Analyzing SquirrelWaffle With Gigasheet
Disruption of Emotet’s infrastructure earlier this year was music to the ears of incident responders all over the world. With the introduction of initial access broker markets and a steep rise in ransomware affiliates, cybercrime groups were wreaking havoc. Well, as they say, ‘When one leaves, another arrives’. SquirrelWaffle is the new baddie in town.
Let’s take a quick look at how the loader (or dropper) got its name, its characteristics, and how we can quickly analyze SquirrelWaffle’s network traffic using Gigasheet.
What is ‘SquirrelWaffle’?
I get it; the name’s quite strange but that’s precisely how the industry has been keeping track of adversaries. In this case, SquirrelWaffle is the name assigned to a new set of malware loaders by Proofpoint under their Emerging Threats Pro ruleset. What’s making headlines about the loader is the infrastructure it’s served from: the TR botnet.
The TR botnet was previously in the limelight as it was the primary distributor of Qakbot, another loader responsible for hundreds of compromises worldwide . Although Qakbot went silent earlier this year, its alternative, SquirrelWaffle, seems to have picked up the pace and might just be the biggest threat after Emotet’s takedown.
Network Analysis of SquirrelWaffle
To kickstart our analysis of SquirrelWaffle, we’ve picked up a sample network traffic capture shared by Brad on Malware Traffic Analysis. If you’re interested in following along, feel free to get the capture and we’ll get to work.
The Old School Approach
Traditionally, you’d likely be in for a long Wireshark analysis session. Wireshark is an excellent network protocol analyzer and an analysis powerhouse; there’s no denying that. However, with the release of more frameworks like Bro/Zeek and other open source tools, you do have lots of options to choose from. Your tool selection will likely be based on the ease of use, time to analyze a traffic capture, and other features.
For this particular analysis, I’ve decided to use Zeek to analyze the traffic capture of the SquirrelWaffle infection. Although Zeek can be configured to run and acquire traffic on a live interface, it can also be paired with a packet capture file acquired from a tool like tcpdump. Here, I’ve simply passed the PCAP to Zeek for default analysis:
zeek -r squirrel-waffle.pcap -C
Great; we’ve got a dozen or so log files to go through for our analysis.
Since we do know that the initial access was a Phishing email embedding a URL (using the HTTP protocol), we can simply kickstart our analysis looking for connections to the port. Now here’s the catch; analyzing Zeek logs in its default tab-separated value format requires some form of processing. Zeek’s own documentation suggests using awk, a text processing tool, or zeek-cut, a utility shipped with Zeek itself to process the logs.
For example, to retrieve the list of domain names resolved in this traffic capture; you can use zeek-cut on dns.log to acquire the information. Here’s it:
cat dns.log | zeek-cut query | sort | uniq -c | sort -n
If you’re not a fan of the TSV (tab-separated value) format, you can ship your Zeek logs in JSON. Using a tool like jq, processing becomes easier but the catch to process it is still there. If you love command-line jujutsu, the path to analysis isn’t really difficult. For beginners and analysts looking to steer clear of consoles for a quick analysis session, Gigasheet’s another option.
The New Quick Way To Analyze Network Traffic
Gigasheet makes it easy to quickly analyze this data, without requiring any installation, configuration, or special commands to run. Once logged in to Gigasheet, simply drag-and-drop all your Zeek log files on the ‘Your Files’ page and it will ingest them as separate datasets. It’s super quick and you can organize your files in folders if you’re a busy analyst with multiple traffic captures to analyze at once. In this example the files are relatively small, but Gigasheet supports logs with tens of millions of rows of data.
Jumping into connection logs (conn.log), our log files are completely processed and ready for our analysis. Take a look:
First, let’s filter our connections to port 80 only so we’re focused on HTTP connections. To use the port as a filter for the field, ID.RESP_P, head over to the filters tab, pick the column, the operator, and finally the value (80). Whew; 288 logs out of 788. We’re already making progress.
In the past, you’d pick apart fields using zeek-cut or awk, but in Gigasheet we can easily remove columns to clear out the view by clicking on the hamburger menu by the field name and selecting ‘delete’. Now that the pre-processing is out of the way, let’s focus on the analysis. We know the user received an email which attempted to download an archive file from the domain, business-z.ml. A simple reverse lookup shows us the IP address which resolves the domain; 188.8.131.52.
Just one single entry; yet the duration of the connection and the received byte count do suggest a file transfer might’ve taken place; we’ll make sure of it, next. We can find this information in another log file; http.log. Here, you can also save time by utilizing Gigasheet’s Cross-lookup Function to find the UID (CJMKst481WzekuBKw1) across the two files and correlate logs together.
From the http.log file, we can find a similar entry pointing to a file download from the aforementioned domain. Let’s pick up the FUID (unique ID for the downloaded file in the field RESP_FUIDS) from the log and search it in files.log to see information of the acquired file.
This is where you could get your malware analysis gloves on and work through the mal-doc to figure out what the document attempts to do. Since we’re aware of its malicious nature, let’s skip past the initial checks and dump the macros from the document. Using a tool like oledump or olevba, we can swiftly analyze the OLE macros inside an Office document. Take a look at the Indicators of Compromise (IoC) reported by olevba:
The macro attempts to connect to the aforementioned URLs, pull the HTML pages, convert them to their binary equivalent, and write them to disk - only to execute them later via rundll32.exe. Here’s a complete list of the domains (or URLs) which we were able to acquire from the SquirrelWaffle macros:
Let’s group the server names within the ssl.log file (since they do actually encrypt their communication) and look for domains which match the domains in our list. Here's a grouped view of the domains from the log file on Gigasheet:
Now that the DLLs are on the disk; the infection continues to make headway to the SquirrelWaffle C2. Here, you’d be going forward with analyzing the DLL (spoiler alert: it’s packed to make your analysis a tad bit harder) dropped to disk and look for network indicators within. It’s test.digiru.ro in this case. Since it uses the plain-text HTTP protocol to communicate back and forth with the compromised host, we can actually take a look into the communication.
SquirrelWaffle infections don’t just end there; just as their predecessors didn’t. Much like Qakbot and Emotet, several SquirrelWaffle infections have been linked to Cobalt Strike as the follow-up malware (i.e., the malware it loads). Here’s the C2 communication with the Cobalt Strike server from this traffic capture:
SquirrelWaffle, as a loader, incorporates a custom packer along with several anti-debugging techniques. Although it’s not technically impossible to override them, they do require some expertise to get to the executable or payload being loaded. The SquirrelWaffle sample we’ve analyzed drops Cobalt Strike to the compromised system and the infection chain continues.
Up against time trying to pick apart the network traffic of a SquirrelWaffle infection? Give Gigasheet a try by signing up for the beta and importing Zeek logs for a swift response, now!