Stuxnet\'s Footprint in Memory with Volatility 2.0

a1234567mdy 发表于 2011-12-23 03:23

<a href="http://mnin.blogspot.com/2011/06/examining-stuxnets-footprint-in-memory.html" target="_blank">http://mnin.blogspot.com/2011/06/examining-stuxnets-footprint-in-memory.html</a><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: 16px; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); "><div class="blog-posts hfeed"><div class="date-outer">FRIDAY, JUNE 3, 2011<div class="date-posts"><div class="post-outer"><div class="post hentry uncustomized-post-template" style="position: relative; min-height: 0px; margin-top: 0px; margin-right: 0px; margin-bottom: 25px; margin-left: 0px; "><a name="2661066967859357938"></a>Stuxnet's Footprint in Memory with Volatility 2.0<div class="post-body entry-content" id="post-body-2661066967859357938" style="width: 620px; font-size: 13px; line-height: 1.4; position: relative; ">In this blog post, we'll examine Stuxnet's footprint in memory using <a href="http://code.google.com/p/volatility/" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">Volatility 2.0</a>. A talk was given at <a href="https://www.volatilesystems.com/default/omfw" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">Open Memory Forensics Workshop</a> on this topic (see the online <a href="http://prezi.com/goocmfeuiqdf/tracking-stuxnets-footprint-through-memory/" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">Prezi</a>) 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: * Mark Russinovich's <a href="http://blogs.technet.com/b/markrussinovich/archive/2011/03/30/3416253.aspx" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">Analyzing a Stuxnet Infection with the Sysinternals Tools</a><a href="http://blogs.technet.com/b/markrussinovich/archive/2011/03/30/3416253.aspx" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">, Part I</a> * Mark Russinovich's <a href="http://blogs.technet.com/b/markrussinovich/archive/2011/04/20/3422035.aspx" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">Analyzing a Stuxnet Infection with the Sysinternals Tools</a><a href="http://blogs.technet.com/b/markrussinovich/archive/2011/04/20/3422035.aspx" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">, Part II</a> * Mark Russinovich's <a href="http://blogs.technet.com/b/markrussinovich/archive/2011/05/10/3422212.aspx" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">Analyzing a Stuxnet Infection with the Sysinternals Tools</a><a href="http://blogs.technet.com/b/markrussinovich/archive/2011/05/10/3422212.aspx" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">, Part III</a> * Symantec's <a href="http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/w32_stuxnet_dossier.pdf" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">W32.Stuxnet Dossier</a> * Amr Thabet's <a href="http://ispy.infospyware.net/images/2010/MrxCls-Stuxnet-Loader-Driver-English.pdf" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">MrxCls - Stuxnet Loader Driver</a> * ESET's <a href="http://www.eset.com/resources/white-papers/Stuxnet_Under_the_Microscope.pdf" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">Stuxnet Under The Microscope </a> Getting Started The memory image we'll be working with is available <a href="http://malwarecookbook.googlecode.com/svn/trunk/stuxnet.vmem.zip" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">here</a>. The MD5 of the Stuxnet sample is<a href="http://threatexpert.com/report.aspx?md5=74ddc49a7c121a61b8d06c03f92d0c13" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">74ddc49a7c121a61b8d06c03f92d0c13</a> (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 <a href="http://code.google.com/p/malwarecookbook/source/browse/trunk/malware.py" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">malware.py source code</a> and placed it in Volatility's plugins directory. Artifact 1: Extra lsass.exe <blockquote>"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." </blockquote>Based on this statement, you could use the <a href="http://code.google.com/p/volatility/wiki/CommandReference#pslist" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">pslist</a>, <a href="http://code.google.com/p/volatility/wiki/CommandReference#psscan" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">psscan</a>, or <a href="http://code.google.com/p/volatility/wiki/CommandReference#pstree" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">pstree</a> 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 <a href="http://volatility.googlecode.com/files/volatility-2.0-inheritance-graph.pdf" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">Volatility 2.0 Inheritance Graph</a>) 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 <a href="http://code.google.com/p/volatility/wiki/CommandReference#getsids" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">getsids</a>. $ ./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 <div style="text-align: left; color: rgb(51, 51, 255); "><blockquote>"...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</blockquote></div>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 <a href="http://code.google.com/p/volatility/wiki/CommandReference#volshell" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">volshell</a> 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 : 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 <a href="http://msdn.microsoft.com/en-us/library/ms686219%28v=vs.85%29.aspx" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">SetPriorityClass</a>, 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 <a href="http://msdn.microsoft.com/en-us/library/ms686277%28v=vs.85%29.aspx" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">SetThreadPriority</a> is called), then the differences should be visible using the <a href="http://code.google.com/p/volatility/wiki/CommandReference#threads" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">threads</a>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 ------ 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: 0x9 TEB: 0x7ffa0000 StartAddress: 0x7c8106e9 ServiceTable: 0x80552fa0 0x80501b8c NtClose 0xb240f80e PROCMON20.SYS NtCreateKey 0xb240f604 PROCMON20.SYS NtDeleteKey 0xb240f4ac PROCMON20.SYS NtDeleteValueKey 0xb240f4f2 PROCMON20.SYS NtEnumerateKey 0xb240f3f2 PROCMON20.SYS NtEnumerateValueKey 0xb240f34e PROCMON20.SYS NtFlushKey 0xb240f446 PROCMON20.SYS NtLoadKey 0xb240f972 PROCMON20.SYS NtOpenKey 0xb240f7d0 PROCMON20.SYS NtQueryKey 0xb240f03e PROCMON20.SYS NtQueryValueKey 0xb240f166 PROCMON20.SYS NtSetValueKey 0xb240f28a PROCMON20.SYS NtUnloadKey 0xb240fac2 PROCMON20.SYS - - - 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: 0x8 TEB: 0x7ffdb000 StartAddress: 0x7c8106e9 ServiceTable: 0x80552f60 0x80501b8c NtClose 0xb240f80e PROCMON20.SYS NtCreateKey 0xb240f604 PROCMON20.SYS NtDeleteKey 0xb240f4ac PROCMON20.SYS NtDeleteValueKey 0xb240f4f2 PROCMON20.SYS NtEnumerateKey 0xb240f3f2 PROCMON20.SYS NtEnumerateValueKey 0xb240f34e PROCMON20.SYS NtFlushKey 0xb240f446 PROCMON20.SYS NtLoadKey 0xb240f972 PROCMON20.SYS NtOpenKey 0xb240f7d0 PROCMON20.SYS NtQueryKey 0xb240f03e PROCMON20.SYS NtQueryValueKey 0xb240f166 PROCMON20.SYS NtSetValueKey 0xb240f28a PROCMON20.SYS NtUnloadKey 0xb240fac2 PROCMON20.SYS 0xbf999b80 - - 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<a href="http://msdn.microsoft.com/en-us/library/ff549659%28v=vs.85%29.aspx" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">KeStackAttachProcess</a> 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 <blockquote>"...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..." </blockquote>Based on this statement, you can use <a href="http://code.google.com/p/volatility/wiki/CommandReference#dlllist" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">dlllist</a> 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 ************************************************************************ 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 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 <a href="http://code.google.com/p/volatility/wiki/CommandReference#handles" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">handles</a> command (we'll use this command later). Artifact 4: Injected Code <blockquote>"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." </blockquote>Based on this statement, you can use <a href="http://code.google.com/p/volatility/wiki/CommandReference#malfind" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">malfind</a> 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 <a href="http://code.google.com/p/volatility/wiki/CommandReference#vadinfo" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">vadinfo</a> to see more granular details about the memory segment: $ ./vol.py vadinfo -p 868 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 <blockquote>"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...." </blockquote>Based on this statement, you can use the <a href="http://code.google.com/p/volatility/wiki/CommandReference#dlllist" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">dlllist</a> 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 Path 0x013f0000 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 <a href="http://code.google.com/p/volatility/wiki/CommandReference#ldrmodules" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">ldrmodules</a> 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<a href="http://msdn.microsoft.com/en-us/library/aa366890%28VS.85%29.aspx" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">VirtualAlloc</a>(Ex) and <a href="http://msdn.microsoft.com/en-us/library/ms681674%28VS.85%29.aspx" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">WriteProcessMemory</a>. 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<a href="http://blog.spiderlabs.com/2011/05/analyzing-malware-hollow-processes.html" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">hollow process</a> situation. You can confirm by using <a href="http://code.google.com/p/volatility/wiki/CommandReference#procexedump" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">procexedump</a> or <a href="http://code.google.com/p/volatility/wiki/CommandReference#procmemdump" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">procmemdump</a> 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 <blockquote>"The functions hooked for this purpose in Ntdll.dll are: * ZwMapViewOfSection * ZwCreateSection * ZwOpenFile * ZwCloseFile * ZwQueryAttributesFile * ZwQuerySection" </blockquote>Based on this statement, you can use the <a href="http://code.google.com/p/volatility/wiki/CommandReference#apihooks" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">apihooks</a> plugin to detect what Symantec is describing. $ ./vol.py apihooks Volatile Systems Volatility Framework 2.0 Name Type Target Value services.exe syscallntdll.dll!NtClose 0x7c900050 MOV EDX, 0x7c900050 (UNKNOWN) services.exe syscallntdll.dll!NtCreateSection 0x7c900048 MOV EDX, 0x7c900048 (UNKNOWN) services.exe syscallntdll.dll!NtMapViewOfSection 0x7c900044 MOV EDX, 0x7c900044 (UNKNOWN) services.exe syscallntdll.dll!NtOpenFile 0x7c90004c MOV EDX, 0x7c90004c (UNKNOWN) services.exe syscallntdll.dll!NtQueryAttributesFile 0x7c900054 MOV EDX, 0x7c900054 (UNKNOWN) services.exe syscallntdll.dll!NtQuerySection 0x7c900058 MOV EDX, 0x7c900058 (UNKNOWN) services.exe syscallntdll.dll!ZwClose 0x7c900050 MOV EDX, 0x7c900050 (UNKNOWN) services.exe syscallntdll.dll!ZwCreateSection 0x7c900048 MOV EDX, 0x7c900048 (UNKNOWN) services.exe syscallntdll.dll!ZwMapViewOfSection 0x7c900044 MOV EDX, 0x7c900044 (UNKNOWN) services.exe syscallntdll.dll!ZwOpenFile 0x7c90004c MOV EDX, 0x7c90004c (UNKNOWN) services.exe syscallntdll.dll!ZwQueryAttributesFile 0x7c900054 MOV EDX, 0x7c900054 (UNKNOWN) services.exe syscallntdll.dll!ZwQuerySection 0x7c900058 MOV EDX, 0x7c900058 (UNKNOWN) 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 <a href="http://www.honeynet.org/node/578" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">Carberp</a> instead of the more common Inline/IAT/EAT hooking. To interactively explore code around the hook address, use the <a href="http://code.google.com/p/volatility/wiki/CommandReference#volshell" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">volshell</a> 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 0x7c90cfec c20c00 RET 0xc 0x7c90cfef 90 NOP 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 <a href="http://www.nynaeve.net/?p=48" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">the system call dispatcher on x86</a>). 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 , DL 0x7c90006a 6e OUTS DX, 0x7c90006b 20444f53 AND , AL 0x7c90006f 206d6f AND , CH 0x7c900072 64652e0d0d0a2400 OR EAX, 0x240a0d 0x7c90007a 0000 ADD , AL 0x7c90007c 0000 ADD , AL 0x7c90007e 0000 ADD , 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 <a href="http://dvlabs.tippingpoint.com/blog/2008/08/07/mindshare-anti-reversing-techniques" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">MindshaRE: Anti-Reversing Techniques</a>) 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 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 0x9401ad8d542408 LEA EDX, 0x9401b1cd2e 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.....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 <blockquote style="color: rgb(51, 51, 255); ">"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..." </blockquote>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." Based on this statement, you can use the <a href="http://code.google.com/p/volatility/wiki/CommandReference#mutantscan" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">mutantscan</a> and/or <a href="http://code.google.com/p/volatility/wiki/CommandReference#handles" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">handles</a> 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 <a href="http://code.google.com/p/volatility/source/browse/trunk/volatility/plugins/overlays/windows/win7_sp0_x86_vtypes.py#5433" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">OwnerThread member of each _KMUTANT</a> (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' 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 <a href="http://code.google.com/p/volatility/wiki/CommandReference#thrdscan" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">thrdscan</a> 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 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: <a href="http://3.bp.blogspot.com/-0txXvpqeYYM/TiUd8X7SROI/AAAAAAAACK8/lW0n-EForLk/s1600/globalmutexsvc.png" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank"><img src="http://3.bp.blogspot.com/-0txXvpqeYYM/TiUd8X7SROI/AAAAAAAACK8/lW0n-EForLk/s320/globalmutexsvc.png" alt="" id="BLOGGER_PHOTO_ID_5630939832148706530" style="border-top-style: solid; border-right-style: solid; border-bottom-style: solid; border-left-style: solid; border-width: initial; border-color: initial; position: relative; padding-top: 5px; padding-right: 5px; padding-bottom: 5px; padding-left: 5px; background-image: initial; background-attachment: initial; background-origin: initial; background-clip: initial; background-color: rgb(255, 255, 255); border-top-width: 1px; border-right-width: 1px; border-bottom-width: 1px; border-left-width: 1px; border-top-color: rgb(238, 238, 238); border-right-color: rgb(238, 238, 238); border-bottom-color: rgb(238, 238, 238); border-left-color: rgb(238, 238, 238); -webkit-box-shadow: rgba(0, 0, 0, 0.0976563) 1px 1px 5px; box-shadow: rgba(0, 0, 0, 0.0976563) 1px 1px 5px; display: block; margin-top: 0px; margin-right: auto; margin-bottom: 10px; margin-left: auto; text-align: center; cursor: pointer; width: 320px; height: 158px; background-position: initial initial; background-repeat: initial initial; " border="0"></a> <a href="http://2.bp.blogspot.com/-kFntpBRDuRg/TiWn3wBXtyI/AAAAAAAACLE/7OkcsDy6Yno/s1600/globalmutexsvc2.png" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank"><img src="http://2.bp.blogspot.com/-kFntpBRDuRg/TiWn3wBXtyI/AAAAAAAACLE/7OkcsDy6Yno/s320/globalmutexsvc2.png" alt="" id="BLOGGER_PHOTO_ID_5631091485321967394" style="border-top-style: solid; border-right-style: solid; border-bottom-style: solid; border-left-style: solid; border-width: initial; border-color: initial; position: relative; padding-top: 5px; padding-right: 5px; padding-bottom: 5px; padding-left: 5px; background-image: initial; background-attachment: initial; background-origin: initial; background-clip: initial; background-color: rgb(255, 255, 255); border-top-width: 1px; border-right-width: 1px; border-bottom-width: 1px; border-left-width: 1px; border-top-color: rgb(238, 238, 238); border-right-color: rgb(238, 238, 238); border-bottom-color: rgb(238, 238, 238); border-left-color: rgb(238, 238, 238); -webkit-box-shadow: rgba(0, 0, 0, 0.0976563) 1px 1px 5px; box-shadow: rgba(0, 0, 0, 0.0976563) 1px 1px 5px; display: block; margin-top: 0px; margin-right: auto; margin-bottom: 10px; margin-left: auto; text-align: center; cursor: pointer; width: 320px; height: 158px; background-position: initial initial; background-repeat: initial initial; " border="0"></a> That's a wrap for this one! Artifact 9: File Objects <blockquote>"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." </blockquote>Based on this statement, you can use the <a href="http://code.google.com/p/volatility/wiki/CommandReference#handles" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">handles</a> command to see if any processes currently have open handles to the specified files, or you can use <a href="http://code.google.com/p/volatility/wiki/CommandReference#filescan" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">filescan</a> 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 <a href="http://msdn.microsoft.com/en-us/library/ms724211%28v=vs.85%29.aspx" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">CloseHandle</a>. 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 <blockquote style="color: rgb(51, 51, 255); ">"This function 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: <ul style="padding-top: 0px; padding-right: 2.5em; padding-bottom: 0px; padding-left: 2.5em; margin-top: 0.5em; margin-right: 0px; margin-bottom: 0.5em; margin-left: 0px; line-height: 1.4; "><li style="padding-top: 0px; padding-right: 0px; padding-bottom: 0px; padding-left: 0px; margin-top: 0px; margin-right: 0px; margin-bottom: 0.25em; margin-left: 0px; text-indent: 0px; ">www.mypremierfutbol.com</li><li style="padding-top: 0px; padding-right: 0px; padding-bottom: 0px; padding-left: 0px; margin-top: 0px; margin-right: 0px; margin-bottom: 0.25em; margin-left: 0px; text-indent: 0px; ">www.todaysfutbol.com" </li></ul></blockquote>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 <a href="http://code.google.com/p/volatility/wiki/CommandReference#Networking" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">Networking</a>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 ---------- -------------------- ------ ------ ------ ------ ------------------- 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 <blockquote>"...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" </blockquote>Based on this statement, we can use <a href="http://code.google.com/p/volatility/wiki/CommandReference#printkey" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">printkey</a> 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 , 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 <a href="http://code.google.com/p/volatility/wiki/CommandReference#svcscan" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">svcscan</a> 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 <a href="http://msdn.microsoft.com/en-us/library/ms682450%28v=vs.85%29.aspx" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">CreateService</a> and<a href="http://msdn.microsoft.com/en-us/library/ms686321%28v=vs.85%29.aspx" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">StartService</a> by creating the registry keys directly and then calling <a href="http://msdn.microsoft.com/en-us/library/ff566470%28v=vs.85%29.aspx" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">NtLoadDriver</a> (which is exactly what Stuxnet does). Artifact 12: Kernel Drivers <blockquote style="color: rgb(0, 0, 0); ">"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." </blockquote>Based on this statement, the two drivers should be visible with the <a href="http://code.google.com/p/volatility/wiki/CommandReference#modules" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">modules</a> or <a href="http://code.google.com/p/volatility/wiki/CommandReference#modscan" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">modscan</a> commands. $ ./vol.py modules 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 <a href="http://code.google.com/p/volatility/wiki/CommandReference#moddump" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">moddump</a> for inspection with strings, IDA Pro, or for scanning with your favorite antivirus. Artifact 13: Kernel Callbacks <blockquote>"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." </blockquote>Based on this statement, you can use the <a href="http://code.google.com/p/volatility/wiki/CommandReference#callbacks" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">callbacks</a> 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) The output shows the <a href="http://msdn.microsoft.com/en-us/library/ff559957%28v=vs.85%29.aspx" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">PsSetLoadImageNotifyRoutine</a> installed by mrxcls.sys. Mark also states "Ironically, Process Monitor also uses this callback functionality to monitor image loads."  which is why you see the PROCMON20.SYS entries as well. Artifact 14: FileSystem Hooks <blockquote>"The driver also registers to a filesystem registration callback routine in order to hook newly created filesystem objects on the fly." </blockquote>Based on this statement, if the rootkit used <a href="http://msdn.microsoft.com/en-us/library/ff548499%28v=vs.85%29.aspx" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">IoRegisterFsRegistrationChange</a> to install the file system registration callback routine, then you can use the callbacks plugin to detect it. However, instead it uses<a href="http://msdn.microsoft.com/en-us/library/ff549511%28v=vs.85%29.aspx" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">IoRegisterDriverReinitialization</a>, 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. <a href="http://4.bp.blogspot.com/-PE5eHxuRQaI/Teln4Qc_qBI/AAAAAAAACKg/ILfsMLYf2ho/s1600/IoRi.png" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank"><img src="http://4.bp.blogspot.com/-PE5eHxuRQaI/Teln4Qc_qBI/AAAAAAAACKg/ILfsMLYf2ho/s320/IoRi.png" alt="" id="BLOGGER_PHOTO_ID_5614132626680948754" style="border-top-style: solid; border-right-style: solid; border-bottom-style: solid; border-left-style: solid; border-width: initial; border-color: initial; position: relative; padding-top: 5px; padding-right: 5px; padding-bottom: 5px; padding-left: 5px; background-image: initial; background-attachment: initial; background-origin: initial; background-clip: initial; background-color: rgb(255, 255, 255); border-top-width: 1px; border-right-width: 1px; border-bottom-width: 1px; border-left-width: 1px; border-top-color: rgb(238, 238, 238); border-right-color: rgb(238, 238, 238); border-bottom-color: rgb(238, 238, 238); border-left-color: rgb(238, 238, 238); -webkit-box-shadow: rgba(0, 0, 0, 0.0976563) 1px 1px 5px; box-shadow: rgba(0, 0, 0, 0.0976563) 1px 1px 5px; display: block; margin-top: 0px; margin-right: auto; margin-bottom: 10px; margin-left: auto; text-align: center; cursor: pointer; width: 320px; height: 265px; background-position: initial initial; background-repeat: initial initial; " border="0"></a> Artifact 15: Devices & IRPs <blockquote>"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)." </blockquote>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 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 <a href="http://msdn.microsoft.com/en-us/library/ff548397%28v=vs.85%29.aspx" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">IoCreateDevice</a>) 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 <a href="http://code.google.com/p/volatility/wiki/CommandReference#driverirp" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">driverirp</a> 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 DriverStartName 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 <blockquote>"In the driver file, the project path b:\myrtus\src\objfre_w2k_x86\i386 \guava.pdb was not removed." </blockquote>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 <blockquote>"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." </blockquote>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 <a href="http://moyix.blogspot.com/2010/07/gdi-utilities-taking-screenshots-of.html" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">GDI Utilities: Taking Screenshots from Memory Dumps</a>. One is the creation of a window class (see <a href="http://msdn.microsoft.com/en-us/library/ms633587%28v=VS.85%29.aspx" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">RegisterClas***</a>) which results in a new <a href="http://msdn.microsoft.com/en-us/library/ff468795%28v=VS.85%29.aspx" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">Atom</a>. 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 0xcc05da80xc0b1 0x4 0 Performed DropEffect 0xcc05da80xc0b7 0x2 0 TargetCLSID 0xcc05da80xc0d6 0x1 0 text/richtext 0xcc05da80xc0d9 0x1 0 application/base64 0xcc05da80xc118 0x2 0 AFX64c313 0xcc05da80xc010 0x1 RTL_ATOM_PINNED OleDraw 0xcc05da80xc033 0x1 RTL_ATOM_PINNED OTHERWINDOWCREATED 0xcc05da80xc069 0x17 0 6.0.2600.5512!SysLink The next artifact we're looking for is a window (see <a href="http://msdn.microsoft.com/en-us/library/ms632680%28v=VS.85%29.aspx" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">CreateWindowEx</a>) 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 <a href="http://www.dfrws.org/2011/program.shtml" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">DFRWS 2011 "Extracting the Windows Clipboard from Memory"</a> 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 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 <a href="http://msdn.microsoft.com/en-us/library/ms633573%28v=VS.85%29.aspx" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">window procedure</a> 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 : cc(pid=668) Current context: process services.exe, pid=668, ppid=624 DTB=0xa940080 In : dis(0x13fe695) 0x13fe695 55 PUSH EBP 0x13fe696 8bec MOV EBP, ESP 0x13fe698 817d0c19020000 CMP DWORD , 0x219 ; WM_DEVICECHANGE 0x13fe69f 7514 JNZ 0x13fe6b5 0x13fe6a1 ff7514 PUSH DWORD 0x13fe6a4 ff7510 PUSH DWORD 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 0x13fe6bc 55 PUSH EBP 0x13fe6bd 8bec MOV EBP, ESP 0x13fe6bf 83e4f8 AND ESP, -0x8 0x13fe6c2 64a100000000 MOV EAX, 0x13fe6c8 6aff PUSH -0x1 0x13fe6ca 68893d4401 PUSH DWORD 0x1443d89 0x13fe6cf 50 PUSH EAX 0x13fe6d0 64892500000000 MOV , ESP 0x13fe6d7 83ec6c SUB ESP, 0x6c 0x13fe6da 817d0800800000 CMP DWORD , 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!</div><div class="post-footer" style="line-height: 1.6; margin-top: 20px; margin-right: -2px; margin-bottom: 0px; margin-left: -2px; padding-top: 5px; padding-right: 10px; padding-bottom: 5px; padding-left: 10px; color: rgb(102, 102, 102); background-color: rgb(249, 249, 249); border-bottom-width: 1px; border-bottom-style: solid; border-bottom-color: rgb(238, 238, 238); font-size: 12px; "><div class="post-footer-line post-footer-line-1">Posted by Michael Hale Ligh at <a class="timestamp-link" href="http://mnin.blogspot.com/2011/06/examining-stuxnets-footprint-in-memory.html" rel="bookmark" title="permanent link" style="text-decoration: none; color: rgb(34, 136, 187); ">8:13 AM</a> <a href="http://www.blogger.com/email-post.g?blogID=3630199973361886660&postID=2661066967859357938" title="Email Post" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank"><img alt="" class="icon-action" src="http://img1.blogblog.com/img/icon18_email.gif" style="border-top-style: none !important; border-right-style: none !important; border-bottom-style: none !important; border-left-style: none !important; border-width: initial; border-color: initial; position: relative; margin-top: 0px !important; margin-right: 0px !important; margin-bottom: 0px !important; margin-left: 0.5em !important; vertical-align: middle; " height="13" width="18"> </a></div><div class="post-footer-line post-footer-line-2"></div><div class="post-footer-line post-footer-line-3"></div></div></div><div class="comments" id="comments" style="position: relative; min-height: 0px; "><a name="comments"></a>4 comments:<div id="Blog1_comments-block-wrapper"><a name="c5183311371282307016"></a><div class="avatar-image-container avatar-stock" style="margin-top: 0.2em; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; height: 37px; left: -45px; position: absolute; width: 37px; "><a href="http://travisaltman.com/" rel="nofollow" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank"><img src="http://img1.blogblog.com/img/blank.gif" alt="" title="travis" style="border-top-style: solid; border-right-style: solid; border-bottom-style: solid; border-left-style: solid; border-width: initial; border-color: initial; position: relative; border-top-width: 0px; border-right-width: 0px; border-bottom-width: 0px; border-left-width: 0px; border-top-color: rgb(238, 238, 238); border-right-color: rgb(238, 238, 238); border-bottom-color: rgb(238, 238, 238); border-left-color: rgb(238, 238, 238); float: right; padding-top: 1px; padding-right: 1px; padding-bottom: 1px; padding-left: 1px; " height="16" width="16"></a></div><a href="http://travisaltman.com/" rel="nofollow" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">travis</a> said...Excellent break down, keep the articles coming.<a href="http://mnin.blogspot.com/2011/06/examining-stuxnets-footprint-in-memory.html?showComment=1312433606316#c5183311371282307016" title="comment permalink" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">August 3, 2011 10:53 PM</a><a name="c7487291907498269028"></a><div class="avatar-image-container vcard" style="margin-top: 0.2em; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; height: 37px; left: -45px; position: absolute; width: 37px; "><a href="http://www.blogger.com/profile/14118470540475024612" rel="nofollow" class="avatar-hovercard" id="av-1-14118470540475024612" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank"><img src="http://3.bp.blogspot.com/-MsVWj80py5I/TkKqOzzPZWI/AAAAAAAAAAo/5phUaAMRf-0/s45/the_lord_of_the_rings-10078.jpg" alt="" class="delayLoad" longdesc="http://3.bp.blogspot.com/-MsVWj80py5I/TkKqOzzPZWI/AAAAAAAAAAo/5phUaAMRf-0/s45/the_lord_of_the_rings-10078.jpg" title="sessionpool" style="border-top-style: solid; border-right-style: solid; border-bottom-style: solid; border-left-style: solid; border-width: initial; border-color: initial; position: relative; border-top-width: 1px; border-right-width: 1px; border-bottom-width: 1px; border-left-width: 1px; border-top-color: rgb(238, 238, 238); border-right-color: rgb(238, 238, 238); border-bottom-color: rgb(238, 238, 238); border-left-color: rgb(238, 238, 238); float: right; " height="35" width="35"></a></div><a href="http://www.blogger.com/profile/14118470540475024612" rel="nofollow" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">sessionpool</a> said...simply awesome... i am gonna try my hands on the Volatility for sure :)<a href="http://mnin.blogspot.com/2011/06/examining-stuxnets-footprint-in-memory.html?showComment=1313090287601#c7487291907498269028" title="comment permalink" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">August 11, 2011 1:18 PM</a><a name="c3886032911705323737"></a><div class="avatar-image-container avatar-stock" style="margin-top: 0.2em; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; height: 37px; left: -45px; position: absolute; width: 37px; "><a href="http://www.blogger.com/profile/03769171162717944993" rel="nofollow" class="avatar-hovercard" id="av-2-03769171162717944993" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank"><img src="http://img2.blogblog.com/img/b16-rounded.gif" alt="" title="Mic" style="border-top-style: solid; border-right-style: solid; border-bottom-style: solid; border-left-style: solid; border-width: initial; border-color: initial; position: relative; border-top-width: 0px; border-right-width: 0px; border-bottom-width: 0px; border-left-width: 0px; border-top-color: rgb(238, 238, 238); border-right-color: rgb(238, 238, 238); border-bottom-color: rgb(238, 238, 238); border-left-color: rgb(238, 238, 238); float: right; padding-top: 1px; padding-right: 1px; padding-bottom: 1px; padding-left: 1px; " height="16" width="16"></a></div><a href="http://www.blogger.com/profile/03769171162717944993" rel="nofollow" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">Mic</a> said...Simply great. I have comprehended that using a Win7 platform using adapted Linux commands and the Sysinternals suite and was flabbergasted about the techniques used by stuxnet and the capabilities of Volatility I did not use before. Many thanks to Michael for supporting me an the quick adaptation of the Malware plugin!<a href="http://mnin.blogspot.com/2011/06/examining-stuxnets-footprint-in-memory.html?showComment=1313648930758#c3886032911705323737" title="comment permalink" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">August 18, 2011 12:28 AM</a><a name="c2534388054356414892"></a><div class="avatar-image-container vcard" style="margin-top: 0.2em; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; height: 37px; left: -45px; position: absolute; width: 37px; "><a href="http://www.blogger.com/profile/16143323653424656404" rel="nofollow" class="avatar-hovercard" id="av-3-16143323653424656404" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank"><img src="http://2.bp.blogspot.com/-EizGgTgLZbQ/ThXTZU_l9dI/AAAAAAAAACw/yitteIFGWwk/s45/227067_10150177518107167_684962166_7211275_6093230_n.jpg" alt="" class="delayLoad" longdesc="http://2.bp.blogspot.com/-EizGgTgLZbQ/ThXTZU_l9dI/AAAAAAAAACw/yitteIFGWwk/s45/227067_10150177518107167_684962166_7211275_6093230_n.jpg" title="Sachin Sonekar" style="border-top-style: solid; border-right-style: solid; border-bottom-style: solid; border-left-style: solid; border-width: initial; border-color: initial; position: relative; border-top-width: 1px; border-right-width: 1px; border-bottom-width: 1px; border-left-width: 1px; border-top-color: rgb(238, 238, 238); border-right-color: rgb(238, 238, 238); border-bottom-color: rgb(238, 238, 238); border-left-color: rgb(238, 238, 238); float: right; " height="35" width="35"></a></div><a href="http://www.blogger.com/profile/16143323653424656404" rel="nofollow" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">Sachin Sonekar</a> said...Thanks for this memory analysis using volatility .. I really need this .. I am malware analyst .currently working on memory analysis<a href="http://mnin.blogspot.com/2011/06/examining-stuxnets-footprint-in-memory.html?showComment=1314594385458#c2534388054356414892" title="comment permalink" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">August 28, 2011 11:06 PM</a></div><a href="http://www.blogger.com/comment.g?blogID=3630199973361886660&postID=2661066967859357938" style="text-decoration: none; color: rgb(34, 136, 187); " target="_blank">Post a Comment</a></div></div></div></div></div><div class="blog-pager" id="blog-pager" style="background-image: none; background-attachment: scroll; background-origin: initial; background-clip: initial; background-color: transparent; margin-top: 1em; margin-right: 0px; margin-bottom: 1em; margin-left: 0px; text-align: center; overflow-x: hidden; overflow-y: hidden; background-position: 50% 0%; background-repeat: no-repeat no-repeat; "><a class="blog-pager-older-link" href="http://mnin.blogspot.com/2011/04/detectingmemory-forging-attempt-by.html" id="Blog1_blog-pager-older-link" title="Older Post" style="background-color: rgb(255, 255, 255); padding-top: 5px; padding-right: 5px; padding-bottom: 5px; padding-left: 5px; text-decoration: none; color: rgb(34, 136, 187); ">Older Post</a><a class="home-link" href="http://mnin.blogspot.com/" style="background-color: rgb(255, 255, 255); padding-top: 5px; padding-right: 5px; padding-bottom: 5px; padding-left: 5px; text-decoration: none; color: rgb(34, 136, 187); ">Home</a></div><div class="post-feeds"><div class="feed-links">Subscribe to: <a class="feed-link" href="http://mnin.blogspot.com/feeds/2661066967859357938/comments/default" target="_blank" type="application/atom+xml" style="text-decoration: none; color: rgb(34, 136, 187); ">Post Comments (Atom)</a></div></div>

页: [1]

Chinaunix's Archiver

Stuxnet\'s Footprint in Memory with Volatility 2.0