Unlike in previous posts, Qbot has not generated any Suricata rules, so we get to actually do some raw hunting!
Personally, I like to start looking at TLS traffic as it forces me to look hard at metadata instead of relying on the contents of packets. We’ll move on to packets later, but let’s start further down the attacker lifecycle and see if we can work our way backwards.
Of note, I’ve added the ja3 field to assist with this larger dataset. JA3 is a SSL/TLS client fingerprint that allows us to identify scale good (or bad) client/server TLS connections irrespective of the domain that is used. As you can see, two domains have the same
ja3 fingerprint but different destination IP addresses and domains. This will help in eliminating traffic to chase by filtering out (or on) that fingerprint instead of every domain/IP combination that could be using it.
|Source IP||Destination IP||tls.client.ja3||tls.server.subject|
Let’s filter out the
9e10692f1b7f78228b2d4e424db3a98c ja3 fingerprint (and various others that are part of assumed good for now - yahoo, linkedin, skype, etc.) help get our dataset down to a manageable level (over 300 events down to 95).
Next, let’s look at the largest number of TLS events, and that is
CN=gaevietovp.mobi,OU=Dobubaexo Boolkedm Bmuw,C=ES, I’ve also added the
tls.validation_status field and, as you can see, it is
unable to get local issuer certificate. That’s not necessarily bad, but it’s different from the other TLS traffic samples we’re looking at.
From here we have some indicators (
gaevietovp[.]mobi) that we can take and search through some traffic where we can see more than metadata, however, the only traffic for these hosts was over TLS, so we’ve exhausted the route and can list this as a good find based on the other information we collected above.
Next, let’s remove our filters and check out the HTTP log and see if there’s anything that’s unencrypted that can we dig through. We’ll again eliminate the assumed good (Microsoft, Windows Update, Symantec, etc.), and check out the
http.resp_mime_types. While the filename of
4444444.png is a bit suspect, the fact that it has a file extension of a PNG file, but it has a mime type of
application/x-dosexec is a big red flag.
We’ve got a few options to analyze this file, we can use Docket and carve it from PCAP or we can leverage the file extraction features of Zeek and just grab it right off the sensor.
Filtering on the
files dataset, we can see what the name of the file is that is on the sensor when we look at the
files.extracted field -
HTTP-FQbqYF2UXkZ54fXJXi.exe. Extracted files are located in
ll /data/zeek/logs/extract_files/ total 464 -rw-r--r--. 1 zeek zeek 475136 Feb 25 16:38 HTTP-FQbqYF2UXkZ54fXJXi.exe
If we want to carve that PCAP with Docket, we can do that too…following the TCP stream doesn’t look very good /smh
So, we’ll Export the HTTP Object (or looked at
HTTP-FQbqYF2UXkZ54fXJXi.exe) and hash and collect the metadata from that file (truncated).
... File Name : 444444.png File Type : Win32 EXE File Type Extension : exe Time Stamp : 2020:01:22 15:38:11-06:00 PE Type : PE32 Internal Name : xseja Original File Name : xsejan.dl Product Name : Xseja ...
There’s some interesting things here that we can use when we make some Yara signatures in the Detection-Logic section below:
Furthermore, the hash of
c43367ebab80194fe69258ca9be4ac68) is loud and proud on VirusTotal as being Qbot malware.
Okay, so we’ve got 3 indicators so far, what about the network systems that
444444.png was downloaded from (
5[.]61[.]27[.]159)? In digging into those 2, it looks like we’ve identified everything that talked to/from those systems.
Let’s take a look at the URI structure from
alphaenergyeng[.]com/wp-content/uploads/2020/01/ahead/444444[.]png and see if we have any more hits on systems using
wp-content/uploads/2020/01/ahead/, disco another new hit with 2 new indicators (
I wasn’t able to grab
9312.zip, I have the packets, but there are hundreds of files in the TCP stream with the same name with various sizes. I’m not sure if it’s an issue with my pcap or it’s an obfuscation technique. That said, searching for the URL online yielded several analysis results 1, 2, 3.
In keeping to my mantra of not “finding” things simply because they’re on the IOC list from Malware Traffic Analysis, beyond playing “whack-a-mole” with DNS entries, which I have done before, there wasn’t much additional information I was able to find through raw hunting. I did want to showcase some indicators that Malware Traffic Analysis did highlight, but beyond knowing they were bad because it’s in the IOC list, I don’t think in good consciousness I can say I’d have found it on my own.
68[.]1[.]115[.]106 (post infection SSL/TLS traffic) gaevietovp[.]mobi (post infection SSL/TLS traffic) 7dd50e112cd23734a310b90f6f44a7cd (post infection ja3 fingerprint) 7c02dbae662670040c7af9bd15fb7e2f (post infection ja3s fingerprint) 5[.]61[.]27[.]159 (HTTP request for Qbot PE) alphaenergyeng[.]com (HTTP request for Qbot PE) /wp-content/uploads/2020/01/ahead/444444.png (HTTP request for Qbot PE) c43367ebab80194fe69258ca9be4ac68 (444444.png - Qbot PE) 103[.]91[.]92[.]1 (HTTP request for Qbot archive) bhatner[.]com (HTTP request for Qbot archive) /wp-content/uploads/2020/01/ahead/9312.zip (HTTP request for Qbot archive) 275ebb5c0264dac2d492efd99f96c8ad (9312.zip - Qbot archive) 153[.]92[.]65[.]114 (found by Malware Traffic Analysis) 54[.]36[.]108[.]120 (found by Malware Traffic Analysis) pop3[.]arcor[.]de (found by Malware Traffic Analysis)
Until next time, cheers and happy hunting!