Researchers:
Maxim Mai (g9maxim@cdf.toronto.edu)
Nate Margono (g8margon@cdf.toronto.edu)
Dave Weber (g8weberd@cdf.toronto.edu)
Advisors:
Professor G. Scott Graham (Computer Science, University of Toronto)
Ioan Stefanovici (Computer Science, University of Toronto)
Research Background:
As a undergraduate/graduate course project, we were guided to continue MHL’s investigation on stuxnet, which is a very sophisticated malware discovered in 2010. We performed static analysis on a memory image dumped from an infected machine, using volatility 2.0
FRIDAY, JUNE 3, 2011
Stuxnet’s Footprint in Memory with Volatility 2.0
In this blog post, we’ll examine Stuxnet’s footprint in memory using Volatility 2.0. A talk was given at Open Memory Forensics Workshop on this topic (see the online Prezi) and the details will be shared here for anyone who missed it.I picked this topic for two reasons. First, Stuxnet modifies an infected system in such ways that are perfect for showing off many of the new capabilities in Volatility 2.0. We won’t cover all of Volatility’s commands (for example you won’t see idt, gdt, ssdt), because Stunet doesn’t mess with those areas of the system, but you’ll get a good summary. Second, although many people understand technical malware descriptions, not many people have the “glue” knowledge to translate artifacts that they read about into Volatility commands. Sometimes you can capably determine if a system is infected by hunting for the artifacts eluded to in reports. Thus, many of the artifacts we’ll be hunting come from direct quotes in the following articles:
* [1] Mark Russinovich’s Analyzing a Stuxnet Infection with the Sysinternals Tools, Part I
* [2] Mark Russinovich’s Analyzing a Stuxnet Infection with the Sysinternals Tools, Part II
* [3] Mark Russinovich’s Analyzing a Stuxnet Infection with the Sysinternals Tools, Part III
* [4] Symantec’s W32.Stuxnet Dossier
* [5] Amr Thabet’s MrxCls – Stuxnet Loader Driver
* [6] ESET’s Stuxnet Under The Microscope
original post by MHL: http://mnin.blogspot.com/2011/06/examining-stuxnets-footprint-in-memory.html
Artifact 19: RPC Servers
The first artifact that we investigated was the RPC servers. Starting with the infected lsass.exe processes with PIDs 868 and 1928, we investigated the DLLs that were associated with each process. To do so, we used the command:
$ ./vol.py -f stuxnet.vmem dlllist -p 868,1928 Volatile Systems Volatility Framework 2.0 ************************************************************************ lsass.exe pid: 868 Command line : "C:\WINDOWS\\system32\\lsass.exe" Service Pack 3 Base Size Path 0x01000000 0x006000 C:\WINDOWS\system32\lsass.exe 0x7c900000 0x0af000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 0x0f6000 C:\WINDOWS\system32\kernel32.dll 0x77dd0000 0x09b000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e70000 0x092000 C:\WINDOWS\system32\RPCRT4.dll 0x77fe0000 0x011000 C:\WINDOWS\system32\Secur32.dll 0x7e410000 0x091000 C:\WINDOWS\system32\USER32.dll 0x77f10000 0x049000 C:\WINDOWS\system32\GDI32.dll ************************************************************************ lsass.exe pid: 1928 Command line : "C:\WINDOWS\\system32\\lsass.exe" Service Pack 3 Base Size Path 0x01000000 0x006000 C:\WINDOWS\system32\lsass.exe 0x7c900000 0x0af000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 0x0f6000 C:\WINDOWS\system32\kernel32.dll 0x77dd0000 0x09b000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e70000 0x092000 C:\WINDOWS\system32\RPCRT4.dll 0x77fe0000 0x011000 C:\WINDOWS\system32\Secur32.dll 0x7e410000 0x091000 C:\WINDOWS\system32\USER32.dll 0x77f10000 0x049000 C:\WINDOWS\system32\GDI32.dll [snip]
We can see that each process starts the DLL RPCRT4.DLL. On MHL’s blog, in his write-up for the second artifact, he states that in the fake lsass.exe processes, significantly fewer DLLs are contained within them. However, RPCRT4.DLL is kept, and its primary function is to spread the malware to other computers.
We can confirm this by using svcscan and then using GREP to find out the network connection that is setup to call RPC:
$ ./vol.py -f stuxnet.vmem svcscan | grep rpc Volatile Systems Volatility Framework 2.0 [snip] 0x3885f8 0xb9 -------- 'rpcapd' 'Remote Packet Capture Protocol v.0 (experimental)' SERVICE_WIN32_OWN_PROCESS SERVICE_STOPPED -------- 0x388720 0xbb 940 'RpcSs' 'Remote Procedure Call (RPC)' SERVICE_WIN32_SHARE_PROCESS SERVICE_RUNNING C:\WINDOWS\system32\svchost -k rpcss
Artifact 20: Stolen Digital Signatures
The second artifact mentioned by MHL that we investigated with Volatility was the stolen digital certificates. Russinovich mentioned that Stuxnet contained signed certificates from Realtek and JMicron[1]. A custom Yara rule, stolen_signatures.yar, was written to help find the digital certificates:
rule stolen_signatures
{
strings:
$comp1 = "realtek" nocase
$comp2 = "jmicron" nocase
condition:
$comp1 or $comp2
}
We used malfind in combination with yara to locate processes that contained either of the companies whose certificates were stolen. The full command was:
./vol.py -f stuxnet.vmem malfind -D out/ -Y stolen_signatures.yar The rogue lsass.exe process with PID 1928 yielded several hits: Name Pid Start End Tag Hits Protect lsass.exe 1928 0x00870000 0x9a7fff00 Vad 1 PAGE_EXECUTE_READWRITE Dumped to: out1/lsass.exe.1e47c00.00870000-009a7fff.dmp YARA rule: stolen_signatures Hit: Realtek 0x008ca824 52 65 61 6c 74 65 6b 20 53 65 6d 69 63 6f 6e 64 Realtek Semicond 0x008ca834 75 63 74 6f 72 20 43 6f 72 70 31 3e 30 3c 06 03 uctor Corp1>0<.. 0x008ca844 55 04 0b 13 35 44 69 67 69 74 61 6c 20 49 44 20 U...5Digital ID 0x008ca854 43 6c 61 73 73 20 33 20 2d 20 4d 69 63 72 6f 73 Class 3 - Micros 0x008ca864 6f 66 74 20 53 6f 66 74 77 61 72 65 20 56 61 6c oft Software Val 0x008ca874 69 64 61 74 69 6f 6e 20 76 32 31 0d 30 0b 06 03 idation v21.0... 0x008ca884 55 04 0b 14 04 52 54 43 4e 31 23 30 21 06 03 55 U....RTCN1#0!..U 0x008ca894 04 03 14 1a 52 65 61 6c 74 65 6b 20 53 65 6d 69 ....Realtek Semi Hit: Realtek 0x008ca898 52 65 61 6c 74 65 6b 20 53 65 6d 69 63 6f 6e 64 Realtek Semicond 0x008ca8a8 75 63 74 6f 72 20 43 6f 72 70 30 81 9f 30 0d 06 uctor Corp0..0.. [snip] Hit: realtek 0x008cad87 72 65 61 6c 74 65 6b 2e 63 6f 6d 30 0d 06 09 2a realtek.com0...* [snip]
It is evident from this malfind dump, that we were able to retrieve the digital signatures (bolded) mentioned by Russinovich in his article, which was stolen from Realtek Semiconductors Corp, and was a legitimate Microsoft certificate (“Digital ID Class 3 – Microsoft Software Validation v21.0”). Unfortunately, the dump was unable to detect the stolen JMicron signature.
It’s noteworthy that the volatility command verinfo could’ve easily detected this embedded certificate in the rogue lsass.exe process, if verinfo still accepted PID (“-p, –pid”) as a parameter, but that feature has been deprecated in Volatility 2.0[2].
Artifact 21: UPX Packing
Another artifact mentioned by MHL, that he didn’t have time to investigate, is UPX packing. UPX is a versatile executable compression program that is commonly used on malware, as it adds a layer of obfuscation. After conducting some research, we found that the names “UPX0”, “UPX1” and “.rsrc” can be found in the headers of UPX compressed executables[3]by default. Based on this information, we wrote a custom yar rule to find the typical header information from a UPX packed executable:
rule upx_find
{
strings:
$upx0 = "upx0" nocase
$upx1 = "upx1" nocase
$rsrc = ".rsrc" nocase
condition:
$upx0 and $upx1 and $rsrc
}
We used malfind to locate and extract the injected executable code. This returned the two rogue lsass.exe processes, as reported by MHL, with PIDs of 868 and 1928. We then ran the command:
./vol.py -f stuxnet.vmem malfind -D outdave4 –Y upx_find.yar
Both processes were a hit for all three UPX header artifacts:
$ ./vol.py -f stuxnet.vmem malfind -D outdave4 -Y upx_find.yar Volatile Systems Volatility Framework 2.0 Name Pid Start End Tag Hits Protect [snip] lsass.exe 868 0x00080000 0xf9fff000 Vad 1 PAGE_EXECUTE_READWRITE Dumped to: out5/lsass.exe.1e498c8.00080000-000f9fff.dmp YARA rule: upx_find Hit: UPX0 0x00080200 55 50 58 30 00 00 00 00 00 d0 0b 00 00 10 00 00 UPX0............ 0x00080210 00 00 00 00 00 04 00 00 00 00 00 00 00 00 00 00 ................ 0x00080220 00 00 00 00 80 00 00 e0 55 50 58 31 00 00 00 00 ........UPX1.... 0x00080230 00 90 07 00 00 e0 0b 00 00 8e 07 00 00 04 00 00 ................ 0x00080240 00 00 00 00 00 00 00 00 00 00 00 00 40 00 00 e0 ............@... 0x00080250 2e 72 73 72 63 00 00 00 00 10 00 00 00 70 13 00 .rsrc........p.. 0x00080260 00 08 00 00 00 92 07 00 00 00 00 00 00 00 00 00 ................ 0x00080270 00 00 00 00 40 00 00 c0 00 00 00 00 00 00 00 00 ....@........... Hit: UPX1 0x00080228 55 50 58 31 00 00 00 00 00 90 07 00 00 e0 0b 00 UPX1............ 0x00080238 00 8e 07 00 00 04 00 00 00 00 00 00 00 00 00 00 ................ 0x00080248 00 00 00 00 40 00 00 e0 2e 72 73 72 63 00 00 00 ....@....rsrc... [snip] Hit: .rsrc 0x00080250 2e 72 73 72 63 00 00 00 00 10 00 00 00 70 13 00 .rsrc........p.. [snip]
As you can see, the three aforementioned keywords can be found from this malfind dump, indicating that this file was compressed by means of UPX packing.
Hey guys, glad to see you using volatility and following up on some leads.
I just wanted to point out that any RPC client or server will have RPCRT4.dll loaded, so it not necessarily any indication of malicious activity (much less specific to stuxnet). In fact if you look closer, every process which isn’t already terminated has a copy of RPCRT4.dll loaded.
Furthermore, the RpcSs service is standard to windows, it comes installed and will practically always be running. The rpcapd service is an artifact from once having winpcap (a wireshark dependency) previously installed. So neither of those services are actually related to stuxnet.
If you’re looking for other malware memory samples to play with, there’s a good collection here: http://code.google.com/p/volatility/wiki/SampleMemoryImages.
Hope its useful! Cheers.