Intro⌗

It’s no secret that Wireshark is a great tool that can aid Threat Hunters and other infosec folk up to a degree. But, once you start working with large PCAP files, Wireshark becomes basically unusable which necessitates the use of command line tools or other enterprise solutions. Tshark is also well-suited for this task but I won’t be focusing on that today in favor of some less used tools. I will be using the PCAP from the lab The Case of the Stolen Szechuan Sauce for this demonstration.

The Playbook⌗

Tools Used

  • zeek
  • RITA
  • Basic Linux utilities (cut, sed, tr)

I’m a big fan of the K.I.S.S principal (Keep It Simple, Stupid) and many of the tools I’m about to introduce are useful to this end. Take for instance this diagram of an improvised water filter below and how we can apply the same principal to a large PCAP.
![[net_threathunt.png]]

By applying a multi-tiered approach to picking apart a network capture, we can turn something muddy into something clear and digestible.

So, the process will look something like the following:

  1. Run capinfos against the PCAP to get a time frame which we will need for timelining the incident (not covered here). PCAPs that have less than 12-24 hours total capture time make it a little difficult to identify C2s and another long-beaconing activity which would be worth investigating.
  2. Ingest the PCAP with Zeek which will break up the PCAP into plaintext log files according to a few different categories. RITA also needs Zeek formatted log files to function.
  3. Import Zeek logs to RITA and generate an HTML report to review.
  4. Download a ruleset for Suricata, then run Suricata against the PCAP file to generate some logs for review.
  5. Export files if there are any (we can just use Wireshark for this) and then run YARA against the files. Most of the time we can just hash these files and submit those to a threat intel platform.
  6. Next, we can analyze the PCAP with tools like zeek-cut and datamash to generate some more data we can further pivot on later in our investigation.

Demo⌗

Let’s begin with capinfos

capinfos capture.pcap

Okay, so we’re dealing with roughly an eight-and-a-half hour block, this won’t be ideal for checking beacons or C2 activity but we’ll be looking regardless.

Next, we ingest the PCAP with Zeek to generate our logs.

mkdir zeek_logs && cd zeek_logs/
zeek -r /path/to/capture.pcap

Now we have a bunch of interesting logs we can pivot on, but conn.log is usually the most helpful. RITA can now be used to ingest these logs and generate a HTML report for us.

rita import . new_dbname
[...]
rita html-report new_dbname</code></pre>

Our browser should automatically open up after generating the report, select the database and then we’re going to click on the Beacons tab. Beacons are essentially network “heartbeats” - infected hosts will commonly call out to C2 servers at regular intervals with regular packet sizes, this is a trend RITA excels at identifying.

There’s some other columns out of frame but the most important ones are here. RITA does some fancy math things and spits out a “Score” - the column on the left. The closer to 1 the Score is, the more likely this connection is indicative of a beacon. Now this doesn’t mean the connection is malicious as we’ll demonstrate, let’s look at the FQDNs (Fully Qualified Domain Names) tab.

Immediately we can see that our .999 beacon is a connection to our Domain Controller, so the high score is not really abnormal but we still found something of note. There’s nothing else too interesting here so we’ll move onto “Long Connections”.

Okay so we already know the 3rd entry is just our DC, but the first 2 entries? We should definitely pay attention when connections have cumulative durations almost 10x that of our DC. We’ll make a note of that destination IP and continue investigating.

Last, we’re going to look at the “User Agents” tab and see if there’s anything weird. Attackers often neglect to change their user agent which can give away some tooling or just be something to flag as suspicious.

Two things stand out here. First is the empty user agent string, that’s abnormal activity and something we make a note of to follow up on. The other weird thing is “No JA3 hash generated” for a total of 1349 times. JA3 hashing is a relatively new and allows for the fingerprinting of TLS applications, which in most cases is plain ol’ HTTPS. So why wouldn’t a JA3 hash be generated 1349 times? Hard to say without looking at the packets but it’s possible a non-TLS application was communicating over port 443, and since there would be no cipher exchange or SSL “Client Hello”, no JA3 hash would get generated. Again we make a note of this and will follow up.

This wraps up the first part of our investigation, next time we’re going to learn how to; use Suricata to look for USB activity, export HTTP objects and run a malware scan against them, and how to generate on-the-fly reports like RITA does with datamash and zeek-cut instead.

Until next time, happy hunting!

Further Reading⌗

Detecting Malware Beacons With Zeek and RITA

Book of Zeek (v4.0.0)

Real Intelligence Threat Analytics (RITA)

JA3 Hashes