基于内存取证进行stuxnet 病毒分析（上）

最新推荐文章于 2024-01-15 16:59:31 发布

sea nine sun

最新推荐文章于 2024-01-15 16:59:31 发布

阅读量1.9k

点赞数

分类专栏：病毒分析文章标签：安全

本文链接：https://blog.csdn.net/weixin_46286477/article/details/121343841

版权

病毒分析专栏收录该内容

2 篇文章

订阅专栏

基于内存取证进行stuxnet 病毒分析（上）

stuxnet病毒翻译过来又叫震网病毒，是美国针对伊朗核电站进行的有组织开发的恶意病毒。主要是利用Windows操作系统未被发现的四个漏洞，可以通过U盘，打印机等进行传播，无需借助网络连接。通过提权的操作可以进行对其设备发送命令，造成严重的破坏。
下面本文从内存取证的角度对震网病毒进行分析。

1.扫描进程之间的关系

前提知识：一个普通的 Windows XP 安装只有一个 Lsass.exe 实例，Winlogon 进程在系统启动时创建它。
下面使用volatility中Pstree来查看进程。
代码： python vol.py -f stuxnet.vmem --profile WinXPSP2x86 pstree
显示结果：
在这里插入图片描述

可以看到一共有三个lsass.exe，其中父 pid 为 668属于 services.exe 。父 pid 为 624，它属于 winlogon.exe。进程树显示两个新的 Lsass.exe 实例都是由Services.exe…服务控制管理器，这意味着 Stuxnet 以某种方式将其代码放入了 Services.exe 进程中。

2.进程优先级

前提知识：一些 Windows 系统进程（例如会话管理器、服务控制器和本地安全认证服务器）的基本进程优先级略高于 Normal 类的默认值 (8)。进程基本优先级存储在 EPROCESS.Pcb.BasePriority 中。
下面用一个脚本来查看一下进程的优先级。
代码：python vol.py -f stuxnet.vmem --profile WinXPSP2x86 volshell
import volatility.win32.tasks as tasks

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.UniqueProcessId in (680, 868, 1928)：
… print “Pid: {0} Priority: {1}”.format(task.UniqueProcessId, task.Pcb.BasePriority)
…

显示结果：在这里插入图片描述
合法的本地安全认证服务器 (lsass.exe) 将比普通进程具有更高的优先级，包括由 Stuxnet 创建的进程。BasePriority合法的 lsass.exe (pid 680) 为 9，而 Stuxnet 创建的 lsass.exe (pid 868、1928)为 8。

3.查看震网病毒的DLL

震网病毒创建的恶意进程加载的DLL比合法进程要少很多，使用插件dlllist显示恶意进程的dll。
代码：python vol.py -f stuxnet.vmem --profile WinXPSP2x86 dlllist -p 680,868,1928
结果：
lsass.exe pid: 680
Command line : C:\WINDOWS\system32\lsass.exe
Service Pack 3

Base Size LoadCount LoadTime Path

lsass.exe pid: 868
Command line : “C:\WINDOWS\system32\lsass.exe”
Service Pack 3

Base Size LoadCount LoadTime Path

lsass.exe pid: 1928
Command line : “C:\WINDOWS\system32\lsass.exe”
Service Pack 3

Base Size LoadCount LoadTime Path

0x01000000 0x6000 0xffff C:\WINDOWS\system32\lsass.exe
0x7c900000 0xaf000 0xffff C:\WINDOWS\system32\ntdll.dll
0x7c800000 0xf6000 0xffff C:\WINDOWS\system32\kernel32.dll
0x77dd0000 0x9b000 0xffff C:\WINDOWS\system32\ADVAPI32.dll
0x77e70000 0x92000 0xffff
…12个
C:\WINDOWS\system32\WININET.dll
0x77a80000 0x95000 0x2 C:\WINDOWS\system32\CRYPT32.dll
0x77b20000 0x12000 0x2 C:\WINDOWS\system32\MSASN1.dll
0x71ad0000 0x9000 0x2 C:\WINDOWS\system32\WSOCK32.dll
0x773d0000 0x103000 0x2 C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.5512_x-ww_35d4ce83\comctl32.dll
0x5d090000 0x9a000 0x1 C:\WINDOWS\system32\comctl32.dll

4.代码注入

前提知识：合法的 Lsass 没有可执行数据区域，但两个新的 Lsass 进程在它们的地址空间中都具有相同位置和相同大小的具有执行和写入权限的区域。
代码： python vol.py -f stuxnet.vmem --profile WinXPSP2x86 malfind
结果显示：
在这里插入图片描述

Malfind 在两个进程的基地址 0x80000 处找到了两个可疑区域。它们具有 MM_EXECUTE_READWRITE 权限并以 MZ 开头，这意味着 PE 可能存储在这里。

5.DLL怎么隐藏的呢？

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
显示结果：
![在这里插入图片描述](https://img-blog.csdnimg.cn/58ad588a8a524991a9d81858f3be39d6.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA5biI5aeQ55qE5bCP5biI5aa5,size_16,color_FFFFFF,t_70,g_se,x_16
结论:恶意的 lsass.exe 二进制文件的内容明显不同。这实际上是进程hollow的效果——Stuxnet 使用的第二种代码注入。红色框中的 API 的名称是被恶意软件钩住的 API（参见 Artifact 6），其他 API 可能来自文件的导入地址表。

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 时的执行流。
在这里插入图片描述