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

Getting Started

The memory image we'll be working with is available here. The MD5 of the Stuxnet sample is 74ddc49a7c121a61b8d06c03f92d0c13 (link to ThreatExpert).

Since I plan to run several commands on the same memory image, I'll start by setting environment variables for the file name and profile.

$ export VOLATILITY_LOCATION=file:///memory/stuxnet.vmem
$ export VOLATILITY_PROFILE=WinXPSP3x86

Then I made sure to grab the latest malware.py source code and placed it in Volatility's plugins directory.

Artifact 1: Extra lsass.exe
"a normal Windows XP installation has just one instance of Lsass.exe that the Winlogon process creates when the system boots (Wininit creates it on Windows Vista and higher). The process tree reveals that the two new Lsass.exe instances were both created by Services.exe...the Service Control Manager, which implies that Stuxnet somehow got its code into the Services.exe process." [1]
Based on this statement, you could use the pslist, psscan, or pstree commands. Pslist walks the doubly-linked list of EPROCESS structures starting from PsActiveProcessHead. Psscan uses pool tag scanning. Since we have no reason to believe that Stuxnet uses DKOM for process hiding, I won't use psscan. Pstree inherits from pslist (see the Volatility 2.0 Inheritance Graph) and is probably best since it shows a visual parent/child relationship.
$ ./vol.py pstree
Volatile Systems Volatility Framework 2.0
Name                                        Pid    PPid   Thds   Hnds   Time  
 0x823C8830:System                               4      0     59    403 1970-01-01 00:00:00       
. 0x820DF020:smss.exe                          376      4      3     19 2010-10-29 17:08:53       
.. 0x821A2DA0:csrss.exe                        600    376     11    395 2010-10-29 17:08:54       
.. 0x81DA5650:winlogon.exe                     624    376     19    570 2010-10-29 17:08:54       
... 0x82073020:services.exe                    668    624     21    431 2010-10-29 17:08:54       
.... 0x81FE52D0:vmtoolsd.exe                  1664    668      5    284 2010-10-29 17:09:05       
..... 0x81C0CDA0:cmd.exe                       968   1664      0 ------ 2011-06-03 04:31:35       
...... 0x81F14938:ipconfig.exe                 304    968      0 ------ 2011-06-03 04:31:35       
.... 0x822843E8:svchost.exe                   1032    668     61   1169 2010-10-29 17:08:55       
..... 0x822B9A10:wuauclt.exe                   976   1032      3    133 2010-10-29 17:12:03       
..... 0x820ECC10:wscntfy.exe                  2040   1032      1     28 2010-10-29 17:11:49       
.... 0x81E61DA0:svchost.exe                    940    668     13    312 2010-10-29 17:08:55       
.... 0x81DB8DA0:svchost.exe                    856    668     17    193 2010-10-29 17:08:55       
..... 0x81FA5390:wmiprvse.exe                 1872    856      5    134 2011-06-03 04:25:58       
.... 0x821A0568:VMUpgradeHelper               1816    668      3     96 2010-10-29 17:09:08       
.... 0x81FEE8B0:spoolsv.exe                   1412    668     10    118 2010-10-29 17:08:56       
.... 0x81FF7020:svchost.exe                   1200    668     14    197 2010-10-29 17:08:55       
.... 0x81C47C00:lsass.exe                     1928    668      4     65 2011-06-03 04:26:55       
.... 0x81E18B28:svchost.exe                   1080    668      5     80 2010-10-29 17:08:55       
.... 0x8205ADA0:alg.exe                        188    668      6    107 2010-10-29 17:09:09       
.... 0x823315D8:vmacthlp.exe                   844    668      1     25 2010-10-29 17:08:55       
.... 0x81E0EDA0:jqs.exe                       1580    668      5    148 2010-10-29 17:09:05       
.... 0x81C498C8:lsass.exe                      868    668      2     23 2011-06-03 04:26:55       
.... 0x82279998:imapi.exe                      756    668      4    116 2010-10-29 17:11:54       
... 0x81E70020:lsass.exe                       680    624     19    342 2010-10-29 17:08:54 
As you can see, the two lsass.exe processes that started on 2011-06-03 have a parent pid of 668, which belongs to services.exe. However the real lsass.exe (pid 680) has a parent pid of 624 which belongs to winlogon.exe. Given the method used to start the two malicious lsass.exe processes, their SIDs also match the legit copy...which you can verify with getsids.
$ ./vol.py getsids -p 680,868,1928
Volatile Systems Volatility Framework 2.0
lsass.exe (680): S-1-5-18 (Local System)
lsass.exe (680): S-1-5-32-544 (Administrators)
lsass.exe (680): S-1-1-0 (Everyone)
lsass.exe (680): S-1-5-11 (Authenticated Users)
lsass.exe (868): S-1-5-18 (Local System)
lsass.exe (868): S-1-5-32-544 (Administrators)
lsass.exe (868): S-1-1-0 (Everyone)
lsass.exe (868): S-1-5-11 (Authenticated Users)
lsass.exe (1928): S-1-5-18 (Local System)
lsass.exe (1928): S-1-5-32-544 (Administrators)
lsass.exe (1928): S-1-1-0 (Everyone)
lsass.exe (1928): S-1-5-11 (Authenticated Users)
Artifact 2: Process Priority
"...some Windows system processes (such as the Session Manager, service controller, and local security authentication server) have a base process priority slightly higher than the default for the Normal class (8)." - Windows Internals 5th Edition pg. 395
In other words, the legit local security authentication server (lsass.exe) will have a higher priority than normal processes, including those created by Stuxnet. The process base priority is stored in EPROCESS.Pcb.BasePriority. Although there isn't necessarily a plugin already written to extract the BasePriority field, the data is very easy to access in Volatility, as opposed to some GUI tools which only show you select fields from EPROCESS. For example, just use a little volshell scripting.
$ ./vol.py volshell 
Volatile Systems Volatility Framework 2.0
Current context: process System, pid=4, ppid=0 DTB=0x319000
Leopard libedit detected.
Welcome to volshell! Current memory image is:
file:////memory/stuxnet.vmem
To get help, type 'hh()'

In [1]: for proc in win32.tasks.pslist(self.addrspace):
....:     if proc.UniqueProcessId in (680, 868, 1928):
....:         print "Pid: {0} Priority: {1}".format(proc.UniqueProcessId, proc.Pcb.BasePriority)
....:
Pid: 680 Priority: 9
Pid: 868 Priority: 8
Pid: 1928 Priority: 8
As you can see, the BasePriority of the legit lsass.exe (pid 680) is 9, whereas the ones created by Stuxnet are 8. It is possible to change the priority by using SetPriorityClass, but Stuxnet doesn't bother to do so. Also, since the base priority of threads is inherited from the base priority of the process which owns the thread (unless SetThreadPriority is called), then the differences should be visible using the threads command.

Take a look at a thread owned by the legit lsass.exe (Tid 1768) and a thread owned by a malicious lsass.exe (Tid 764).
$ ./vol.py threads 
[snip] 
------
ETHREAD: 0x822722d0 Pid: 680 Tid: 1768
Tags: HookedSSDT
Created: 2010-10-29 17:09:05 
Exited: -
Owning Process: 0x81e70020 'lsass.exe'
Attached Process: 0x81e70020 'lsass.exe'
State: Waiting:UserRequest
BasePriority: 0x9
Priority: 0x9TEB: 0x7ffa0000
StartAddress: 0x7c8106e9 
ServiceTable: 0x80552fa0
   [0] 0x80501b8c
       [0x19] NtClose 0xb240f80e PROCMON20.SYS
       [0x29] NtCreateKey 0xb240f604 PROCMON20.SYS
       [0x3f] NtDeleteKey 0xb240f4ac PROCMON20.SYS
       [0x41] NtDeleteValueKey 0xb240f4f2 PROCMON20.SYS
       [0x47] NtEnumerateKey 0xb240f3f2 PROCMON20.SYS
       [0x49] NtEnumerateValueKey 0xb240f34e PROCMON20.SYS
       [0x4f] NtFlushKey 0xb240f446 PROCMON20.SYS
       [0x62] NtLoadKey 0xb240f972 PROCMON20.SYS
       [0x77] NtOpenKey 0xb240f7d0 PROCMON20.SYS
       [0xa0] NtQueryKey 0xb240f03e PROCMON20.SYS
       [0xb1] NtQueryValueKey 0xb240f166 PROCMON20.SYS
       [0xf7] NtSetValueKey 0xb240f28a PROCMON20.SYS
       [0x107] NtUnloadKey 0xb240fac2 PROCMON20.SYS
   [1] -
   [2] -
   [3] -
 Win32Thread: 0x00000000
 CrossThreadFlags: 

------
ETHREAD: 0x81f44730 Pid: 1928 Tid: 764
Tags: HookedSSDT
Created: 2011-06-03 04:26:55 
Exited: -
Owning Process: 0x81c47c00 'lsass.exe'
Attached Process: 0x81c47c00 'lsass.exe'
State: Waiting:UserRequest
BasePriority: 0x8
Priority: 0x8TEB: 0x7ffdb000
StartAddress: 0x7c8106e9 
ServiceTable: 0x80552f60
  [0] 0x80501b8c
      [0x19] NtClose 0xb240f80e PROCMON20.SYS
      [0x29] NtCreateKey 0xb240f604 PROCMON20.SYS
      [0x3f] NtDeleteKey 0xb240f4ac PROCMON20.SYS
      [0x41] NtDeleteValueKey 0xb240f4f2 PROCMON20.SYS
      [0x47] NtEnumerateKey 0xb240f3f2 PROCMON20.SYS
      [0x49] NtEnumerateValueKey 0xb240f34e PROCMON20.SYS
      [0x4f] NtFlushKey 0xb240f446 PROCMON20.SYS
      [0x62] NtLoadKey 0xb240f972 PROCMON20.SYS
      [0x77] NtOpenKey 0xb240f7d0 PROCMON20.SYS
      [0xa0] NtQueryKey 0xb240f03e PROCMON20.SYS
      [0xb1] NtQueryValueKey 0xb240f166 PROCMON20.SYS
      [0xf7] NtSetValueKey 0xb240f28a PROCMON20.SYS
      [0x107] NtUnloadKey 0xb240fac2 PROCMON20.SYS
  [1] 0xbf999b80
  [2] -
  [3] -
Win32Thread: 0xe126ceb0
CrossThreadFlags: 
The BasePriority 0x9 you see for Tid 1768 is because the parent process (legit lsass.exe) has BasePriority 0x9 (slightly above normal). The BasePriority 0x8 you see for Tid 764 is because the parent process (Stuxnet lsass.exe) has BasePriority 0x8 (Normal).

This isn't a strong artifact, since threads can dynamically change priority, but its an artifact nonetheless.

Lastly, it is worth noting that Stuxnet's kernel driver injects DLLs into processes by using the KeStackAttachProcess API. So if you happen to dump memory during one of the injection procedures, you'll also see in the threads output that the owning process is different from the attached process.

Artifact 3: Too Few DLLs

"...besides running as children of Services.exe, another suspicious characteristic of the two superfluous processes is the fact that they have very few DLLs loaded..." [1]
Based on this statement, you can use dlllist with the -p parameter to focus only on certain processes. In this case, we're interested in comparing pids 680 (legit), 868 (bad), and 1928 (bad).
$ ./vol.py dlllist -p 680,868,1928
Volatile Systems Volatility Framework 2.0
************************************************************************
lsass.exe pid:    680
Command line : -
Service Pack 3

Base         Size         Path
0x01000000   0x006000     
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
0x75730000   0x0b5000     C:\WINDOWS\system32\LSASRV.dll
[snip - about 60 others]
************************************************************************
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
0x00870000   0x138000     C:\WINDOWS\system32\KERNEL32.DLL.ASLR.0360b7ab
[snip - about 20 others]
This output supports Mark's findings that the malicious lsass.exe processes have far fewer DLLs loaded than the legit copy. Its worth mentioning that the malicious processes also have less open files and registry keys - which you can verify with the handles command (we'll use this command later).

Artifact 4: Injected Code

"No non-Microsoft DLLs show up in the loaded-module lists for Services.exe, Lsass.exe or Explorer.exe, so they are probably hosting injected executable code. [....] Sure enough, the legitimate Lsass has no executable data regions, but both new Lsass processes have regions with Execute and Write permissions in their address spaces at the same location and same size." [1]
Based on this statement, you can use malfind to automatically locate and extract the injected executable code.
$ ./vol.py malfind -D out 
Volatile Systems Volatility Framework 2.0
Name                 Pid    Start      End        Tag    Hits Protect
lsass.exe            868 0x00080000 0x000F9FFF Vad       0      6 (MM_EXECUTE_READWRITE)
Dumped to: out/lsass.exe.1e498c8.00080000-000f9fff.dmp
0x00080000   4d 5a 90 00 03 00 00 00 04 00 00 00 ff ff 00 00    MZ..............
0x00080010   b8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00    ........@.......
0x00080020   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
0x00080030   00 00 00 00 00 00 00 00 00 00 00 00 08 01 00 00    ................
0x00080040   0e 1f ba 0e 00 b4 09 cd 21 b8 01 4c cd 21 54 68    ........!..L.!Th
0x00080050   69 73 20 70 72 6f 67 72 61 6d 20 63 61 6e 6e 6f    is program canno
0x00080060   74 20 62 65 20 72 75 6e 20 69 6e 20 44 4f 53 20    t be run in DOS 
0x00080070   6d 6f 64 65 2e 0d 0d 0a 24 00 00 00 00 00 00 00    mode....$.......

lsass.exe           1928 0x00080000 0x000F9FFF Vad       0      6 (MM_EXECUTE_READWRITE)
Dumped to: out/lsass.exe.1e47c00.00080000-000f9fff.dmp
0x00080000   4d 5a 90 00 03 00 00 00 04 00 00 00 ff ff 00 00    MZ..............
0x00080010   b8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00    ........@.......
0x00080020   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
0x00080030   00 00 00 00 00 00 00 00 00 00 00 00 08 01 00 00    ................
0x00080040   0e 1f ba 0e 00 b4 09 cd 21 b8 01 4c cd 21 54 68    ........!..L.!Th
0x00080050   69 73 20 70 72 6f 67 72 61 6d 20 63 61 6e 6e 6f    is program canno
0x00080060   74 20 62 65 20 72 75 6e 20 69 6e 20 44 4f 53 20    t be run in DOS 
0x00080070   6d 6f 64 65 2e 0d 0d 0a 24 00 00 00 00 00 00 00    mode....$.......
Malfind located two suspicious regions, at 0x80000 base address in both processes. They have MM_EXECUTE_READWRITE permissions and start with MZ, meaning a PE is likely stored here. My usual next step is to try and find out where the injected code came from. Is it mapped to some file on disk? You can use vadinfo to see more granular details about the memory segment:
$ ./vol.py vadinfo -p 868 
[snip]

VAD node @822e7e70 Start 00080000 End 000f9fff Tag Vad 
Flags: 
Commit Charge: 0 Protection: 6
ControlArea @81de9890 Segment e2b7dbf0
Dereference list: Flink 00000000, Blink 00000000
NumberOfSectionReferences:          0 NumberOfPfnReferences:           0
NumberOfMappedViews:                1 NumberOfUserReferences:          1
WaitingForDeletion Event:  00000000
Flags: Commit, HadUserReference
FileObject: none
First prototype PTE: e2b7dc30 Last contiguous PTE: e2b7dff8
Flags2: Inherit
You can tell the memory isn't backed by a file because the FileObject pointer is none/NULL. It would be backed by a file if the PE was loaded via LoadLibrary. More on this in the next artifact.

Artifact 5: Hidden DLLs

"Stuxnet calls LoadLibrary with a specially crafted file name that does not exist on disk and normally causes LoadLibrary to fail. However, W32.Stuxnet has hooked Ntdll.dll to monitor for requests to load specially crafted file names. These specially crafted filenames are mapped to another location instead—a location specified by W32.Stuxnet. That location is generally an area in memory where a .dll file has been decrypted and stored by the threat previously. The filenames used have the pattern of KERNEL32.DLL.ASLR.[HEXADECIMAL]..." [4]
Based on this statement, you can use the dlllist command to view the evidence. Even though the file doesn't exist on disk *and* the malware hooks the DLL loading APIs, the file name will still end up in the PEB lists.
$ ./vol.py dlllist | grep ASLR
Volatile Systems Volatility Framework 2.0
Base         Size         Path0x013f0000   0x138000     C:\WINDOWS\system32\KERNEL32.DLL.ASLR.0360c5e2
0x00d00000   0x138000     C:\WINDOWS\system32\KERNEL32.DLL.ASLR.0360c8ee
0x00870000   0x138000     C:\WINDOWS\system32\KERNEL32.DLL.ASLR.0360b7ab
For a different perspective, you can use the ldrmodules plugin. This is useful if you don't preemptively know to search for "ASLR" or any predictable file name. This plugin compares the PE files in memory with mapped files and the 3 DLL lists in the PEB. This is one of my favorite artifacts, because Stuxnet actually uses 3 different types of code injection - all of which are visible (and distinguishable from each other) by using a simpe command:
$ ./vol.py ldrmodules -p 1928
Volatile Systems Volatility Framework 2.0
Pid      Process              Base     InLoad   InInit   InMem    Path
  1928 lsass.exe            0x00080000      0      0      0 -
  1928 lsass.exe            0x7C900000      1      1      1 \WINDOWS\system32\ntdll.dll
  1928 lsass.exe            0x773D0000      1      1      1 \WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.5512_x-ww_35d4ce83\comctl32.dll
  1928 lsass.exe            0x77F60000      1      1      1 \WINDOWS\system32\shlwapi.dll
  1928 lsass.exe            0x771B0000      1      1      1 \WINDOWS\system32\wininet.dll
  1928 lsass.exe            0x77A80000      1      1      1 \WINDOWS\system32\crypt32.dll
  1928 lsass.exe            0x77FE0000      1      1      1 \WINDOWS\system32\secur32.dll
  1928 lsass.exe            0x77C00000      1      1      1 \WINDOWS\system32\version.dll
  1928 lsass.exe            0x01000000      1      0      1 -
  1928 lsass.exe            0x5B860000      1      1      1 \WINDOWS\system32\netapi32.dll
  1928 lsass.exe            0x77E70000      1      1      1 \WINDOWS\system32\rpcrt4.dll
  1928 lsass.exe            0x71AB0000      1      1      1 \WINDOWS\system32\ws2_32.dll
  1928 lsass.exe            0x71AD0000      1      1      1 \WINDOWS\system32\wsock32.dll
  1928 lsass.exe            0x774E0000      1      1      1 \WINDOWS\system32\ole32.dll
  1928 lsass.exe            0x7E410000      1      1      1 \WINDOWS\system32\user32.dll
  1928 lsass.exe            0x77F10000      1      1      1 \WINDOWS\system32\gdi32.dll
  1928 lsass.exe            0x77120000      1      1      1 \WINDOWS\system32\oleaut32.dll
  1928 lsass.exe            0x76D60000      1      1      1 \WINDOWS\system32\iphlpapi.dll
  1928 lsass.exe            0x769C0000      1      1      1 \WINDOWS\system32\userenv.dll
  1928 lsass.exe            0x7C800000      1      1      1 \WINDOWS\system32\kernel32.dll
  1928 lsass.exe            0x76BF0000      1      1      1 \WINDOWS\system32\psapi.dll
  1928 lsass.exe            0x77C10000      1      1      1 \WINDOWS\system32\msvcrt.dll
  1928 lsass.exe            0x77DD0000      1      1      1 \WINDOWS\system32\advapi32.dll
  1928 lsass.exe            0x7C9C0000      1      1      1 \WINDOWS\system32\shell32.dll
  1928 lsass.exe            0x00870000      1      1      1 -
  1928 lsass.exe            0x76F20000      1      1      1 \WINDOWS\system32\dnsapi.dll
  1928 lsass.exe            0x5D090000      1      1      1 \WINDOWS\system32\comctl32.dll
  1928 lsass.exe            0x71AA0000      1      1      1 \WINDOWS\system32\ws2help.dll
  1928 lsass.exe            0x77B20000      1      1      1 \WINDOWS\system32\msasn1.dll
The three lines in red are either suspicious because an entry is missing from one of the 3 PEB lists or because the path name is blank. From top to bottom, you first see the PE at 0x80000 which we have already identified as injected code in artifact 4. It wasn't loaded with LoadLibrary so its not in any of the 3 PEB lists. Its not backed by a file, so the path is blank. Most likely, this is code injected via VirtualAlloc(Ex) and WriteProcessMemory.

The PE at 0x01000000 is interesting, because there is an entry for it in 2 of the 3 DLL lists (missing from the Init list), yet it isn't backed by a file. In normal cases, a program's main module (the .exe) will be backed by a file. So the question becomes: is 0x01000000 the ImageBase of the main module? To see, you can run ldrmodules using the -v (verbose) flag.
$ ./vol.py ldrmodules -p 1928 -v 
Volatile Systems Volatility Framework 2.0
Pid      Process              Base     InLoad   InInit   InMem    Path
1928 lsass.exe            0x00080000      0      0      0 -
1928 lsass.exe            0x01000000      1      0      1 -
     Load Path: C:\WINDOWS\system32\lsass.exe : lsass.exe
     Mem Path:  C:\WINDOWS\system32\lsass.exe : lsass.exe
1928 lsass.exe            0x00870000      1      1      1 -
     Load Path: C:\WINDOWS\system32\KERNEL32.DLL.ASLR.0360b7ab : KERNEL32.DLL.ASLR.0360b7ab
     Init Path: C:\WINDOWS\system32\KERNEL32.DLL.ASLR.0360b7ab : KERNEL32.DLL.ASLR.0360b7ab
     Mem Path:  C:\WINDOWS\system32\KERNEL32.DLL.ASLR.0360b7ab : KERNEL32.DLL.ASLR.0360b7ab
This confirms that 0x01000000 is the ImageBase for the main module, C:\WINDOWS\system32\lsass.exe. So then why is the path blank, indicating that the memory isn't backed by a file? We may be looking at a hollow process situation. You can confirm by using procexedump or procmemdump to extract whatever exists in this memory region and compare it with the legit lsass.exe.
$ ./vol.py procexedump -p 680,868,1928 -D out 
Volatile Systems Volatility Framework 2.0
************************************************************************
Dumping lsass.exe, pid:    680 output: executable.680.exe
************************************************************************
Dumping lsass.exe, pid:    868 output: executable.868.exe
************************************************************************
Dumping lsass.exe, pid:   1928 output: executable.1928.exe
Here are the strings (ANSI only) from the legit lsass.exe:
$ strings out/executable.680.exe 
!This program cannot be run in DOS mode.
Rich
.text
`.data
.rsrc
ADVAPI32.dll
KERNEL32.dll
NTDLL.DLL
LSASRV.dll
SAMSRV.dll
Here are the strings from one of the malicious lsass.exe:
$ strings out/executable.868.exe 
!This program cannot be run in DOS mode.
Rich
.verif
.text
.bin
.reloc
ZwMapViewOfSection 
ZwCreateSection
ZwOpenFile 
ZwClose
ZwQueryAttributesFile
ZwQuerySection
TerminateProcess
GetCurrentProcess
CloseHandle
WaitForSingleObject
OpenProcess
ExitProcess
CreateThread
SetUnhandledExceptionFilter
SetErrorMode
KERNEL32.dll
AdjustTokenPrivileges
LookupPrivilegeValueW
OpenProcessToken
ADVAPI32.dll
VirtualProtect
GetModuleHandleW
GetCurrentThreadId
GetTickCount
lstrcpyW
lstrlenW
GetProcAddress
wsprintfW
USER32.dll
As you can see, the content of the alleged lsass.exe binary is clearly different. This is in fact the effect of process hollowing - the second type of code injection used by Stuxnet. The names of the APIs in red are the ones hooked by the malware (see Artifact 6) and the others are probably from the file's Import Address Table.

Lastly, the PE at 0x00870000 named KERNEL32.DLL.ASLR.0360b7ab also is not backed by a file on disk, but its in all 3 DLL lists. That's because this is the "hidden" DLL that is never written to disk (an attempt to evade antivirus). That is the third type of code injection / DLL hiding implemented by Stuxnet.

Artifact 6: Hooked APIs

"The functions hooked for this purpose in Ntdll.dll are:

* ZwMapViewOfSection
* ZwCreateSection
* ZwOpenFile
* ZwCloseFile
* ZwQueryAttributesFile
* ZwQuerySection" [4]
Based on this statement, you can use the apihooks plugin to detect what Symantec is describing.
$ ./vol.py apihooks 
Volatile Systems Volatility Framework 2.0
Name                             Type     Target                                   Value
services.exe[668]                syscall  ntdll.dll!NtClose[0x7c90cfd0]            0x7c900050 MOV EDX, 0x7c900050 (UNKNOWN)
services.exe[668]                syscall  ntdll.dll!NtCreateSection[0x7c90d160]    0x7c900048 MOV EDX, 0x7c900048 (UNKNOWN)
services.exe[668]                syscall  ntdll.dll!NtMapViewOfSection[0x7c90d500] 0x7c900044 MOV EDX, 0x7c900044 (UNKNOWN)
services.exe[668]                syscall  ntdll.dll!NtOpenFile[0x7c90d580]         0x7c90004c MOV EDX, 0x7c90004c (UNKNOWN)
services.exe[668]                syscall  ntdll.dll!NtQueryAttributesFile[0x7c90d6f0] 0x7c900054 MOV EDX, 0x7c900054 (UNKNOWN)
services.exe[668]                syscall  ntdll.dll!NtQuerySection[0x7c90d8b0]     0x7c900058 MOV EDX, 0x7c900058 (UNKNOWN)
services.exe[668]                syscall  ntdll.dll!ZwClose[0x7c90cfd0]            0x7c900050 MOV EDX, 0x7c900050 (UNKNOWN)
services.exe[668]                syscall  ntdll.dll!ZwCreateSection[0x7c90d160]    0x7c900048 MOV EDX, 0x7c900048 (UNKNOWN)
services.exe[668]                syscall  ntdll.dll!ZwMapViewOfSection[0x7c90d500] 0x7c900044 MOV EDX, 0x7c900044 (UNKNOWN)
services.exe[668]                syscall  ntdll.dll!ZwOpenFile[0x7c90d580]         0x7c90004c MOV EDX, 0x7c90004c (UNKNOWN)
services.exe[668]                syscall  ntdll.dll!ZwQueryAttributesFile[0x7c90d6f0] 0x7c900054 MOV EDX, 0x7c900054 (UNKNOWN)
services.exe[668]                syscall  ntdll.dll!ZwQuerySection[0x7c90d8b0]     0x7c900058 MOV EDX, 0x7c900058 (UNKNOWN)
[snip]
If there are 6 hooked APIs, why are there 12 lines of output? Since Ntdll.dll exports each function twice (one for Nt* and one for Zw*), the apihooks plugin shows them both. Also, it is apparent that Stuxnet uses the "syscall" hooking technique similar to Carberp instead of the more common Inline/IAT/EAT hooking. To interactively explore code around the hook address, use the volshell command. This time we'll use it to follow the flow of execution when a hooked API is called.

First you need to break into the shell and switch into the context of a process that has been hooked. Then navigate to the hooked API. I'll start with ZwClose which is at 0x7C90cfd0.
$ ./vol.py volshell
Volatile Systems Volatility Framework 2.0
Current context: process System, pid=4, ppid=0 DTB=0x319000
Welcome to volshell! Current memory image is:
file:///memory/stuxnet.vmem
To get help, type 'hh()'
>>> cc(pid=668)
Current context: process services.exe, pid=668, ppid=624 DTB=0xa940080
>>> dis(0x7c90cfd0)
0x7c90cfd0 b819000000                       MOV EAX, 0x19
0x7c90cfd5 ba5000907c                       MOV EDX, 0x7c900050
0x7c90cfda ffd2                             CALL EDX
0x7c90cfdc c20400                           RET 0x4
0x7c90cfdf 90                               NOP
0x7c90cfe0 b81a000000                       MOV EAX, 0x1a
0x7c90cfe5 ba0003fe7f                       MOV EDX, 0x7ffe0300
0x7c90cfea ff12                             CALL DWORD [EDX]
0x7c90cfec c20c00                           RET 0xc
0x7c90cfef 90                               NOP
[snip]
When comparing the instructions in red (which belong to ZwClose) with the instructions in purple (which belong to an API not hooked by Stuxnet, you see that a different value is placed in EDX. The clean API calls the DWORD at 0x7ffe0300 (see the system call dispatcher on x86). The hooked API calls 0x7c900050. So that is our next hop when following the rootkit, and what we see next will be interesting.
>>> dis(0x7c900050)
0x7c900050 b203                             MOV DL, 0x3
0x7c900052 eb08                             JMP 0x7c90005c
0x7c900054 b204                             MOV DL, 0x4
0x7c900056 eb04                             JMP 0x7c90005c
0x7c900058 b205                             MOV DL, 0x5
0x7c90005a eb00                             JMP 0x7c90005c
0x7c90005c 52                               PUSH EDX
0x7c90005d e804000000                       CALL 0x7c900066
0x7c900062 f20094005aff2269                 ADD [EAX+EAX+0x6922ff5a], DL
0x7c90006a 6e                               OUTS DX, [ESI]
0x7c90006b 20444f53                         AND [EDI+ECX*2+0x53], AL
0x7c90006f 206d6f                           AND [EBP+0x6f], CH
0x7c900072 64652e0d0d0a2400                 OR EAX, 0x240a0d
0x7c90007a 0000                             ADD [EAX], AL
0x7c90007c 0000                             ADD [EAX], AL
0x7c90007e 0000                             ADD [EAX], AL
At 0x7c90005d there is a CALL to 0x7c900066. But according to the disassembly, 0x7c900066 is in the middle of the instruction that starts at 0x7c900062. Its possible that this is an anti-disassembling trick (see the Anti-Disassembling section of MindshaRE: Anti-Reversing Techniques) but either way, all we have to do is re-align the disassembly engine by telling it to start at 0x7c900066.
>>> dis(0x7c900066)
0x7c900066 5a                               POP EDX
0x7c900067 ff22                             JMP DWORD [EDX]
Ah, that's better! So when the CALL at 0x7c90005d is executed, its return address (0x7c900062) is pushed onto the stack. The POP EDX instruction at 0x7c900066 then removes that value from the stack and places it in EDX. At 0x7c900067, EDX is dereferenced and called. So the pointer being dereferenced is 0x7c900062. The 4 bytes at that address are highlighted in red above - f2009400. Given endiannes, this is actually 0x009400F2 - our official next hop in following the rootkit.
>>> dis(0x009400F2)
0x9400f2 5a                               POP EDX
0x9400f3 84d2                             TEST DL, DL
0x9400f5 7425                             JZ 0x94011c
0x9400f7 feca                             DEC DL
0x9400f9 0f8482000000                     JZ 0x940181
0x9400ff feca                             DEC DL
0x940101 0f84bb000000                     JZ 0x9401c2
0x940107 feca                             DEC DL
0x940109 0f84fe000000                     JZ 0x94020d
0x94010f feca                             DEC DL
0x940111 0f8440010000                     JZ 0x940257
0x940117 e98c010000                       JMP 0x9402a8
0x94011c e8f9010000                       CALL 0x94031a
[snip]
0x9401ad  8d542408                             LEA EDX, [ESP+0x8]
0x9401b1  cd2e                                 INT 0x2e
By analyzing the code at this location, you can begin to understand the exact purpose of the hook. However, from Artifact 5 we already know the purpose is to support loading DLLs that don't exist on disk.

The instructions in red show how the malware eventually calls the requested system service. It uses the IDT instead of the SSDT. Although Windows itself doesn't use the IDT for system service dispatching anymore (that stopped with Windows 2000), the IDT was still kept around for backward capability. This begs the question...are any other DLLs on my system still using the IDT? How unique is the byte pattern for the instructions in red?

To find out, you can search process memory for 8D 54 24 ?? CD 2E where ?? is a wildcard. In the output below, two memory regions tested positive. 0x00940000 shouldn't be surprising since that's the source of our signature. But 0x013F0000 also contains the pattern.
$ ./vol.py malfind -p 668 -D out -Y "{8D 54 24 ?? CD 2E}" 
Volatile Systems Volatility Framework 2.0
Name                 Pid    Start      End        Tag    Hits Protect
services.exe            668 0x00940000 0x00940FFF Vad       1      6 (MM_EXECUTE_READWRITE)
Dumped to: out/services.exe.2273020.00940000-00940fff.dmp

YARA rule: z1
Hit: 8d542408cd2e
0x00940145   8d 54 24 08 cd 2e eb 0c 5a 8d 54 24 08 64 ff 15    .T$.....Z.T$.d..
0x00940155   c0 00 00 00 85 c0 75 23 e8 b8 01 00 00 85 d2 74    ......u#.......t

Hit: 8d542408cd2e
0x009401ad   8d 54 24 08 cd 2e eb 0c 5a 8d 54 24 08 64 ff 15    .T$.....Z.T$.d..
0x009401bd   c0 00 00 00 c3 e8 53 01 00 00 85 d2 74 20 50 57    ......S.....t PW

Hit: 8d542408cd2e
0x009401f8   8d 54 24 08 cd 2e eb 0c 5a 8d 54 24 08 64 ff 15    .T$.....Z.T$.d..
0x00940208   c0 00 00 00 c3 81 7c 24 08 ae 82 19 ae 75 03 33    ......|$.....u.3

Hit: 8d542408cd2e
0x00940242   8d 54 24 08 cd 2e eb 0c 5a 8d 54 24 08 64 ff 15    .T$.....Z.T$.d..
0x00940252   c0 00 00 00 c3 e8 be 00 00 00 85 d2 74 26 50 52    ............t&PR

Hit: 8d542408cd2e
0x00940293   8d 54 24 08 cd 2e eb 0c 5a 8d 54 24 08 64 ff 15    .T$.....Z.T$.d..
0x009402a3   c0 00 00 00 c3 e8 6d 00 00 00 85 d2 52 74 45 8b    ......m.....RtE.

Hit: 8d542408cd2e
0x00940305   8d 54 24 08 cd 2e eb 0c 5a 8d 54 24 08 64 ff 15    .T$.....Z.T$.d..
0x00940315   c0 00 00 00 c3 50 56 57 51 52 83 ec 1c 8b c4 6a    .....PVWQR.....j

services.exe            668 0x013F0000 0x01527FFF Vad       1      6 (MM_EXECUTE_READWRITE)
Dumped to: out/services.exe.2273020.013f0000-01527fff.dmp
YARA rule: z1
Hit: 8d542408cd2e
0x0144782e   8d 54 24 08 cd 2e eb 0c 5a 8d 54 24 08 64 ff 15    .T$.....Z.T$.d..
0x0144783e   c0 00 00 00 85 c0 75 23 e8 b8 01 00 00 85 d2 74    ......u#.......t

Hit: 8d542408cd2e
0x01447896   8d 54 24 08 cd 2e eb 0c 5a 8d 54 24 08 64 ff 15    .T$.....Z.T$.d..
0x014478a6   c0 00 00 00 c3 e8 53 01 00 00 85 d2 74 20 50 57    ......S.....t PW

Hit: 8d542408cd2e
0x014478e1   8d 54 24 08 cd 2e eb 0c 5a 8d 54 24 08 64 ff 15    .T$.....Z.T$.d..
0x014478f1   c0 00 00 00 c3 81 7c 24 08 ae 82 19 ae 75 03 33    ......|$.....u.3

Hit: 8d542408cd2e
0x0144792b   8d 54 24 08 cd 2e eb 0c 5a 8d 54 24 08 64 ff 15    .T$.....Z.T$.d..
0x0144793b   c0 00 00 00 c3 e8 be 00 00 00 85 d2 74 26 50 52    ............t&PR

Hit: 8d542408cd2e
0x0144797c   8d 54 24 08 cd 2e eb 0c 5a 8d 54 24 08 64 ff 15    .T$.....Z.T$.d..
0x0144798c   c0 00 00 00 c3 e8 6d 00 00 00 85 d2 52 74 45 8b    ......m.....RtE.

Hit: 8d542408cd2e
0x014479ee   8d 54 24 08 cd 2e eb 0c 5a 8d 54 24 08 64 ff 15    .T$.....Z.T$.d..
0x014479fe   c0 00 00 00 c3 50 56 57 51 52 83 ec 1c 8b c4 6a    .....PVWQR.....j
As you can see, both memory regions have 6 hits, which coincides with the 6 hooked APIs. But why are there two memory regions in the first place? Well, just guessing here but based on the relative size (140KB to 1KB), the 0x013F0000 region contains the code responsible for installing the API hooks. It allocated and copied a smaller 1KB chunk of itself to 0x00940000.

Artifact 7: Patched PE Header
"To hook the functions specified above, the malware allocates a memory buffer for code that will dispatch calls to hooked functions, overwrite some data in MZ header of the image with the code that transfers control to the new functions, and hook the original functions by overwriting its bodies..." [6]
In the previous artifact you might remember us tracking an address at 0x7c900050. If ntdll.dll's base is 0x7c900000, then the address we're tracking is in the PE header. In order to hide code in ntdll.dll's PE header without breaking anything, Stuxnet overwrites some inconsequential fields including most of the "This program cannot be run in DOS mode" message.

To detect the malicious PE header modification, you can use the following yara rule which alerts on any pages of memory that contain a PE header and that do not contain the "This program cannot..." message. The rule was saved to modified_pe_header.yar.
rule modified_pe_header { 
  strings:
  $msg = "This program cannot"

  condition:
  uint16(0) == 0x5A4D and 
  uint32(uint32(0x3C)) == 0x00004550 and
  not $msg
}
Now scan for the memory with malfind:
$ ./vol.py malfind -D out -Y modified_pe_header.yar 
Volatile Systems Volatility Framework 2.0
Name                 Pid    Start      End        Tag    Hits Protect
services.exe            668 0x7C900000 0x7C9AEFFF Vad       1      7 (MM_EXECUTE_WRITECOPY)
Dumped to: out/services.exe.2273020.7c900000-7c9aefff.dmp
YARA rule: modified_pe_header

svchost.exe             940 0x7C900000 0x7C9AEFFF Vad       1      7 (MM_EXECUTE_WRITECOPY)
Dumped to: out/svchost.exe.2061da0.7c900000-7c9aefff.dmp
YARA rule: modified_pe_header

lsass.exe              1928 0x7C900000 0x7C9AEFFF Vad       1      7 (MM_EXECUTE_WRITECOPY)
Dumped to: out/lsass.exe.1e47c00.7c900000-7c9aefff.dmp
YARA rule: modified_pe_header
The results tell you Stuxnet has modified ntdll.dll in three processes.

Artifact 8: Mutexes

"Stuxnet communicates between different components via global mutexes." [4]

Based on this statement, you can use the mutantscan and/or handles plugins to list mutexes on the system. However, resources indicate that the mutex name can be random (or at least pseudo-random). Without doing the necessary RE to see if there are any detectable patterns in the mutex name, we don't really know what to look for. So how do we find out which mutexes on the system are artifacts of Stuxnet?

Since Stuxnet injects code into services.exe (based on previous findings), there is a good chance that services.exe has an open handle to the mutex, or mutexes. Let's use the handles plugin to filter by object type (Mutant) and process ID, also ignoring un-named mutexes:
$ ./vol.py handles -t Mutant -p 668
Volatile Systems Volatility Framework 2.0
Offset(V)    Pid    Type             Details
0x81ee3968   668    Mutant           'SHIMLIB_LOG_MUTEX'
0x81db23b0   668    Mutant           'ShimCacheMutex'
0x8205fa78   668    Mutant           'PnP_Init_Mutex'
0x81fc3cc0   668    Mutant           '{5EC171BB-F130-4a19-B782-B6E655E091B2}'
0x821b75e0   668    Mutant           '{E41362C3-F75C-4ec2-AF49-3CB6BCA591CA}'
0x81f08b98   668    Mutant           'PrefetchFileCacheOwner'
0x81f78e90   668    Mutant           'Spooler_Perf_Library_Lock_PID_01F'
0x82287600   668    Mutant           '85991EC7-5621-4A6F-9453-DC19BAE9C542'
0x82287600   668    Mutant           '85991EC7-5621-4A6F-9453-DC19BAE9C542'
I've highlighted three of the Stuxnet artifacts in red. But at this point, pretend you still don't know. One advantage of using mutantscan is that it prints the OwnerThread member of each _KMUTANT (if its available). Here is some output to help drive this point home:
$ ./vol.py mutantscan -s 
Volatile Systems Volatility Framework 2.0
Offset     Obj Type   #Ptr #Hnd Signal Thread     CID        Name
0x01e4dbe0 0x823c55e0    2    1      1 0x00000000            '_!SHMSFTHISTORY!_'
0x01e8ab88 0x823c55e0    3    2      1 0x00000000            'c:!documents and settings!administrator!cookies!'
0x02108bb0 0x823c55e0    2    1      0 0x81fc0020 668:568    'PrefetchFileCacheOwner'
0x021c3cd8 0x823c55e0    4    3      1 0x00000000            '{5EC171BB-F130-4a19-B782-B6E655E091B2}'
0x023b75f8 0x823c55e0    2    1      0 0x81c6d180 668:476    '{E41362C3-F75C-4ec2-AF49-3CB6BCA591CA}'
0x0240f300 0x823c55e0    2    1      1 0x00000000            'WPA_LT_MUTEX'
0x0240f350 0x823c55e0    2    1      1 0x00000000            'WPA_RT_MUTEX'
0x0241ef40 0x823c55e0    2    1      1 0x00000000            '.NET CLR Data_Perf_Library_Lock_PID_680'
0x0242d248 0x823c55e0    2    1      0 0x8210d200 1712:1716  'SunJavaUpdateSchedulerMutex'
[snip]
Now we know that thread ID 568 owns the PrefetchFileCacheOwner mutex and thread ID 476 owns the one that starts with "{E41362C3". Windows doesn't track creation time for mutex objects, but it does for thread objects. Let's see when the owning threads were created using the thrdscan command:
$ ./vol.py thrdscan
Volatile Systems Volatility Framework 2.0
Offset     PID    TID    Create Time               Exit Time                 StartAddr
---------- ------ ------ ------------------------- ------------------------- ----------
0x021c0020    668 568    2011-06-03 04:26:55                                 0x7c8106e9
0x01e6d180    668 476    2011-06-03 04:26:55                                 0x7c8106e9
[snip]
Both threads were created at 04:26:55. The two malicious lsass.exe processes discussed in Artifact 1 were also created at 04:26:55. Now we have a direct temporal relationship between the times when Stuxnet spawned the lsass.exe processes, when it injected code into services.exe (resulting in several new threads), and when the mutexes were created.

A few things should be noted. The PrefetchFileCacheOwner is probably not one of the "global mutexes used for communication" - it is one of the side-effects of some action performed by the thread. Second, to confirm my findings, I infected the system with Stuxnet again, this time with a breakpoint set on CreateMutexW inside the services.exe process. Before long, the breakpoint triggered twice:



That's a wrap for this one!

Artifact 9: File Objects
"The final modifications made by the virus include the creation of four additional files in the C:\Windows\Inf directory: Oem7a.pnf, Mdmeric3.pnf, Mdmcpq3.pnf and Oem6c.pnf." [2]
Based on this statement, you can use the handles command to see if any processes currently have open handles to the specified files, or you can use filescan to see if any FILE_OBJECT structures still reside in memory after the malware created them.
$ ./vol.py handles | grep -i .pnf
Volatile Systems Volatility Framework 2.0
$

$ ./vol.py filescan | grep -i .pnf
Volatile Systems Volatility Framework 2.0
0x01dfa028 0x0x823eb040    1    0 R--r-- -          '\\WINDOWS\\inf\\oem7A.PNF'
0x01e0d028 0x0x823eb040    1    0 -WD--- -          '\\WINDOWS\\inf\\mdmeric3.PNF'
0x021b53c8 0x0x823eb040    1    0 RW---- -          '\\WINDOWS\\inf\\mdmcpq3.PNF'
As you can see, the output of the handles command is empty. Either the process that created the PNF files has terminated, or the process has already called CloseHandle. However, filescan can still locate traces of the activity, which is the whole reason filescan exists in the first place. Kudos to filescan!

Artifact 10: Network Connections
"This function [export #28] is responsible for performing actual data exchange with the C&C server. In the event that there is no iexplore.exe in the system, it calls this function from the address space of the default browser: it starts the default browser as a new process, injects into it the main module, and calls the function performing data exchange.

The malware communicates to the C&C server through http. A list of URLs is included in the Stuxnet configuration data of Stuxnet:
  • www.mypremierfutbol.com
  • www.todaysfutbol.com" [6]
This artifact was not present in the initial memory dump. Export #28 (the function referred to in the quote) wasn't called for one reason or another. To elicit the described behavior, I dumped memory a second time, after manually coercing the execution of Export #28. Then using connscan (one of the Networking commands) you can see the evidence:
$ ./vol.py -f stuxnet2.vmem connscan 
Volatile Systems Volatility Framework 2.0
Offset     Local Address             Remote Address            Pid
---------- ------------------------- ------------------------- ------
0x01da9e68 192.168.16.129:1311       128.61.111.9:51442          1280
0x01e4fe68 192.168.16.129:1233       128.61.111.9:21             1280
0x01eeebf0 172.16.237.145:1170       72.167.202.5:80              528
0x020bf4e0 172.16.237.145:1045       96.17.106.99:80             1648
0x0242ec28 172.16.237.145:1048       96.17.106.99:80             1708
0x025069e8 172.16.237.145:1090       137.254.16.78:80             152
The connection in red is suspicious because, as shown below, it was created by a browser process and the IP maps back to one of the C&C domains.
$ ./vol.py -f stuxnet2.vmem pslist
Volatile Systems Volatility Framework 2.0
Offset(V)  Name                 PID    PPID   Thds   Hnds   Time
---------- -------------------- ------ ------ ------ ------ -------------------
[snip]
0x81af13b8 firefox.exe             528    356      4    112 2011-07-20 16:32:09

$ host www.mypremierfutbol.com
www.mypremierfutbol.com is an alias for mypremierfutbol.com.
mypremierfutbol.com has address 72.167.202.5
Perhaps more interesting than the connection itself is the fact that Stuxnet uses a specific message structure for its C&C packets. Each message starts with a 0x1 constant byte and has the OS major version at offset 2, OS minor version at offset 3, OS service pack at offset 4, and so on. That means an XP SP1 system may look like hex "01??050101" and a Windows 7 SP0 may look like "01??060100". A bit more research can help refine these patters even more and before long you can have a Volatility plugin, consisting of a few lines of Python, that finds Stuxnet C&C packets (before encryption) in process memory.

Artifact 11: Registry Keys
"...because we see Lsass.exe drop one of the two Stuxnet drivers, MRxCls.sys, in C:\Windows\System32\Drivers and create its corresponding registry keys" [2]
Based on this statement, we can use printkey to read the cached registry keys in memory. Service registry keys are in the system hive under ControlSet001\Services\SERVICENAME. So based on the article, we know exactly what to look for:
$ ./vol.py printkey -K 'ControlSet001\Services\MrxNet'
Volatile Systems Volatility Framework 2.0
Legend: (S) = Stable   (V) = Volatile

----------------------------
Registry: \Device\HarddiskVolume1\WINDOWS\system32\config\system
Key name: MRxNet (S)
Last updated: 2011-06-03 04:26:47 

Subkeys:
  (V) Enum

Values:
REG_SZ        Description     : (S) MRXNET
REG_SZ        DisplayName     : (S) MRXNET
REG_DWORD     ErrorControl    : (S) 0
REG_SZ        Group           : (S) Network
REG_SZ        ImagePath       : (S) \??\C:\WINDOWS\system32\Drivers\mrxnet.sys
REG_DWORD     Start           : (S) 1
REG_DWORD     Type            : (S) 1

$ ./vol.py printkey -K 'ControlSet001\Services\MrxCls'
Volatile Systems Volatility Framework 2.0
Legend: (S) = Stable   (V) = Volatile

----------------------------
Registry: \Device\HarddiskVolume1\WINDOWS\system32\config\system
Key name: MRxCls (S)
Last updated: 2011-06-03 04:26:47 

Subkeys:
  (V) Enum

Values:
REG_SZ        Description     : (S) MRXCLS
REG_SZ        DisplayName     : (S) MRXCLS
REG_DWORD     ErrorControl    : (S) 0
REG_SZ        Group           : (S) Network
REG_SZ        ImagePath       : (S) \??\C:\WINDOWS\system32\Drivers\mrxcls.sys
REG_DWORD     Start           : (S) 1
REG_DWORD     Type            : (S) 1
REG_BINARY    Data            : (S) 
0000   8F 1F F7 6D 7D B1 C9 09 9D CC 24 7A C6 9F FB 23    ...m}.....$z...#
0010   90 BD 9D BF F1 D4 51 92 2A B4 1F 6A 2E A6 4F B3    ......Q.*..j..O.
0020   CB 69 7C 0B 92 3B 1B C0 D7 75 17 A9 E3 33 48 DC    .i|..;...u...3H.
0030   AD F6 DA EA 2F 87 10 C4 21 81 A5 75 68 00 2E B1    ..../...!..uh...
0040   C2 7B EB DD BB 72 47 DC 87 91 14 A5 F3 C4 32 B0    .{...rG.......2.
0050   CC 93 38 36 6B 49 0A F2 6F 1F 1D A1 4A 15 05 80    ..86kI..o...J...
0060   4B 13 A8 AA 82 41 4B 89 DC 89 24 A2 ED 16 37 F3    K....AK...$...7.
0070   42 A9 A0 6A 7F 82 CD 90 E5 3C 49 CC B2 97 CA CB    B..j.....< span="">
0080   7B 64 C1 48 B2 4C F5 AE 54 42 74 0F 00 31 FD 80    {d.H.L..TBt..1..
0090   E8 7E 0E 69 12 42 3A EC 0F 6F 03 B8 46 9C 68 97    .~.i.B:..o..F.h.
00A0   AC 62 16 FB 1A 1B D9 33 6C E8 F9 93 C3 56 54 A1    .b.....3l....VT.
00B0   89 7A 7B 77 CE BA 0D 95 A7 0F AB 5E 1C 3C 18 63    .z{w.......^.<.c
00C0   AE 3E 60 A6 81 BC FA 85 FB 37 A0 0A 57 F9 C9 D3    .>`......7..W...
00D0   CF 6B 41 D9 6D CD 39 71 C5 11 83 F1 D9 F3 7D B7    .kA.m.9q......}.
00E0   91 F7 70 46 C2 24 F7 B9 0F 2D B2 60 72 1C 8F F9    ..pF.$...-.`r...
00F0   98 16 34 52 4B 7D 5F 81 5F 35 FD 8B 3E 78 B1 0B    ..4RK}_._5..>x..
0100   0A 90 5A D8 30 5A 56 90 9A C0 C1 0F EB 95 D5 2F    ..Z.0ZV......../
0110   B7 C5 8D 2B 3F 49 41 8B 86 B4 DB 71 67 69 E6 E8    ...+?IA....qgi..
0120   69 77 29 77 18 82 11 8B D7 5D 26 E4 5A 5C 2C 46    iw)w.....]&.Z.,F
0130   C2 F0 02 28 D8 EA 4B 95 9C 3A 3C 12 DA C4 87 21    ...(..K..:<....!
0140   91 4F D0 6E FA C4 DD B7 C9 AF E2 AE FE 14 0F 53    .O.n...........S
0150   C4 BA DD 31 1A 38 7B 37 C0 9E 83 FF 2C B2 4C 88    ...1.8{7....,.L.
0160   33 C1 89 E5 CA 68 31 2D 20 CE 50 64 7B 39 C7 FB    3....h1- .Pd{9..
0170   B1 9F A9 0D 6C 2A 82 AE 7F 25 43 A7 A2 28 EB 27    ....l*...%C..(.'
0180   73 C9 45 F9 FD 53 A8 F4 A7 FD B4 90 B2 28 D8 0C    s.E..S.......(..
0190   5A A8 84 D0 7F ED 99 25 18 FE B8 4C 48 66 8D 59    Z......%...LHf.Y
01A0   40 F6 CC 30 A6 F4 04 E8 76 9C EA 0E F6 A4 4A CE    @..0....v.....J.
01B0   D2                                                 .<>
You can see the timestamp from when the registry keys were last modified, the full path on disk to the service binary (the Stuxnet drivers) and the full contents of the encrypted Data value. According to Thabet [5], after decryption "This data contains the name of some system processes and filenames for stuxnet files. This data tells the driver the filename of the stuxnet file and the name of the process that stuxnet needs to inject its file into."

Don't forget you can also use the svcscan command to enumerate services.
$ ./vol.py -f stuxnet.vmem svcscan | grep -i mrx
Volatile Systems Volatility Framework 2.0
0x385d28     0x70     -------- 'MRxDAV'         'WebDav Client Redirector'     SERVICE_FILE_SYSTEM_DRIVER     SERVICE_RUNNING      \FileSystem\MRxDAV
0x385db8     0x71     -------- 'MRxSmb'         'MRxSmb'                       SERVICE_FILE_SYSTEM_DRIVER     SERVICE_RUNNING      \FileSystem\MRxSmb
Why do we only see legitimate services MRxDAV and MRxSmb? Well, just because there are entries in the ControlSet001\Services registry key, that doesn't mean the malware used the Service Control Manager (services.exe) to create or start the service. For example, you can skip calling CreateService and StartService by creating the registry keys directly and then calling NtLoadDriver (which is exactly what Stuxnet does).

Artifact 12: Kernel Drivers
"Mrxnet.sys is the driver that the programmer originally sent me and that implements the rootkit that hides files, and Mrxcls.sys is a second Stuxnet driver file that launches the malware when the system boots." [1]
Based on this statement, the two drivers should be visible with the modules or modscan commands.
$ ./vol.py modules
[snip]
0x81f8cb60 \??\C:\WINDOWS\system32\Drivers\mrxcls.sys         0x00f895a000 0x005000 mrxcls.sys
0x81c2a530 \??\C:\WINDOWS\system32\Drivers\mrxnet.sys         0x00b21d8000 0x003000 mrxnet.sys
Feel free to extract the drivers to disk with moddump for inspection with strings, IDA Pro, or for scanning with your favorite antivirus.

Artifact 13: Kernel Callbacks
"That means Mrxcls.sys called PsSetLoadImageNotifyRoutine so that Windows would call it whenever an executable image, such as a DLL or device driver, is mapped into memory." [3]
Based on this statement, you can use the callbacks command.
$ ./vol.py callbacks
Volatile Systems Volatility Framework 2.0
Type                                 Callback   Owner
PsSetLoadImageNotifyRoutine          0xb240ce4c PROCMON20.SYS
PsSetLoadImageNotifyRoutine          0x805f81a6 ntoskrnl.exe
PsSetLoadImageNotifyRoutine          0xf895ad06 mrxcls.sys
PsSetCreateThreadNotifyRoutine       0xb240cc9a PROCMON20.SYS
PsSetCreateProcessNotifyRoutine      0xf87ad194 vmci.sys
PsSetCreateProcessNotifyRoutine      0xb240cb94 PROCMON20.SYS
KeBugCheckCallbackListHead           0xf83e65ef NDIS.sys (Ndis miniport)
KeBugCheckCallbackListHead           0x806d77cc hal.dll (ACPI 1.0 - APIC platform UP)
KeRegisterBugCheckReasonCallback     0xf8b7aab8 mssmbios.sys (SMBiosData)
KeRegisterBugCheckReasonCallback     0xf8b7aa70 mssmbios.sys (SMBiosRegistry)
[snip]
The output shows the PsSetLoadImageNotifyRoutine installed by mrxcls.sys. Mark also states "Ironically, Process Monitor also uses this callback functionality to monitor image loads." [3] which is why you see the PROCMON20.SYS entries as well.

Artifact 14: FileSystem Hooks
"The driver also registers to a filesystem registration callback routine in order to hook newly created filesystem objects on the fly." [4]
Based on this statement, if the rootkit used IoRegisterFsRegistrationChange to install the file system registration callback routine, then you can use the callbacks plugin to detect it. However, instead it uses IoRegisterDriverReinitialization, which works a bit differently. In particular, it uses different pool tags, a different structure for storing the callback address, and a different symbol name for the list head (nt!_IopDriverReinitializeQueueHead). Extending the callbacks plugin for this purpose is extremely easy. Just take the information shown in the following screen shot and have a look at the other examples in the malware.py source code.


Artifact 15: Devices & IRPs

"The driver scans for the following filesystem driver objects:

* \FileSystem\ntfs
* \FileSystem\fastfat
* \FileSytstem\cdfs

A new device object is created by Stuxnet and attached to the device chain for each device object managed by these driver objects. [...] By inserting such objects, Stuxnet is able to intercept IRP requests (example: writes, reads, to devices NTFS, FAT, or CD-ROM devices)." [4]
Based on this statement, the Stuxnet driver is exploiting Microsoft's layered driver architecture which you can explore with the devicetree plugin. Let's focus on ntfs to start.
$ ./vol.py devicetree 
Volatile Systems Volatility Framework 2.0
[snip]
DRV 0x0253d180 '\\FileSystem\\Ntfs'
DEV 0x8224e020 (unnamed) FILE_DEVICE_DISK_FILE_SYSTEM
ATT 0x8223e6c0 (unnamed) - '\\FileSystem\\sr' FILE_DEVICE_DISK_FILE_SYSTEM
        ATT 0x821d52f0 (unnamed) - '\\Driver\\MRxNet' FILE_DEVICE_DISK_FILE_SYSTEM
DEV 0x8224f790 Ntfs FILE_DEVICE_DISK_FILE_SYSTEM
ATT 0x8223edd0 (unnamed) - '\\FileSystem\\sr' FILE_DEVICE_DISK_FILE_SYSTEM
        ATT 0x820d2350 (unnamed) - '\\Driver\\MRxNet' FILE_DEVICE_DISK_FILE_SYSTEM
You can see that the MRxNet driver has created several devices (via IoCreateDevice) and attached them to the device chain of \FileSystem\Ntfs for filtering purposes. The Fastfat file system is not used on the system, so it isn't shown, but Cdfs is:
DRV 0x01f9cf38 '\\FileSystem\\Cdfs'
DEV 0x81d9cc88 Cdfs FILE_DEVICE_CD_ROM_FILE_SYSTEM
        ATT 0x81ff3d50 (unnamed) - '\\Driver\\MRxNet' FILE_DEVICE_CD_ROM_FILE_SYSTEM
Stuxnet maintains control over network file systems in addition to local disks and CDROMs. In total, it creates and attaches 11 devices. Other targets include vmhgfs (VMware Host/Guest File System), WebDav, and SMB.
DRV 0x023c6268 '\\FileSystem\\Fs_Rec'
DEV 0x82303030 FatCdRomRecognizer FILE_DEVICE_CD_ROM_FILE_SYSTEM
        ATT 0x82127b00 (unnamed) - '\\Driver\\MRxNet' FILE_DEVICE_CD_ROM_FILE_SYSTEM
DEV 0x8233a030 FatDiskRecognizer FILE_DEVICE_DISK_FILE_SYSTEM
        ATT 0x8230daf0 (unnamed) - '\\Driver\\MRxNet' FILE_DEVICE_DISK_FILE_SYSTEM
DEV 0x8222d918 UdfsDiskRecognizer FILE_DEVICE_DISK_FILE_SYSTEM
        ATT 0x81da8bf8 (unnamed) - '\\Driver\\MRxNet' FILE_DEVICE_DISK_FILE_SYSTEM
DEV 0x82259d38 UdfsCdRomRecognizer FILE_DEVICE_CD_ROM_FILE_SYSTEM
        ATT 0x821d7530 (unnamed) - '\\Driver\\MRxNet' FILE_DEVICE_CD_ROM_FILE_SYSTEM
DEV 0x81dcd030 CdfsRecognizer FILE_DEVICE_CD_ROM_FILE_SYSTEM

DRV 0x023c6da0 '\\FileSystem\\vmhgfs'
DEV 0x8230d030 hgfsInternal FILE_DEVICE_UNKNOWN
DEV 0x81eba030 HGFS FILE_DEVICE_NETWORK_FILE_SYSTEM
        ATT 0x8222d320 (unnamed) - '\\Driver\\MRxNet' FILE_DEVICE_NETWORK_FILE_SYSTEM

DRV 0x023c7030 '\\FileSystem\\MRxSmb'
DEV 0x81d9ad80 LanmanDatagramReceiver FILE_DEVICE_NETWORK_BROWSER
DEV 0x82266c00 LanmanRedirector FILE_DEVICE_NETWORK_FILE_SYSTEM
        ATT 0x81da7f10 (unnamed) - '\\Driver\\MRxNet' FILE_DEVICE_NETWORK_FILE_SYSTEM

DRV 0x021ef6e8 '\\FileSystem\\MRxDAV'
DEV 0x81ee4610 WebDavRedirector FILE_DEVICE_NETWORK_FILE_SYSTEM
        ATT 0x81d50190 (unnamed) - '\\Driver\\MRxNet' FILE_DEVICE_NETWORK_FILE_SYSTEM
Also, you can use the driverirp command to analyze which IRPs the Stuxnet drivers handle and which ones they ignore. For example:
$ ./vol.py driverirp -r mrxnet
Volatile Systems Volatility Framework 2.0
DriverStart  Name             IRP                                  IrpAddr      IrpOwner         HookAddr     HookOwner
0xb21d8000   'MRxNet'         IRP_MJ_CREATE                        0xb21d8486   mrxnet.sys       -            -
0xb21d8000   'MRxNet'         IRP_MJ_CREATE_NAMED_PIPE             0xb21d8486   mrxnet.sys       -            -
0xb21d8000   'MRxNet'         IRP_MJ_CLOSE                         0xb21d8486   mrxnet.sys       -            -
0xb21d8000   'MRxNet'         IRP_MJ_READ                          0xb21d8486   mrxnet.sys       -            -
0xb21d8000   'MRxNet'         IRP_MJ_WRITE                         0xb21d8486   mrxnet.sys       -            -
0xb21d8000   'MRxNet'         IRP_MJ_QUERY_INFORMATION             0xb21d8486   mrxnet.sys       -            -
0xb21d8000   'MRxNet'         IRP_MJ_SET_INFORMATION               0xb21d8486   mrxnet.sys       -            -
0xb21d8000   'MRxNet'         IRP_MJ_QUERY_EA                      0xb21d8486   mrxnet.sys       -            -
0xb21d8000   'MRxNet'         IRP_MJ_SET_EA                        0xb21d8486   mrxnet.sys       -            -
0xb21d8000   'MRxNet'         IRP_MJ_FLUSH_BUFFERS                 0xb21d8486   mrxnet.sys       -            -
0xb21d8000   'MRxNet'         IRP_MJ_QUERY_VOLUME_INFORMATION      0xb21d8486   mrxnet.sys       -            -
0xb21d8000   'MRxNet'         IRP_MJ_SET_VOLUME_INFORMATION        0xb21d8486   mrxnet.sys       -            -
0xb21d8000   'MRxNet'         IRP_MJ_DIRECTORY_CONTROL             0xb21d84ec   mrxnet.sys       0xb21d97c4   mrxnet.sys 
0xb21d8000   'MRxNet'         IRP_MJ_FILE_SYSTEM_CONTROL           0xb21d8496   mrxnet.sys       0xb21d97c4   mrxnet.sys
0xb21d8000   'MRxNet'         IRP_MJ_DEVICE_CONTROL                0xb21d8486   mrxnet.sys       -            -
0xb21d8000   'MRxNet'         IRP_MJ_INTERNAL_DEVICE_CONTROL       0xb21d8486   mrxnet.sys       -            -
0xb21d8000   'MRxNet'         IRP_MJ_SHUTDOWN                      0xb21d8486   mrxnet.sys       -            -
0xb21d8000   'MRxNet'         IRP_MJ_LOCK_CONTROL                  0xb21d8486   mrxnet.sys       -            -
0xb21d8000   'MRxNet'         IRP_MJ_CLEANUP                       0xb21d8486   mrxnet.sys       -            -
0xb21d8000   'MRxNet'         IRP_MJ_CREATE_MAILSLOT               0xb21d8486   mrxnet.sys       -            -
0xb21d8000   'MRxNet'         IRP_MJ_QUERY_SECURITY                0xb21d8486   mrxnet.sys       -            -
0xb21d8000   'MRxNet'         IRP_MJ_SET_SECURITY                  0xb21d8486   mrxnet.sys       -            -
0xb21d8000   'MRxNet'         IRP_MJ_POWER                         0xb21d8486   mrxnet.sys       -            -
0xb21d8000   'MRxNet'         IRP_MJ_SYSTEM_CONTROL                0xb21d8486   mrxnet.sys       -            -
0xb21d8000   'MRxNet'         IRP_MJ_DEVICE_CHANGE                 0xb21d8486   mrxnet.sys       -            -
0xb21d8000   'MRxNet'         IRP_MJ_QUERY_QUOTA                   0xb21d8486   mrxnet.sys       -            -
0xb21d8000   'MRxNet'         IRP_MJ_SET_QUOTA                     0xb21d8486   mrxnet.sys       -            -
0xb21d8000   'MRxNet'         IRP_MJ_PNP                           0xb21d8486   mrxnet.sys       -            -
The HookAddr and HookOwner column in the output is admittedly a little mis-leading. In this case, the IRPs aren't hooked. The columns are just showing where the next hop of execution leads, based on the instructions at the IRP address. The columns are blank for everything except IRP_MJ_DIRECTORY_CONTROL and IRP_MJ_FILE_SYSTEM_CONTROL. Thus, these two IRPs are handled specially by the rootkit. All other IRPs are probably ignored or passed through.

Artifact 16: PDB Reference

"In the driver file, the project path b:\myrtus\src\objfre_w2k_x86\i386 \guava.pdb was not removed." [4]
Based on this statement, you have a unique string to search for in kernel memory. That can be done with Malfind by passing the -K or --kernel flag.
$ ./vol.py malfind -D out -K -Y "myrtus"
Volatile Systems Volatility Framework 2.0
Name                 Pid    Start      End        Tag    Hits Protect
mrxnet.sys           -      0xB21D8000 0xB21DB000 -         1 -      (Unknown)
Hit: myrtus
0xb21d9d9b   6d 79 72 74 75 73 5c 73 72 63 5c 6f 62 6a 66 72    myrtus.src.objfr
0xb21d9dab   65 5f 77 32 6b 5f 78 38 36 5c 69 33 38 36 5c 67    e_w2k_x86.i386.g
0xb21d9dbb   75 61 76 61 2e 70 64 62 00 00 00 00 00 00 00 00    uava.pdb........
0xb21d9dcb   00 00 00 00 00 30 18 00 00 1c 1a 00 00 fe ff ff    .....0..........
0xb21d9ddb   ff 00 00 00 00 d8 ff ff ff 00 00 00 00 fe ff ff    ................
0xb21d9deb   ff cb 84 1d b2 cf 84 1d b2 00 00 00 00 fe ff ff    ................
0xb21d9dfb   ff 00 00 00 00 d8 ff ff ff 00 00 00 00 fe ff ff    ................
0xb21d9e0b   ff 21 85 1d b2 25 85 1d b2 00 00 00 00 fe ff ff    .!...%..........
We got a hit in mrxnet.sys at 0xb21d9d9b. Easy enough!

Artifact 17 and 18: Windows & Classes

"It registers a window class with the name "AFX64c313" and creates a window corresponding to the class created. The window procedure of the class monitors WM_DEVICE_CHANGE messages sent when there is a change to the hardware configuration of a device or the computer. The window procedure of the class handles only requests with wParam set to DBT_DEVICEARRIVAL." [6]
This statement is describing two different, but related artifacts. We'll detect them using a few plugins built on information originally disclosed by Moyix in his blog GDI Utilities: Taking Screenshots from Memory Dumps. One is the creation of a window class (see RegisterClassEx) which results in a new Atom. If you're not familiar with atom tables, they can be extremely useful for various tasks, including malware analysis. I'll save the details for a later discussion. For now, let's check for the malicious class atom:
$ ./vol.py atomscan
Volatile Systems Volatility Framework 2.0
Table      Atom     Refs     Flags                Name
0xcc05da8  0xc0b1   0x4      0                    Performed DropEffect
0xcc05da8  0xc0b7   0x2      0                    TargetCLSID
0xcc05da8  0xc0d6   0x1      0                    text/richtext
0xcc05da8  0xc0d9   0x1      0                    application/base64
0xcc05da8  0xc118   0x2      0                    AFX64c313
0xcc05da8  0xc010   0x1      RTL_ATOM_PINNED      OleDraw
0xcc05da8  0xc033   0x1      RTL_ATOM_PINNED      OTHERWINDOWCREATED
0xcc05da8  0xc069   0x17     0                    6.0.2600.5512!SysLink
The next artifact we're looking for is a window (see CreateWindowEx) of the class AFX64c313. Handles to windows (and all other USER objects) are stored in a completely different handle table than mutexes, files, registry keys, etc. We can filter by USER object type using the -t parameter.

Note: I don't want to spoil whatever surprises that Okolica and Peterson plan to share at DFRWS 2011 "Extracting the Windows Clipboard from Memory" but using TYPE_CLIPDATA instead of TYPE_WINDOW to this command is *one* of the ways to dump the contents of the clipboard.
$ ./vol.py userhandles -t TYPE_WINDOW
Volatile Systems Volatility Framework 2.0

[snip]

Process: 668 (services.exe)
Thread: 1420
Type: TYPE_WINDOW (tagWND)
Object: 0xbc951d10
Handle: 0xe00e8
Window text: AFX64c313
Window procedure: 0x13fe695
Class: ['AFX64c313']
Superclass: ['AFX64c313']
Style: WS_MINIMIZEBOX|WS_TABSTOP|WS_DLGFRAME|WS_BORDER|WS_THICKFRAME|WS_CAPTION|WS_SYSMENU|WS_MAXIMIZEBOX|WS_GROUP|WS_OVERLAPPED|WS_CLIPSIBLINGS
ExStyle: WS_EX_LTRREADING|WS_EX_RIGHTSCROLLBAR|WS_EX_WINDOWEDGE|WS_EX_LEFT
Visible: No
Coords: left 88, top 116, right 927, bottom 699
What you see here, in a nutshell, is a window of the class AFX64c313 owned by services.exe. Although the window is not visible, it contains the text "AFX64c313." The window procedure is located at 0x13fe695 in the memory of services.exe. To explore the function, break into a volshell, change context to the right process, and disassemble.
$ ./vol.py volshell
Volatile Systems Volatility Framework 2.0
Current context: process System, pid=4, ppid=0 DTB=0x319000
Welcome to volshell! Current memory image is:
file:///memory/stuxnet.vmem
To get help, type 'hh()'

In [1]: cc(pid=668)
Current context: process services.exe, pid=668, ppid=624 DTB=0xa940080

In [2]: dis(0x13fe695)
0x13fe695 55                               PUSH EBP
0x13fe696 8bec                             MOV EBP, ESP
0x13fe698 817d0c19020000                   CMP DWORD [EBP+0xc], 0x219 ; WM_DEVICECHANGE
0x13fe69f 7514                             JNZ 0x13fe6b5
0x13fe6a1 ff7514                           PUSH DWORD [EBP+0x14]
0x13fe6a4 ff7510                           PUSH DWORD [EBP+0x10]
0x13fe6a7 e810000000                       CALL 0x13fe6bc
0x13fe6ac 59                               POP ECX
0x13fe6ad 33c0                             XOR EAX, EAX
0x13fe6af 59                               POP ECX
0x13fe6b0 40                               INC EAX
0x13fe6b1 5d                               POP EBP
0x13fe6b2 c21000                           RET 0x10
0x13fe6b5 5d                               POP EBP
0x13fe6b6 ff25c4534401                     JMP DWORD [0x14453c4]
0x13fe6bc 55                               PUSH EBP
0x13fe6bd 8bec                             MOV EBP, ESP
0x13fe6bf 83e4f8                           AND ESP, -0x8
0x13fe6c2 64a100000000                     MOV EAX, [FS:0x0]
0x13fe6c8 6aff                             PUSH -0x1
0x13fe6ca 68893d4401                       PUSH DWORD 0x1443d89
0x13fe6cf 50                               PUSH EAX
0x13fe6d0 64892500000000                   MOV [FS:0x0], ESP
0x13fe6d7 83ec6c                           SUB ESP, 0x6c
0x13fe6da 817d0800800000                   CMP DWORD [EBP+0x8], 0x8000 ; DBT_DEVICEARRIVAL
0x13fe6e1 53                               PUSH EBX
0x13fe6e2 56                               PUSH ESI
Artifact 17: check! Artifact 18: check. Capabilities you didn't know existed in any memory analysis framework: check! ;=)

Artifact 19 (and Beyond...)

Okay so we didn't quite make it to 20 artifacts with the time allotted, but with the power of Volatility, we've gotten pretty close. 20 is still a small number in relation to how many artifacts Stuxnet actually leaves on a system. We didn't even touch on the RPC server, jobs/tasks, UPX packing, and fake digital certificates. Also, don't forget there are other memory analysis frameworks with different capabilities.

Conclusion

I hope this has been an informative post for people interested in malware analysis, Stuxnet, Volatility, memory forensics, and related topics. Thank you to the authors of all the quoted articles (the people who did real RE work) and to the Volatility team for completing release 2.0!


轉自   http://mnin.blogspot.com/2011/06/examining-stuxnets-footprint-in-memory.html

0 意見: