Traffic Analysis of STRRAT Malware
Source: https://www.malware-traffic-analysis.net/2024/07/30/index.html
Environment
- Kali Linux: This is where I will be using Wireshark to analyze the PCAP file.
- Ubuntu: I will use Ubuntu to access my Security Onion VM through ssh.
- Security Onion: This is what I will use to analyze the PCAP further. Security Onion is an open-source SIEM that allows you to monitor network intrusions, network visibility, and log management.
For the lab environment, you will be good to go with a minimum of 16GB of RAM and 100 to 150GB of hard disk space.
Triaging
The first thing I did was to find out the number of active hosts on the network. Knowing this will help narrow your scope, helping you to be more decisive as to whose account was compromised. I do this by going to ipv4 statistics under the statistics tab in Wireshark. This will give you a list of all the IP addresses that communicated on the network. With this, you will know which IPs are in use.
Using the data from the LAN segment given to us, we can conclude that the user at 172.16.1.66 was compromised.
MAC Address lookup
The next step would be to find who is at 172.16.1.66 so we can notify them about the breach and perform security awareness training for them. The task given to us, says we need to get the user’s MAC address. MAC addresses are on the second layer of the OSI model, so can find it in the ethernet section.
The MAC address of the user at 172.16.1.66 is 00:1e:64:ec:f3:08 and doing a MAC address lookup on the OUI tells us our user uses an Intel chipset.
Finding Hostname
Finding the hostname would require us to check either DHCP or NBNS services as these services carry hostnames in their packets.
The hostname of the compromised user’s computer is DESKTOP — SKBR25F
Windows User Account Name
The username of a user would only be present in an active directory environment, and this is one. To see the Windows user account name, we would have to filter on Kerberos services.
Filtering on Kerberos, we find the compromised user account to be ccollier’s. This is very important in incidence response because with this we can not only organize targeted security awareness training for ccollier and his department, but we also have an idea of the attacker’s attack vector. Is ccollier a C-Suite executive, admin, supervisor, worker with privileged access, or an intern? What department does he work in? Finance, Support, Maintenance, Human Resource…?
Indicators of Compromise
After taking an enormous amount of time to go through the packets captured in the network by filtering on different services like HTTP, SMB, FTP, DNS… I was able to identify the indicators of compromise. However, I would like to point to the fact that, I only had assumptions on the IoCs until I used Security Onion to analyze the PCAP file for me.
The Malicious Activity
The malicious activity of the STRRAT malware was hidden in plain site as communication was specifically crafted to bypass pure visual inspection but thanks to Security Onion, identifying this activity was easy. Looking at the traffic, the victim happened to navigate to github and then communicated with the subdomain objects[.]githubusercontent[.]com.
Checking the domain objects[.]githubusercontent[.]com, it gives us a red flag verifying its malicious activity.
Looking into the traffic, we see it calls out to ip-api.com. With the help of Security Onion once again, I knew why it made that call. ip-api.com was used to get the external IP address of ccollier’s computer.
Looking at the JSON file that was downloaded after ccollier’s contact, we can see it was used to do some kind of location tracking on ccollier.
After this, ccollier’s computer started communicating with the C2 server of STRRAT. STRRAT was using the TCP protocol on port 12132 for exfiltrating data, this method provides stealth as an advantage. TCP allows for persistent, long-lived connections between the malware and its C2 server, enabling ongoing communication and control without the need to frequently re-establish connections, which could raise alarms.
STRRAT preferred TCP over HTTP because HTTP traffic is commonly inspected by web proxies, firewalls, and security appliances that can detect and block malicious behavior. Using raw TCP, STRRAT can bypass these filters, as many security tools are primarily focused on inspecting HTTP/HTTPS traffic. TCP communication can blend in with other legitimate traffic on the network, making it less likely to raise suspicion compared to HTTP, which is more commonly scrutinized.
Looking at the IP address used to communicate with STRRAT and decoding the data in the TCP segment of STRRAT’S activity confirms it is a malicious activity.
I was able to use base64decode to decode some of the contents and I believe STRRAT was enumerating ccollier’s computer looking for sensitive documents.
Decoding some of these base64 encoded strings proves ccollier was enumerating the computer.
For our indicators of compromise, we have the C2 communication to 141.98.10.79 on port 12132 using the TCP protocol carrying in its data segment a keyword “STRRAT “along with the exfiltrated data.
Looking up STRRAT, I found its attack vector to be phishing. Once fallen for, a PDF file is downloaded which has a download link in it. If clicked will download a zip file which when opened runs a JS that decrypts the STRRAT malware.
But in our case, ccollier probably downloaded this malware from objects[.]guthubusercontent[.]com and ran the payload by opening it. So we can conclude that at 02:39 UTC on 30th July 2024, ccollier was infected with STRRAT malware.
Ending Note
After analyzing this malware, I learned a few things about traffic analysis. The first is never giving up. While looking for the indicators of compromise, I checked most of the IPs and domains against services like VirusTotal, Cisco’s Talos, UrlHaus… and a majority of them came clean. Using Security Onion for a cross-examination gave me the needed boost.
The second will be checking the TCP protocol for malicious activity. Most times when I analyze malicious traffic, common protocols like HTTP and DNS give out the iocs easily, but with this analysis, I had to go deeper than the common protocols known to me.
