Analyzing Dridex malware network traffic

Brad Duncan, who runs the website Malware-Traffic-Analysis.net, posted a new packet capture, which you can find here. This is a great website for learning how to analyze Windows malware-compromised network traffic, using Wireshark, Security Onion IDS alerts, and threat intelligence sharing platforms.

I am preparing to take the CompTIA CySA+ certification exam in the next few weeks. The time and attention put into the packet capture exercises over the past several months has been very helpful in preparation for some aspects for the exam.

I’m also collaborating with a few security professionals around the U.S. (connected via LinkedIn) to create and publish an APT emulation plan, which utilizes MITRE ATT&CK. So, there is certainly more going on than packet capture analysis exercises. I post these walkthroughs because I enjoy the process. I hope they are beneficial to you, the reader.

This is a walkthrough of the latest PCAP exercise, called DUALRUNNING.

Note: I am using a Kali Linux VM. All CLI commands Linux-based.

First, it’s important to take note of the LAN segment information, which is provided:

LAN segment range: 172.16.1.0/24 (172.16.1.0 through 172.16.1.255)

Domain: dualrunning.net

Domain controller: 172.16.1.2 — Dualrunning-DC

LAN segment gateway: 172.16.1.1

LAN segment broadcast address: 172.16.1.255

In order to more easily identify suspicious network traffic, it helps to know what hosts are in-scope.

A text file containing the SGUIL alerts is provided.

The task is to write up an incident report, based on the packet capture file and alerts. The report should include:

• An executive summary — when, who, and what
• Details on the compromised host — IP and MAC addresses, host name, Windows account name
• Any indicators of compromise — file hashes, IPs, URLs, domain names, etc. associated with the infection

As shown in the screenshot below, the first few alerts indicate a high alert count, over local TCP port 8088, and the IP address 172.16.1.239. The activity also involves a Microsoft Office document.

On Wireshark, there are two GET requests from 172.16.1.329 to 185.21.216.153, displayed after applying the following search filter:

(http.request or tls.handshake.type eq 1) and !(ssdp) and tcp.port == 8088

As shown in the far left column, both of the packets were sent across the network at 20:31 UTC, on Wednesday, 07–24–2021. It’s very important to document when these events happened.

Right-clicking on the second packet, I click Follow > TCP Stream.

The stream content displayed in red is traffic from the client (172.16.1.329) to the server (185.21.216.153), while traffic from the server to the client is displayed in blue.

The GET request was for a binary file (file6.bin), but the contents of it is actually a Windows executable.

I close the packet stream and check out the other packet. This packet contains a GET request for a Microsoft XLS document, encoded through GZip compression.

A way that I can check this URL’s reputation, including the file path to the GET request, is to run it through VirusTotal. The domain www.insiderushings[.]com with a GET request for /wp-content/Receipt-9650354.xls?evagk=2MyeEdhGPszYX, is just:

insiderushings[.]com/wp-content/Receipt-9650354.xls?evagk=2MyeEdhGPszYX

VirusTotal performs a URL scan, and a number of scanning engines detect the URL as malicious.

The incident report should include any hash values of exported files. I can export this file from Wireshark, by clicking on File > Export Objects > HTTP…

The document shows up first on the list. I click Save to export it. To get the SHA256 hash value, I can use the sha256sum command in the terminal.

$ sha256sum ‘Receipt-9650354.xls%3fevagk=2MyeEdhGPszYX’ 
8da9ca75c79179d93b03c8705640c9bc6f28a759fedf95cf76af05de9d29785d Receipt-9650354.xls%3fevagk=2MyeEdhGPszYX

The file hash is 8da9ca75c79179d93b03c8705640c9bc6f28a759fedf95cf76af05de9d29785d.

While we’re at it, let’s query the other URL and GET request: http://buyer-remindment[.]com/templates/file6.bin. This is the Windows executable.

Several scanning engines detected this URL as malicious. Again, let’s export this file from Wireshark, and obtain the file hash. Again, click File > Export Objects > HTTP…

$ sha256sum file6.bin 
4b667dbfe053e815e4915a20c176e98785f92cb59e1b895d0f0527f6970b60ca file6.bin

Both of these network connections were over local TCP port 8088. Based on the IDS alerts, the victim user downloaded a malicious VBA-embedded Microsoft Excel document.

Now that it’s clear who the infected host was, let’s document the host information. The report should include the infected host IP address, MAC address, host name, and Windows username.

We already know the IP address, which is 172.16.1.239. To locate the MAC address, select any packet with the that IP address at the Source IP, and expand Ethernet II section in the lower pane, and it will display as the Source MAC address: 00:13:d4:10:05:25.

Next, we need the hostname. There are different protocols we can use to look up on the hostname, but in this instance, we can use the protocol, NetBIO Name Service, by using the nbns search filter.

Select the packet after the name query response packet, expand the NetBIO Name Service option in the lower pane, expand Queries, where it displays DUALRUNNING as the name.

To find the host’s Windows user name, use the search filter:

kerberos.CNameString and !(kerberos.CNameString contains $)

In the lower pane, expand the Kerberbos option, then expand as-req, req-body, cname, and cname-string:

It displays samantha.reed as the user name.

Now that we have documented the compromised host information, we will continue investigating and documenting the other indicators of compromise.

Looking at the alerts, there are repeated triggered alerts for Dridex activity.

Dridex is the name for a family of information-stealing remote access trojan (RAT) malware, that targets its victim’s banking information. Dridex malware is often distributed through malicious spam (malspam) e-mail campaigns, attached directly as a Microsoft Office document, or through a link to a malicious file. Once the victim user opens the file, a DLL installer will typically create a C2 channel on the user’s machine for remote access.

Below, post-infection traffic shows Samantha’s personal data being exfiltrated, outbound, through the attacker’s IP address, 81.17.23.125, over TCP port 2318.