基于内存取证的stuxnet病毒分析(上) stuxnet病毒翻译后又称stuxnet病毒，是美国针对伊朗核电站组织开发的恶意病毒。 主要利用Windows操作系统中未发现的4个漏洞，可以在USB存储器、打印机等中传播，不需要通过网络连接。 通过提权的操作，可以向该设备发送命令，引起严重的破坏。
本文从内存取证的角度分析stuxnet病毒。
1 .扫描进程之间的关系前提知识：典型的Windows XP安装只有一个Lsass.exe实例，Winlogon进程在系统启动时创建它。
接下来，使用volatility中的Pstree验证流程。
代码： python vol.py-fstuxnet.vmem-- profilewinxpsp2x86 pstree
显示结果：
您可以看到共有三个lsass.exe，其中父pid为668，属于services.exe。 父pid为624，属于winlogon.exe。 进程树显示两个新的Lsass.exe实例正在由Services.exe…服务控制管理器进行管理。 也就是说，Stuxnet以某种方式将其代码放置在Services.exe进程中。
2 .进程优先级前提知识：某些Windows系统进程(如会话管理器、服务控制器和本地安全认证服务器)的基本进程优先级略高于正常类默认值(8)。 进程的基本优先级存储在EPROCESS.Pcb.BasePriority中。
使用以下脚本检查进程的优先级：
代码： python vol.py-fstuxnet.vmem-- profilewinxpsp2x86 vol外壳
import volatility.win32.tasksastasks
import volatility.utils as utils
addr _ spac=utils.load _ as (self._ config )
all_tasks=list(tasks.pslist ) addr_spac ) )
for task in all_tasks:
…if task.uniqueprocessidin (680，868，1928 ) :
…print“PID : priority : {1}”. format (task.unique processid，task.Pcb.BasePriority )。
.
显示结果：
合法的本地安全认证服务器(lsass.exe )优先于常规进程，包括由Stuxnet创建的进程。 BasePriority的合法lsass.exe(PID680 )为9，Stuxnet创建的lsass.exe (PID 868，1928 )为8。
3 .检查3.stuxnet病毒由DLLstuxnet病毒创建的恶意进程加载的DLL远远少于合法进程，并使用插件DLLlist显示恶意进程的dll。
代码： python vol.py-fstuxnet.vmem-- profilewinxpsp2x86 dlllist-p680、868、1928
结果：
lsass.exe pid: 680
command line : c :windowssystem32lsass.exe
服务包3
基本大小加载计数加载时间路径
0x 01000000 x 60000 xffffc :windowssystem32lsass.exe
0x7c 900000 xaf 0000 xffffc :windowssystem32ntdll.dll
0x7c 800000 xf 60000 xffffc :windowssystem32kernel32.dll
0x 77dd 00000 x9b 0000 xffffc :windowssystem32advapi32.dll
0x77e 700000 x 920000 xffffc :windowssystem32rpcrt4.dll
. 60个
lsass.exe pid: 868
命令行：“c :windowssystem32lsass.exe”
服务包3
基本大小加载计数加载时间路径
0x 01000000 x 60000 xffffc :windowssystem32lsass.exe
0x7c 900000 xaf 0000 xffffc :windowssystem32ntdll.dll
0x7c 800000 xf 60000 xffffc :windowssystem32kernel32.dll
0x 77dd 00000 x9b 0000 xffffc :windowssystem32advapi32.dll
0x77e
70000 0x92000 0xffff C:WINDOWSsystem32RPCRT4.dll0x77fe0000 0x11000 0xffff C:WINDOWSsystem32Secur32.dll
0x7e410000 0x91000 0xffff C:WINDOWSsystem32USER32.dll
0x77f10000 0x49000 0xffff C:WINDOWSsystem32GDI32.dll
lsass.exe pid: 1928
Command line : “C:WINDOWSsystem32lsass.exe”
Service Pack 3
Base Size LoadCount LoadTime Path
0x01000000 0x6000 0xffff C:WINDOWSsystem32lsass.exe
0x7c900000 0xaf000 0xffff C:WINDOWSsystem32ntdll.dll
0x7c800000 0xf6000 0xffff C:WINDOWSsystem32kernel32.dll
0x77dd0000 0x9b000 0xffff C:WINDOWSsystem32ADVAPI32.dll
0x77e70000 0x92000 0xffff
…12个
C:WINDOWSsystem32WININET.dll
0x77a80000 0x95000 0x2 C:WINDOWSsystem32CRYPT32.dll
0x77b20000 0x12000 0x2 C:WINDOWSsystem32MSASN1.dll
0x71ad0000 0x9000 0x2 C:WINDOWSsystem32WSOCK32.dll
0x773d0000 0x103000 0x2 C:WINDOWSWinSxSx86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.5512_x-ww_35d4ce83comctl32.dll
0x5d090000 0x9a000 0x1 C:WINDOWSsystem32comctl32.dll
前提知识：合法的 Lsass 没有可执行数据区域，但两个新的 Lsass 进程在它们的地址空间中都具有相同位置和相同大小的具有执行和写入权限的区域。
代码： python vol.py -f stuxnet.vmem --profile WinXPSP2x86 malfind
结果显示：
Malfind 在两个进程的基地址 0x80000 处找到了两个可疑区域。它们具有 MM_EXECUTE_READWRITE 权限并以 MZ 开头，这意味着 PE 可能存储在这里。
W32.Stuxnet 已钩住 Ntdll.dll 以监视加载特制文件名的请求。这些特制文件名被映射到另一个位置 - W32.Stuxnet 指定的位置。该位置通常是内存中的一个区域，其中 .dll 文件先前已被威胁解密并存储。使用的文件名具有 KERNEL32.DLL.ASLR 模式。
代码： python vol.py -f stuxnet.vmem --profile WinXPSP2x86 dlllist | grep ASLR
显示结果：
接下来使用ldrmodules插件，该插件可以将内存中的PE文件与映射文件以及PEB中的3个DLL列表进行比较。
代码：python vol.py -f stuxnet.vmem --profile WinXPSP2x86 ldrmodules -p 1928 -v
显示结果：
那么多地址为什么要选择这三个呢？是因为在没-v之前，这三个地址对应的PEB列表中路径名是空白。
显示结果:
从上可以确认0x01000000是主模块C： WINDOWS system32 lsass.exe的ImageBase。接下来使用使用procexedump或procmemdump提取此内存区域中存在的内容并将其与合法的lsass.exe进行比较来进行确认。
代码：python vol.py -f stuxnet.vmem --profile WinXPSP2x86 procdump -p 680,868,1928 -D out
显示结果：
通过命令：strings out/executable.680.exe 来查看具体内容
1.首先看正常的lsass.exe
代码：strings out/executable.680.exe
显示结果：
2.查看注入的lsass.exe
代码：strings out/executable.868.exe
显示结果：
结论:恶意的 lsass.exe 二进制文件的内容明显不同。这实际上是进程hollow的效果——Stuxnet 使用的第二种代码注入。红色框中的 API 的名称是被恶意软件钩住的 API（参见 Artifact 6），其他 API 可能来自文件的导入地址表。
通过ａｐｉｈｏｏｋｓ进行分析。
代码：python vol.py -f stuxnet.vmem --profile WinXPSP2x86 apihooks -p 668
显示结果：总共12个，上一节看到有六个APIhook函数。如果有6个连接的 api，为什么有12行的输出？由于 Ntdll.dll 将每个函数导出两次(一次用于 Nt * ，一次用于 Zw *) ，因此 apihooks 插件将两者都显示出来。另外，很明显 Stuxnet 使用类似于“ syscall”挂接技术，而不是更常见的 Inline/IAT/EAT 挂接技术。要以交互方式探索钩子地址周围的代码，请使用以下命令。这一次，我们将使用它来跟踪调用已挂钩的 API 时的执行流。