In the previous article, we learned how to Pull Process & Network Connections from a Memory Dump. It been kind of fun playing around with a memory dump from our own system, but it would be cool to take a look at some memory dumps that are from infected machines.
Well, you can! The Malware Analyst’s Cookbook (exceptional book by the way) has been kind enough to post several memory dumps that you can play with and also additional plug-ins to increase the functionality of Volatility.
So why don’t we take a look at a memory dump from a system with Stuxnet? Simply download the malfind.py plugin, and the Stuxnet memory sample.
First, let’s grab the imageinfo information for the Stuxnet memory dump:
volatility imageinfo -f stuxnet.vmem
Okay, it is a Windows XP SP3 image, so we use that information with the profile switch.
Next, let’s take a look at what processes were running on the Stuxnet infected machine:
volatility pslist –profile=WinSP3x86 -f stuxnet.vmem (two dashes in front of profile, for some reason only one is showing)
Looking at this list you can see one of the signs of a stuxnet infection. There are three copies of lsass.exe running, there should only be one. The lsass process authenticates users for the Winlogon service. Let’s do a process tree list and see if all three instances of lsass correspond to Winlogon:
volatility pstree –profile=WinSP3x86 -f stuxnet.vmem (two dashes in front of profile)
Looking at the PPID column, you can see that two of the processes connect to PPID 668 and on connects to 624. Looking at the PID you can see that the third instance does in fact tie to Winlogon (624). But the two other instances connect to Services.exe (628). Something is not right.
Let’s run the plugin command “malfind” and see what it detects. According to the Volatility Wiki Command Reference, malfind can find hidden or injected code or DLLs in user mode memory. We will run malfind against the whole memory dump and see if it can find any suspicious code. To do so, because we are using the standalone exe version of Volatility, we need to tell volatility where to find the malfind.py file. We do so by using the –plugin switch:
volatility –plugins=PluginDirectory malfind –profile=WinSP3x86 -f stuxnet.vmem -D OutputFolder (two dashes in front of profile and plugins)
It finds something it didn’t like in explorer.exe right away, but continued to run for quite a while and kicked out two more. Something suspicious in the two copies of lsass.exe – suprise, suprise!
Going to the output directory you see all three suspicious files stored as .dmp files. You can take these files and upload them to VirusTotal to see if it detects anything suspicious.
The first explorer.exe file when run against Virus Total did not return anything malicious. But uploading the two lsass files to virus total returns some interesting results:
Two virus scanners detected something they don’t like in the files. Comodo detects it as a Packed.Win32.MUPX. Gen and VirusBuster detects a Trojan. And indeed there is something fishy there. The real lsass.exe does not have an executable section in its data region, but both of these files do. In the Malfind return above you can see that both copies of the malicious lsass have Page_Execute_ReadWrite permissions. This means exactly what it says, this code has execute and read write permissions.
We could go on and find Stuxnet registry key settings, hidden Dll’s, file objects and numerous other artifacts in this memory sample all with using Volatility. But I will end this simple overview of analyzing stuxnet here.
If you want to see a complete dismantling of Stuxnet with Volatility by an expert analyst. Check out Michael Hale Ligh’s post “Stuxnet’s Footprint in Memory with Volatility 2.0“.
Want to learn a lot more about analyzing malware? Then look no further than the “Malware Analyst’s Cookbook“, written by Michael Hale Ligh, Steven Adair, Blake Hartstein, and Matthew Richard.