Hey everyone! Today I’ll be going over a malware traffic analysis exercise I recently completed called Dualrunning (https://www.malware-traffic-analysis.net/2021/07/14/index.html). If you aren’t already familiar with malware-traffic-analysis.net, it is an awesome resource for learning some really valuable blue team skills. Brad Duncan, the owner of the site, is very knowledgeable and always trying to share his knowledge. Not only does his site include exercises like this, but he also has several tutorials for techniques you can use in wireshark to analyze malware network traffic.
For this exercise, I will be mostly following the template suggested by Brad but with the addition of a technical summary, where I will go more in depth into how I did my analysis and what indicators I based my conclusions off of. So, this post will include a short executive summary, details of the infected victim, indicators of compromise (IOC’s), and then the technical summary at the end.
At approximately 2031 GMT on 14 July 2021, a Windows host used by “samantha.reed” was infected with Dridex malware. Dridex malware is highly modular in its capabilities and allows attackers to steal sensitive data, delete files, establish persistent access, etc.
Compromised Host Details
IP address: 172.16.1.239
MAC address: 00:13:d4:10:05:25
Host name: DEKSTOP-F3P7XLU
Windows user name: samantha.reed
Indicators of Compromise
Host Based Indicators of Compromise
The following is a list of files associated with the compromise, their file sizes, file types, their SHA-256 hashes, and a link to the virustotal results for each file.
- Size: 711.5 KB
- File Type/Description: Microsoft excel spreadsheet with embedded macro.
- SHA256: 4c56a5a7e49b23fcfab4b8d469d42e583497178b9b237374db3e14289f2afc64
- 164 KB
- Windows portable executable (PE).
- SHA256: 8e2d3f6bc5f7b639638d2f5ec751bc2985f1636005131623c5d2c448885c5d89
Network Based Indicators of Compromise
The following is a list of network activity associated with the compromise.
- HTTP GET request to hxxp://insiderushings.com/wp-content/Receipt-9650354.xls?evagk=2MyeEdhGPszYX, port 8088
- HTTP GET request to hxxp://buyer-remindment.com/templates/file6.bin, port 8088
- C2 HTTPS traffic to/from 18.104.22.168, port 453
- C2 HTTPS traffic to/from 22.214.171.124, port 443
- C2 HTTPS traffic to/from 126.96.36.199, port 443
- C2 HTTPS traffic to/from 188.8.131.52, port 443
- C2 HTTPS traffic to/from 184.108.40.206, port 443
- Reverse shell traffic to/from 220.127.116.11, port 443
In this portion of the post, I will be walking through the process of how I performed my analysis.
Starting off, I have several suricata alerts to clue me in on where to start.
These alerts also allow me to make a very early guess as to a possible chain of events. It would be fair to assume from these alerts that a user may have run a macro (VBA project) embedded in a Microsoft Office document. This macro may have then downloaded an EXE or DLL over HTTP, and the EXE/DLL is using the “IsDebuggerPresent” Windows API call to evade analysis. This EXE/DLL is also possibly identified as being of the Dridex malware family. Just based on my previous knowledge of past and current malware threats, I know that threat actors will often use MS office macros to execute malicious code, drop malicious payloads, and generally wreak havoc on their victims. This will drive the next steps in my analysis.
Using the hunting capabilities in security onion, I found that the local IP address 172.16.1.239 downloaded a portable executable (PE) file at 20:31:44 GMT. This can be identified below due to the presence of the MZ magic number at the beginning of the file header.
This told me that I should begin investigating the time period between 20:31:44 GMT, and the beginning of the traffic at 20:30:34 GMT in order to see if I could find the MS office document being referenced in the suricata alert. After narrowing down the search timeframe, I was able to identify the victim IP address (172.16.1.239) making an HTTP GET request to hxxp://insiderushings.com/wp-content/Receipt-9650354.xls?evagk=2MyeEdhGPszYX. This is where the victim retrieved the MS office document being referenced in the suricata alert. Investigating the insiderushings.com domain on virustotal revealed that it is a known malicious domain, and the “communicating files” section references several xls files with similar names to what the victim downloaded.
From here, I used intezer analyze to analyze the Receipt-9650354.xls file, and not surprisingly, the file was identified as malicious. Intezer analyze is also able to classify the malware as being from the Dridex family based on multiple factors, with the screenshot below showing that the excel file spawned a mshta.exe process, which is a behavior seen in Dridex malware.
The attached image below is from Hatching Triage, and shows what the excel document actually looks like when opened by a user. As you can see, it uses the intuit quickbooks name and logo to appear like a legitimate document, presumably relating to taxes. When combined with a filename referencing “Receipt”, you can see how somebody might be fooled into opening this file and following the directions. Once this happens, the infection begins.
Based on this, I was pretty confident that the activity in question is in fact related to Dridex malware. Once the victim clicks “enable content”, the threat actor then uses an mshta.exe process spawned by the excel file’s embedded macro to download the actual Dridex payload. I am not going to go into detail about exactly how it works, as that begins to enter reverse engineering territory, but you can read more about how Dridex malware uses mshta.exe here in this blog post from FortiGuard labs (https://www.fortinet.com/blog/threat-research/new-dridex-variant-being-spread-by-crafted-excel-document).
So at this point, I had identified that the victim was infected with Dridex malware after opening a malicious excel file and running a macro which then downloaded the Dridex payload. Now I needed to go back to that portable executable (PE) file that I observed being downloaded by the victim, and do some analysis on that.
Again using the security onion hunting capabilities to search for downloaded files, I was able to find the name and MD5 hash of the file being downloaded at 20:31:44 GMT, and the domain from which it was downloaded. This file is the Dridex payload.
Searching the MD5 hash of the file6.bin file reveals that the file is identified as malicious by 57 out of 67 vendors on virustotal. The “names” section also references the exact file name “file6.bin”
Intezer analyze also identifies file6.bin as being associated with Dridex malware, again correlating with the suricata alerts and increasing my certainty of a Dridex infection. After the Dridex payload was downloaded at 20:31 GMT (15:31 local), approximately 18 minutes passed before the first Dridex C2 traffic alerts from suricata, suggesting that the malware is using sleep API calls to delay its execution, a common tactic used by malware authors in an attempt to avoid both detection and analysis.
Of note, the malware is also using the “IsDebuggerPresent” API call to detect sandboxes, again in an attempt to avoid full and effective analysis of the sample. This is referenced in the suricata alerts in security onion. This is essentially the end of the relevant Dridex activity, but I still had over two hours of network activity left to investigate, so I headed over to wireshark. The first thing I did in wireshark was filter the kerberos packets in order to get the MAC address, username, and hostname associated with the victim IP address. From there, I filtered new TCP connections, and found that a new connection was established at 21:59 GMT between the victim IP and 18.104.22.168. I then filtered for all packets with either a source address or destination address of 22.214.171.124, as you can see in the image below.
The nearly constant traffic between the two IP addresses, with two ports opened on the victim, and with very small packet sizes, is suspicious. Investigating more of the traffic, I found a few packets containing some odd looking data, so I threw the data over into cyberchef to see what it could decipher.
This raises my suspicions big time. Between the weird traffic, the strange data in the image above, the already existing malware infection, this all looks a lot like a reverse shell was spawned on the victim. Additional analysis reveals that the attacker clearly enumerated the files available to them on the victim machine with the current access that they had. The below image is the cyberchef output of some HTML code that was in a packet originating from the victim and sent to the threat actor with the reverse shell.
Digging into the packets in wireshark even more, I found two TCP streams where the attacker made GET requests to the victim in order to retrieve directory listings.
At this point, there is very little left in the PCAP file and there doesn’t appear to be any significant information to be learned from the rest of it, so that will do for the analysis.
Before I conclude my post, here is a link to a yara rule I wrote for detecting Dridex malware EXE’s/DLL’s: https://github.com/AaronS97/Yara-Rules/blob/main/Dridex.yara.
In conclusion, this was a fun exercise and I definitely learned a lot about Dridex malware, which I was unfamiliar with beforehand. This was a good exercise for me to continue learning how to use security onion to its full potential. I look forward to sharing more of these malware traffic analysis exercises. Thank you for visiting my blog! If you enjoyed this post, please subscribe and share!