By Doug Metz, Senior Security Forensics Specialist

A common scenario for SOC’s and IR teams is being handed a piece of evidence and being asked to “Find Evil.” Those on the receiving end know this to be a broad ask. If there is a known good image to compare things to, the process may be easier, but not all organizations have a gold build available for comparison.

One of the areas I like to investigate when hunting evil is Network Connections. Malware can arrive on a system via multiple means, from phishing, internet activity, USB devices, or remote network connections. Once the malware is there it is going to want to communicate to other Command & Control (C2) infrastructure assets. In the case of malware droppers, this may be a download location where additional malware is being loaded. It could also be a repository where exfiltrated data is being sent. Unless the intention of the malware is strictly to debilitate the asset, there will be some communication expected from the malware. The network activity will not be the earliest activity we find on the system, but it gives us a point in time to pivot from.

I have a RAM dump collected from the suspected compromised computer in this example. The .dmp file was collected using DumpIt within Magnet Response. I processed the memory image with Comae using Axiom Cyber.

Sifting through the noise

Starting with Network Connections, we see there was a fair amount of network activity captured on this system. How are we to know what good network traffic looks like as opposed to bad? A seasoned analyst may recognize certain IP ranges to belong to Microsoft or Google, but others must be tracked down. Depending on the activity of the system before the memory capture, there could be hundreds or more IP addresses referenced, and with duplicates.

Forensics is all about the toolbox approach, and one of the tools I use for this occasion is a Python script, abeebus.py, from Richard Davis over at 13 Cubed.

First, I will use Axiom Cyber’s export feature and export the results of the Network Connections artifacts to a CSV file.

If we browse to the selected export location, we can see Network Connections – Memory.csv

With the help of the abeebus script, we will run through all the IP addresses in the CSV file and run a lookup for the location information and the ASN (Autonomous System Number). We will dump the results into a text file for easy viewing.

python .\abeebus.py ‘E:\Cases\Bohemia\Network Connections – Memory.csv’ > abeebus.txt

Reviewing the results, we can see easily that one of these is not like the others.

Just because an IP address is outside your normal geography does not necessarily make it malicious, but it is one area to look at when identifying outliers. When reviewing the ASNs, you can also look for sources you recognize and remove them from your initial investigation. But be cautious. You could have malware using Azure, Google Cloud, or AWS as part of their infrastructure.

We can also use VirusTotal to investigate the address further.

Let’s head back into Axiom Cyber with our lens focused on the suspicious looking 135.X.X.X address.

Using the Connections feature of Axiom Cyber, we can see the IP address is associated with the process RegSvcs.exe with the process ID of 7640.

Within the Axiom Cyber case we can do a global search for RegSvcs.exe.

We can see the file path information of “C\Windows Microsoft.NET Framework v4.0.3031… This may be an item to add to our list of indicators, and something to follow back on to see what other files share the same path and when they originated.

Along with the other memory information that Axiom Cyber has provided, we can see that a Prefetch file has been carved and is also providing a hit for our search criteria.

The Prefetch artifact for 4USFLIOF.exe has file association with RegSvcs.exe. We can also see that there was a file path of ~User\APPDATA\LOCAL\TEMP\RARSFX0. Both are threads that we could pull on further.

Using the Prefetch artifact and Axiom Cyber’s Timeline feature, we can see what was happening on the system before and after the file was executed.

Just prior to 4USFLIOF.exe executing, we can see that a command shell was running (CMD.exe). Based on the millisecond difference between the events, it is likely that 4USFLIOF.exe was initiated from the command shell immediately preceding it. In the artifact details, we can also see another suspiciously named executable being called from the \TEMP\RARSFX0 directory. We can add this to our list of indicators.

How many plates can you spin?

At this point, we have fair confidence that there has been malicious activity on the system. The VirusTotal report for the IP address suggested Redline, an Infostealer malware.

We can dig deeper into the memory sample, but it might also be time to start actioning other teams. Besides the memory image, now would be a suitable time to grab a triage collection with Magnet Response. It would also be appropriate to contact the Threat Hunting and Network teams to see if there’s evidence of any other assets communicating with the suspect IP address or showing a similar presence of file indicators. Further research on the IP address points to a Malware bazaar download for a Redline Stealer variant. Hopefully, the RE team remembers the 5lb. bag of Skittles you sent over last week and can look to see what the capabilities of this malware are while you continue the investigation.