用volatility取证框架分析震网病毒
本帖最后由 buzhifou01 于 2019-11-26 16:53 编辑1.前言
本文使用volatility内存取证工具来分析震网病毒在计算机中的运行情况，震网病毒在计算机中运行时必然会在内存中留下异常信息，在短时间内，这些异常信息会存留在内存中，那么对内存进行转储，生成dump文件，dump文件具有内存在某一时期的所有信息。因此用volatility对dump文件进行分析就能获得病毒在计算机中的活动痕迹。
2.工具及介绍
使用工具：volatility，DumpIt，VM虚拟机
volatility是一个比较强大信息安全分析工具，它是一个开源工具，具备跨平台特性。它是一个离线分析工具，可以输出内存中的进程信息、文件信息、注册表信息等，根据这些信息可以分析系统是否收到恶意攻击。
DumpIt是一个内存转储工具，在系统运行时，使用它可以把系统中内存信息提取出来生成一个dump文件。
3.病毒介绍
震网病毒(Stuxnet)是一个非常高端的蠕虫病毒，它能自我复制，并将副本通过网络传输，任何一台个人电脑只要和染毒电脑相连，就会被感染。除此之外，它还能通过USB总线传播，并在微软Windows计算机上传播。
4.分析过程
我首先在WindowsXp系统中运行该病毒，随后使用DumpIt工具转储内存，然后把生成的转储文件stuxnet.raw移到linux环境下，用volatility框架分析。
4.1新建额外进程
在正常情况下，系统只会运行一个lsass.exe，Winlogon进程在系统启动时创建它。用pstree插件显示的进程树表明系统中多存在了两个lsass.exe并都是由Services.exe创建的，这意味着Stuxnet以某种方式将其代码放入Services.exe进程中。
$ python vol.py -f stuxnet.raw --profile=WinXPSP3x86 pstree
Volatile Systems Volatility Framework 2.6
Name Pid PPid Thds Hnds Time
0x823C8830:System 4 0 59 403 1990-01-01 00:00:00
. 0x820DF020:smss.exe 376 4 3 19 2019-10-29 17:08:53
.. 0x821A2DA0:csrss.exe 600 376 11 395 2019-10-29 17:08:54
.. 0x81DA5650:winlogon.exe 624 376 19 570 2019-10-29 17:08:54
... 0x82073020:services.exe 668 624 21 431 2019-10-29 17:08:54
.... 0x81FE52D0:vmtoolsd.exe 1664 668 5 284 2019-10-29 17:09:05
..... 0x81C0CDA0:cmd.exe 968 1664 0 ------ 2019-06-03 04:31:35
...... 0x81F14938:ipconfig.exe 304 968 0 ------ 2019-06-03 04:31:35
.... 0x822843E8:svchost.exe 1032 668 61 1169 2019-10-29 17:08:55
..... 0x822B9A10:wuauclt.exe 976 1032 3 133 2019-10-29 17:12:03
..... 0x820ECC10:wscntfy.exe 2040 1032 1 28 2019-10-29 17:11:49
.... 0x81E61DA0:svchost.exe 940 668 13 312 2019-10-29 17:08:55
.... 0x81DB8DA0:svchost.exe 856 668 17 193 2019-10-29 17:08:55
..... 0x81FA5390:wmiprvse.exe 1872 856 5 134 2019-06-03 04:25:58
.... 0x821A0568:VMUpgradeHelper 1816 668 3 96 2019-10-29 17:09:08
.... 0x81FEE8B0:spoolsv.exe 1412 668 10 118 2019-10-29 17:08:56
.... 0x81FF7020:svchost.exe 1200 668 14 197 2019-10-29 17:08:55
.... 0x81C47C00:lsass.exe 1928 668 4 65 2019-06-03 04:26:55
.... 0x81E18B28:svchost.exe 1080 668 5 80 2019-10-29 17:08:55
.... 0x8205ADA0:alg.exe 188 668 6 107 2019-10-29 17:09:09
.... 0x823315D8:vmacthlp.exe 844 668 1 25 2019-10-29 17:08:55
.... 0x81E0EDA0:jqs.exe 1580 668 5 148 2019-10-29 17:09:05
.... 0x81C498C8:lsass.exe 868 668 2 23 2019-06-03 04:26:55
.... 0x82279998:imapi.exe 756 668 4 116 2019-10-29 17:11:54
... 0x81E70020:lsass.exe 680 624 19 342 2019-10-29 17:08:54
系统启动了两个lsass.exe进程，它们的父pid为668，属于services.exe。但是，真正的lsass.exe（pid 680）的父pid为624，属于winlogon.exe。两个恶意lsass.exe进程的SID也与合法进程一样。
$ python vol.py -f stuxnet.raw --profile=WinXPSP3x86 getsids -p 680,868,1928
Volatile Systems Volatility Framework 2.6
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)
4.2进程优先级
进程基础优先级存储在EPROCESS.Pcb.BasePriority中，因此可以使用vol脚本查看。
$ python vol.py -f stuxnet.raw --profile=WinXPSP3x86 volshell
Volatile Systems Volatility Framework 2.6
Current context: process System, pid=4, ppid=0 DTB=0x319000
Leopard libedit detected.
Welcome to volshell! Current memory image is:
file:////memory/stuxnet.raw
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
从上面可以看出震网病毒创建lsass.exe进程的优先级低于合法lsass进程，由于线程的基本优先级是从拥有线程的进程的基本优先级继承的，因此使用threads命令来查看差异。
$ python vol.py -f stuxnet.raw --profile=WinXPSP3x86 threads
------
ETHREAD: 0x822722d0 Pid: 680 Tid: 1768
Tags: HookedSSDT
Created: 2019-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
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: 2019-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
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:
在Tid 1768中看到BasePriority为0x9，这是因为父进程（合法lsass.exe）具有BasePriority 0x9。 在Tid 764中看到的BasePriority 为0x8，是因为父进程（Stuxnet lsass.exe）具有BasePriority 0x8。Stuxnet的内核驱动程序通过使用KeStackAttachProcess API将DLL注入到进程中。
4.3动态链接库
震网病毒创建的恶意进程加载的DLL比合法进程要少很多，使用插件dlllist显示恶意进程的dll。
$python vol.py -f stuxnet.raw --profile=WinXPSP3x86 dlllist -p 680,868,1928
Volatile Systems Volatility Framework 2.6
************************************************************************
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
4.4注入代码
进程Services.exe，Lsass.exe加载的模块中没有微软的dll，那么它们很有可能使用了已注入的可执行代码，并且合法的Lsass没有 可执行数据区域，但这两个新的Lsass进程在其地址空间中的相同位置和相同大小处都具有执行和写入权限的区域，使用malfind插件可以自动查找并提取注入的可执行代码。
$python vol.py -f stuxnet.raw --profile=WinXPSP3x86 malfind -D out
Volatile Systems Volatility Framework 2.6
Name Pid Start End TagHits Protect
lsass.exe 868 0x000800000x000F9FFF 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插件将进程中的两个可疑区域定位在0x80000基址上。 它们都具有MM_EXECUTE_READWRITE权限，并以MZ开头，这意味着PE可能存储在此处。下一步找出注入代码的来源。
$python vol.py -f stuxnet.raw --profile=WinXPSP3x86 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
4.5隐藏的动态链接库
如果Stuxnet直接用磁盘上不存在的指定文件名调用LoadLibrary，通常会导致LoadLibrary失败。但是，W32.Stuxnet钩住了Ntdll.dll来监视加载指定文件名的请求。这些特制文件名被映射到另一个位置(由W32.Stuxnet指定的位置)。该位置通常是内存中以前被威胁解密并存储.dll文件的区域。使用的文件名具有KERNEL32.DLL.ASLR.。于是可以使用dlllist命令查看。
$python vol.py -f stuxnet.raw --profile=WinXPSP3x86 dlllist | grep ASLR
Volatile Systems Volatility Framework 2.6
Base Size Path0x013f0000 0x138000 C:\WINDOWS\system32\KERNEL32.DLL.ASLR.0360c5e2
0x00d00000 0x138000 C:\WINDOWS\system32\KERNEL32.DLL.ASLR.0360c8ee
0x00870000 0x138000 C:\WINDOWS\system32\KERNEL32.DLL.ASLR.0360b7ab
接下来使用ldrmodules插件，该插件可以将内存中的PE文件与映射文件以及PEB中的3个DLL列表进行比较。
$ python vol.py -f stuxnet.raw --profile=WinXPSP3x86 ldrmodules -p 1928
Volatile Systems Volatility Framework 2.6
Pid Process Base InLoad InInit InMem Path
1928 lsass.exe 0x00080000 0 0 0 -
1928 lsass.exe 0x7C900000 1 1 1 \WINDOWS\system32\ntdll.dll
1928 lsass.exe 0x773D0000 1 1 1 \WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.5512_x-ww_35d4ce83\comctl32.dll
1928 lsass.exe 0x77F60000 1 1 1 \WINDOWS\system32\shlwapi.dll
1928 lsass.exe 0x771B0000 1 1 1 \WINDOWS\system32\wininet.dll
1928 lsass.exe 0x77A80000 1 1 1 \WINDOWS\system32\crypt32.dll
1928 lsass.exe 0x77FE0000 1 1 1 \WINDOWS\system32\secur32.dll
1928 lsass.exe 0x77C00000 1 1 1 \WINDOWS\system32\version.dll
1928 lsass.exe 0x01000000 1 0 1 -
1928 lsass.exe 0x5B860000 1 1 1 \WINDOWS\system32\netapi32.dll
1928 lsass.exe 0x77E70000 1 1 1 \WINDOWS\system32\rpcrt4.dll
1928 lsass.exe 0x71AB0000 1 1 1 \WINDOWS\system32\ws2_32.dll
1928 lsass.exe 0x71AD0000 1 1 1 \WINDOWS\system32\wsock32.dll
1928 lsass.exe 0x774E0000 1 1 1 \WINDOWS\system32\ole32.dll
1928 lsass.exe 0x7E410000 1 1 1 \WINDOWS\system32\user32.dll
1928 lsass.exe 0x77F10000 1 1 1 \WINDOWS\system32\gdi32.dll
1928 lsass.exe 0x77120000 1 1 1 \WINDOWS\system32\oleaut32.dll
1928 lsass.exe 0x76D60000 1 1 1 \WINDOWS\system32\iphlpapi.dll
1928 lsass.exe 0x769C0000 1 1 1 \WINDOWS\system32\userenv.dll
1928 lsass.exe 0x7C800000 1 1 1 \WINDOWS\system32\kernel32.dll
1928 lsass.exe 0x76BF0000 1 1 1 \WINDOWS\system32\psapi.dll
1928 lsass.exe 0x77C10000 1 1 1 \WINDOWS\system32\msvcrt.dll
1928 lsass.exe 0x77DD0000 1 1 1 \WINDOWS\system32\advapi32.dll
1928 lsass.exe 0x7C9C0000 1 1 1 \WINDOWS\system32\shell32.dll
1928 lsass.exe 0x00870000 1 1 1 -
1928 lsass.exe 0x76F20000 1 1 1 \WINDOWS\system32\dnsapi.dll
1928 lsass.exe 0x5D090000 1 1 1 \WINDOWS\system32\comctl32.dll
1928 lsass.exe 0x71AA0000 1 1 1 \WINDOWS\system32\ws2help.dll
1928 lsass.exe 0x77B20000 1 1 1 \WINDOWS\system32\msasn1.dll
红色的三行可能是可疑信息，因为3个PEB列表中路径名是空白。 从上到下，首先看到0x80000处的PE，它没有文件支持，因此路径为空白。 这很可能是通过VirtualAlloc（Ex）和WriteProcessMemory注入的代码。接下来在ldrmodules插件后面加上-v标记来看一下0x01000000处的PE
$python vol.py -f stuxnet.raw --profile=WinXPSP3x86 ldrmodules -p 1928 -v
Volatile Systems Volatility Framework 2.6
Pid Process Base InLoad InInit InMem Path
1928 lsass.exe 0x00080000 0 0 0 -
1928 lsass.exe 0x01000000 1 0 1 -
Load Path: C:\WINDOWS\system32\lsass.exe : lsass.exe
Mem Path:C:\WINDOWS\system32\lsass.exe : lsass.exe
1928 lsass.exe 0x00870000 1 1 1 -
Load Path: C:\WINDOWS\system32\KERNEL32.DLL.ASLR.0360b7ab : KERNEL32.DLL.ASLR.0360b7ab
Init Path: C:\WINDOWS\system32\KERNEL32.DLL.ASLR.0360b7ab : KERNEL32.DLL.ASLR.0360b7ab
Mem Path:C:\WINDOWS\system32\KERNEL32.DLL.ASLR.0360b7ab : KERNEL32.DLL.ASLR.0360b7ab
从上可以确认0x01000000是主模块C：\ WINDOWS \ system32 \ lsass.exe的ImageBase。接下来使用使用procexedump或procmemdump提取此内存区域中存在的内容并将其与合法的lsass.exe进行比较来进行确认。
$python vol.py -f stuxnet.raw --profile=WinXPSP3x86 procexedump -p 680,868,1928 -D out
Volatile Systems Volatility Framework 2.6
************************************************************************
Dumping lsass.exe, pid: 680 output: executable.680.exe
************************************************************************
Dumping lsass.exe, pid: 868 output: executable.868.exe
************************************************************************
Dumping lsass.exe, pid: 1928 output: executable.1928.exe
下面是合法lsass.exe的信息：
$ python vol.py -f stuxnet.raw --profile=WinXPSP3x86 strings out/executable.680.exe
!This program cannot be run in DOS mode.
Rich
.text
`.data
.rsrc
ADVAPI32.dll
KERNEL32.dll
NTDLL.DLL
LSASRV.dll
SAMSRV.dll
下面是恶意lsass进程信息：
$ python vol.py -f stuxnet.raw --profile=WinXPSP3x86 strings out/executable.868.exe
!This program cannot be run in DOS mode.
Rich
.verif
.text
.bin
.reloc
ZwMapViewOfSection
ZwCreateSection
ZwOpenFile
ZwClose
ZwQueryAttributesFile
ZwQuerySection
TerminateProcess
GetCurrentProcess
CloseHandle
WaitForSingleObject
OpenProcess
ExitProcess
CreateThread
SetUnhandledExceptionFilter
SetErrorMode
KERNEL32.dll
AdjustTokenPrivileges
LookupPrivilegeValueW
OpenProcessToken
ADVAPI32.dll
VirtualProtect
GetModuleHandleW
GetCurrentThreadId
GetTickCount
lstrcpyW
lstrlenW
GetProcAddress
wsprintfW
USER32.dll
上面两个lsass.exe的二进制文件内容明显不同。 实际上，这是过程空心化的效果，Stuxnet使用第二种代码注入。 红色的API名称是被恶意软件钩住的，其他的可能来自文件的导入地址表。
名称为KERNEL32.DLL.ASLR.0360b7ab的PE在0x00870000上也不受磁盘上文件的支持，但在所有3个DLL列表中均受支持。 这是因为这是永远不会写入磁盘的“隐藏” DLL（试图逃避防病毒）。 这是Stuxnet实现的第三种代码注入/ DLL隐藏。
4.6Hooked APIs
在上一节中发现了6个被勾住的函数，接下来使用apihook函数来查看被钩住的函数信息。
$python vol.py -f stuxnet.raw --profile=WinXPSP3x86 apihooks
Volatile Systems Volatility Framework 2.6
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)
由于Ntdll.dll两次导出每个函数（一个用于Nt *，一个用于Zw *），因此输出了12条信息。接下来使用volshell插件来跟踪调用Hooked API的执行流程。
$python vol.py -f stuxnet.raw --profile=WinXPSP3x86 volshell
Volatile Systems Volatility Framework 2.6
Current context: process System, pid=4, ppid=0 DTB=0x319000
Welcome to volshell! Current memory image is:
file:///memory/stuxnet.raw
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
将红色的指令（属于ZwClose）与紫色的指令（属于Stuxnet未钩住的API）进行比较时，发现EDX中放置了一个不同的值。cleanAPI在0x7ffe0300处调用DWORD）。hooked API调用0x7c900050。因此，这是跟随rootkit时的下一跳。
>>> 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 , AL
在0x7c90005d，有一个call调用0x7c900066处的函数。 但是根据反汇编，0x7c900066位于从0x7c900062开始的指令中间。这可能是花指令。
>>> dis(0x7c900066)
0x7c900066 5a POP EDX
0x7c900067 ff22 JMP DWORD
当执行0x7c90005d处的CALL时，其返回的地址（0x7c900062）被压入堆栈。 然后，位于0x7c900066的POP EDX指令从堆栈中删除该值，并将其放入EDX中。 在0x7c900067处，EDX被取消引用并被调用。 因此，被取消引用的指针是0x7c900062。 该地址的4个字节(f2009400)在上方以红色突出显示。 给定字节，实际上是继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
红色部分显示了恶意软件最终如何调用所请求的系统服务。 它使用IDT而不是SSDT。 尽管Windows本身不再使用IDT进行系统服务分派（此方法在Windows 2000中已停止），但仍保留了IDT以实现向后功能。接下来搜索{8D 54 24 ?? CD 2E}在哪里。
$python vol.py -f stuxnet.raw --profile=WinXPSP3x86 malfind -p 668 -D out -Y "{8D 54 24 ?? CD 2E}"
Volatile Systems Volatility Framework 2.6
Name Pid Start End Tag Hits Protect
services.exe 668 0x00940000 0x00940FFF Vad 1 6 (MM_EXECUTE_READWRITE)
Dumped to: out/services.exe.2273020.00940000-00940fff.dmp
YARA rule: z1
Hit: 8d542408cd2e
0x00940145 8d 54 24 08 cd 2e eb 0c 5a 8d 54 24 08 64 ff 15 .T$.....Z.T$.d..
0x00940155 c0 00 00 00 85 c0 75 23 e8 b8 01 00 00 85 d2 74 ......u#.......t
Hit: 8d542408cd2e
0x009401ad 8d 54 24 08 cd 2e eb 0c 5a 8d 54 24 08 64 ff 15 .T$.....Z.T$.d..
0x009401bd c0 00 00 00 c3 e8 53 01 00 00 85 d2 74 20 50 57 ......S.....t PW
Hit: 8d542408cd2e
0x009401f8 8d 54 24 08 cd 2e eb 0c 5a 8d 54 24 08 64 ff 15 .T$.....Z.T$.d..
0x00940208 c0 00 00 00 c3 81 7c 24 08 ae 82 19 ae 75 03 33 ......|$.....u.3
Hit: 8d542408cd2e
0x00940242 8d 54 24 08 cd 2e eb 0c 5a 8d 54 24 08 64 ff 15 .T$.....Z.T$.d..
0x00940252 c0 00 00 00 c3 e8 be 00 00 00 85 d2 74 26 50 52 ............t&PR
Hit: 8d542408cd2e
0x00940293 8d 54 24 08 cd 2e eb 0c 5a 8d 54 24 08 64 ff 15 .T$.....Z.T$.d..
0x009402a3 c0 00 00 00 c3 e8 6d 00 00 00 85 d2 52 74 45 8b ......m.....RtE.
Hit: 8d542408cd2e
0x00940305 8d 54 24 08 cd 2e eb 0c 5a 8d 54 24 08 64 ff 15 .T$.....Z.T$.d..
0x00940315 c0 00 00 00 c3 50 56 57 51 52 83 ec 1c 8b c4 6a .....PVWQR.....j
services.exe 668 0x013F0000 0x01527FFF Vad 1 6 (MM_EXECUTE_READWRITE)
Dumped to: out/services.exe.2273020.013f0000-01527fff.dmp
YARA rule: z1
Hit: 8d542408cd2e
0x0144782e 8d 54 24 08 cd 2e eb 0c 5a 8d 54 24 08 64 ff 15 .T$.....Z.T$.d..
0x0144783e c0 00 00 00 85 c0 75 23 e8 b8 01 00 00 85 d2 74 ......u#.......t
Hit: 8d542408cd2e
0x01447896 8d 54 24 08 cd 2e eb 0c 5a 8d 54 24 08 64 ff 15 .T$.....Z.T$.d..
0x014478a6 c0 00 00 00 c3 e8 53 01 00 00 85 d2 74 20 50 57 ......S.....t PW
Hit: 8d542408cd2e
0x014478e1 8d 54 24 08 cd 2e eb 0c 5a 8d 54 24 08 64 ff 15 .T$.....Z.T$.d..
0x014478f1 c0 00 00 00 c3 81 7c 24 08 ae 82 19 ae 75 03 33 ......|$.....u.3
Hit: 8d542408cd2e
0x0144792b 8d 54 24 08 cd 2e eb 0c 5a 8d 54 24 08 64 ff 15 .T$.....Z.T$.d..
0x0144793b c0 00 00 00 c3 e8 be 00 00 00 85 d2 74 26 50 52 ............t&PR
Hit: 8d542408cd2e
0x0144797c 8d 54 24 08 cd 2e eb 0c 5a 8d 54 24 08 64 ff 15 .T$.....Z.T$.d..
0x0144798c c0 00 00 00 c3 e8 6d 00 00 00 85 d2 52 74 45 8b ......m.....RtE.
Hit: 8d542408cd2e
0x014479ee 8d 54 24 08 cd 2e eb 0c 5a 8d 54 24 08 64 ff 15 .T$.....Z.T$.d..
0x014479fe c0 00 00 00 c3 50 56 57 51 52 83 ec 1c 8b c4 6a .....PVWQR.....j
从上面可以看出两个内存区域都有6个hit，这与6个hooked API一致。
4.7 修改PE头部
要钩住上面指定的函数，恶意软件会为代码分配内存缓冲区，这些代码将调度对hooked api的调用，并使用将控制权转移到新函数的代码并覆盖PE头中的某些数据。使用yara规则来检测PE头的修改，yara的规则如下。
rule modified_pe_header {
strings:
$msg = "This program cannot"
condition:
uint16(0) == 0x5A4D and
uint32(uint32(0x3C)) == 0x00004550 and
not $msg
}
$ python vol.py -f stuxnet.raw --profile=WinXPSP3x86 malfind -D out -Y modified_pe_header.yar
Volatile Systems Volatility Framework 2.6
Name Pid Start End Tag Hits Protect
services.exe 668 0x7C900000 0x7C9AEFFF Vad 1 7 (MM_EXECUTE_WRITECOPY)
Dumped to: out/services.exe.2273020.7c900000-7c9aefff.dmp
YARA rule: modified_pe_header
svchost.exe 940 0x7C900000 0x7C9AEFFF Vad 1 7 (MM_EXECUTE_WRITECOPY)
Dumped to: out/svchost.exe.2061da0.7c900000-7c9aefff.dmp
YARA rule: modified_pe_header
lsass.exe 1928 0x7C900000 0x7C9AEFFF Vad 1 7 (MM_EXECUTE_WRITECOPY)
Dumped to: out/lsass.exe.1e47c00.7c900000-7c9aefff.dmp
YARA rule: modified_pe_header
以上结果表明Stuxnet在三个进程中修改了ntdll.dll。
4.8 文件
Stuxnet的最终修改包括在C：\ Windows \ Inf目录中创建四个其他文件：Oem7a.pnf，Mdmeric3.pnf，Mdmcpq3.pnf和Oem6c.pnf。” 于是使用handles命令可以查看当前是否有任何进程打开了指定文件的句柄，或者可以使用filescan查看在恶意软件创建文件后是否仍存在任何FILE_OBJECT结构。
$python vol.py -f stuxnet.raw --profile=WinXPSP3x86 handles | grep -i .pnf
Volatile Systems Volatility Framework 2.6
$
$ python vol.py -f stuxnet.raw --profile=WinXPSP3x86 filescan | grep -i .pnf
Volatile Systems Volatility Framework 2.6
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'
handles命令的输出为空。 创建PNF文件的进程已终止，或者该进程已调用CloseHandle。 但是，文件仍然可以找到活动的痕迹。
4.9网络连接
该恶意软件通过http与C＆C服务器通信。 URL列表包含在Stuxnet的Stuxnet配置数据中：
www.mypremierfutbol.com
www.todaysfutbol.com“
$ python vol.py -f stuxnet.raw --profile=WinXPSP3x86 connscan
Volatile Systems Volatility Framework 2.6
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
上面红色连接是可疑的，因为它是由浏览器进程创建的，并且IP映射回C＆C域之一。
$python vol.py -f stuxnet.raw --profile=WinXPSP3x86 pslist
Volatile Systems Volatility Framework 2.6
Offset(V) Name PID PPID Thds Hnds Time
---------- -------------------- ------ ------ ------ ------ -------------------
0x81af13b8 firefox.exe 528 356 4 112 2019-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
Stuxnet在其C＆C数据包中使用了特定的消息结构。 每条消息均以0x1恒定字节开头，并在偏移量2处具有OS主版本，在偏移量3处具有OS次版本，在偏移量4处具有OS Service Pack。
4.10注册表项
使用printkey读取内存中缓存的注册表项。 服务注册表项位于系统配置单元的ControlSet001 \ Services \ SERVICENAME下。
$python vol.py -f stuxnet.raw --profile=WinXPSP3x86 printkey -K 'ControlSet001\Services\MrxNet'
Volatile Systems Volatility Framework 2.6
Legend: (S) = Stable (V) = Volatile
----------------------------
Registry: \Device\HarddiskVolume1\WINDOWS\system32\config\system
Key name: MRxNet (S)
Last updated: 2019-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
$python vol.py -f stuxnet.raw --profile=WinXPSP3x86 printkey -K 'ControlSet001\Services\MrxCls'
Volatile Systems Volatility Framework 2.6
Legend: (S) = Stable (V) = Volatile
----------------------------
Registry: \Device\HarddiskVolume1\WINDOWS\system32\config\system
Key name: MRxCls (S)
Last updated: 2019-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 .<>
在上面可以看到解密后包含的一些系统进程名称和stuxnet文件的文件名。此数据让驱动程序知道stuxnet文件的文件名以及stuxnet将其文件注入到进程的名称。
病毒下载和工具下载：链接：https://pan.baidu.com/s/1YQKZletTL5vVrPGcXnGxvQ
提取码：nwie
lcxmap 发表于 2020-7-17 13:43
不好意思，想请问能跟您拿 stuxnet.raw 吗0.0
用吾爱的xp 虚拟机执行您的 malware.exe 没成功
我找找吧，不知道还在不在
天空藍 发表于 2019-11-27 02:14
加密或混淆的内容，也能使用这方式分析?
可以，因为volatility取证框架也有反汇编功能 楼主太厉害了！！！ 小白表示 好复杂 好牛比 感谢分享，来学习了 感谢分享，来学习了 用取证来分析病毒都能看到这么多有用的信息，还以为只有逆向可以 好东西， 感谢分享 厉害了把 感谢分享 加密或混淆的内容，也能使用这方式分析?