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
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.
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).
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
Artifact 4: Injected Code
Artifact 5: Hidden DLLs
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.
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
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.
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.
Artifact 7: Patched PE Header
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.
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:
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
Artifact 10: Network Connections
Artifact 11: Registry Keys
Don't forget you can also use the svcscan command to enumerate services.
Artifact 12: Kernel Drivers
Artifact 13: Kernel Callbacks
Artifact 14: FileSystem Hooks
Artifact 15: Devices & IRPs
Artifact 16: PDB Reference
Artifact 17 and 18: Windows & Classes
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.
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
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
$ ./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: 8As 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.0360b7abFor 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.dllThe 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.0360b7abThis 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.exeHere 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.dllHere 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.dllAs 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:Based on this statement, you can use the apihooks plugin to detect what Symantec is describing.
* ZwMapViewOfSection
* ZwCreateSection
* ZwOpenFile
* ZwCloseFile
* ZwQueryAttributesFile
* ZwQuerySection" [4]
$ ./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], ALAt 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 0x2eBy 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.....jAs 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_headerThe 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.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:
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]
$ ./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 152The 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.5Perhaps 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\MRxSmbWhy 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.sysFeel 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: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.
* \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]
$ ./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_SYSTEMYou 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_SYSTEMStuxnet 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_SYSTEMAlso, 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!SysLinkThe 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 699What 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 ESIArtifact 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 意見: