or, How to See Malware Activity in Real Time.
I recently discovered Brad Duncan’s blog Malware-Traffic-Analysis.net. The blog is host to a variety of traffic analysis exercises, primarily involving malware infections that take place over a network and are documented in pcap files. It has really been scratching my digital forensics itch lately, and it allows for some detailed log analysis without having to spend an inordinate amount of time downloading a large VM and getting a full PenTest lab set up. I thought I would share one of the exercises I recently completed (which you can find here).
Here’s the basic setup of the scenario: we have a Windows active directory domain, known as pascalpig.com, residing on the LAN at 10.0.0.0/24. In the Security Operations Center, a series of alerts have recently gone off, telling us that something fishy may be taking place in our network, and we need to track it down and report it. Fortunately, we have a pcap file documenting the network traffic for the entire time frame, so, let’s dig in!
First off, it can’t be overstated how important a well-tuned alerts system is. Without any alerts, we may never have found out that anything was wrong in the first place — a pcap file can generate a LOT of information, and, if you don’t know what you’re looking for, it can get overwhelming and malicious traffic can even start to look legitimate (the more sophisticated threats tend to disguise themselves as legitimate uses of protocols and services, after all). However, if your alert system generates alerts too often and identifies too many false positives, it is likely that you will waste too much time chasing leads that go nowhere and get “alert fatigue.” It’s all about that balancing act, and, not surprisingly, it takes some experience and know-how to achieve it.
In our scenario, our alerts are already well-tuned, so we can rely on its direction. Let’s follow the trail.
To start with, we can see that everything seems to start with the IP address 10.0.0.179. Since this is a windows system using Kerberos, and we have access to network traffic with the domain controller, we can peer into the Kerberos protocol and gather some basic user information about this IP address. In a professional scenario, this will be important for when we fill out an incident report at the end of our investigation.
It looks like the IP address 10.0.0.179 belongs to a desktop computer, labeled DESKTOP-M1JC4XX, with the user account belonging to Ronaldo Paccione currently signed in.
The alerts are warning us that this user is downloading a suspicious executable file from a “dotted-quad Host.” Put simply, this just means that an executable is being downloaded directly from an IPv4 address, rather than a named domain. Searching the pcap for an HTTP get request shows the full path:
http://198.12.66.108/jojo.exe
Wireshark, while free, is a particularly powerful traffic analysis tool, and one ability it has is to reconstruct unencrypted data that is captured in transit. In this case, we can actually grab the jojo.exe file in order to examine it.
Note, I rebuilt this file in a sandboxed Linux VM. Without knowing the details of what you’re grabbing, I don’t recommend reconstructing malicious traffic on your usual computer, especially not on an internet connected, Windows computer (since this is the type of environment where the incident originated).
After reconstructing the file, we can check some of the info about it and also hash it. With this hash, we can submit the info online (like at the very popular VirusTotal) and learn a bit more about the file from others who may have researched it already. We could perform static or dynamic malware analysis ourselves, but that’s a bit outside the scope of this exercise (that, and I don’t have my lab set up for that particular type of procedure at the moment)
As it turns out, jojo.exe is a PE32 executable built for Windows and has been identified as a vector in the execution of the AgentTesla malware. AgentTesla is a remote access trojan (RAT) that has been quite popular, especially in 2020, for accessing systems and stealing privileged information. Obviously, this is bad and the downloading of an executable that can be attributed to a malware infection can definitely be considered as an Indicator of Compromise (IoC). As far as I can tell, the pcap file doesn’t seem to indicate the catalyst for downloading this file (much of the earlier traffic was TLS encrypted), but an AgentTesla infection is most commonly started through phishing.
Almost immediately after the jojo.exe file gets downloaded, we can see the affected desktop attempt to connect with a number of IP addresses, some legitimate and some not so much. First, the computer makes a DNS request to paste.nrecom.net, which resolves to 37.120.174.218, and then performs a TLS handshake, establishes a new encryption certificate, and then encrypts all traffic to this site. At this point, some sort of application data is downloaded to the computer, but, unfortunately, because of the encryption, we can’t be sure exactly what it is. Next, the computer makes a DNS request for api.ipify.org, which resolves to 54.235.98.120, perform a TLS handshake with that site, establishes a new encryption certificate, and it downloads some encrypted data as well.
While we can’t be positive of the data that was downloaded because of the encryption, after doing some research (primarily reading this article here), I’m fairly confident saying that it is at this point that the computer is definitely infected with the AgentTesla malware. Particularly important is the use of the pastebin site, paste.nrecom.net, which (while a legitimate site) has a history of infecting users with AgentTesla.
After accessing the previous two suspicious sites, the computer finally makes a DNS query to mail.big3.icu, which is a file sharing site (that also has a history of being used by threat actors, and, specifically, AgentTesla-infected computers).
Lastly, we then see the affected computer start to exfiltrate data to that specific file sharing site using SMTP. Fortunately, this particular traffic wasn’t encrypted, and, using Wireshark, we can actually reconstruct the data that was uploaded via SMTP, and, lo and behold, it’s a trove of privileged data — credentials and passwords, screenshots from the infected computer, and key logger data, to name a few.
At this point, we’ve got a pretty good idea of what got stolen and how it happened. In a professional scenario, it would more or less be time for cleanup (Eradication & Recovery) and then writing an incident report (and maybe also performing an interview with Ronaldo over his cyber hygiene).
As far as traffic analysis goes, this was a fairly straightforward (but fun) one, and the alerts were pretty spot-on as to what occurred. Of course, this isn’t always the case, but, again, it emphasizes the importance of finely-tuned alerts.
