写在前边
2. 调查伪进程注入
(Hollow Process Injection)
在前面介绍的代码注入技术中，恶意代码被注入到合法进程的进程地址空间中。伪进程注入(或进程空化)也是一种代码注入技术，但不同的是，在这种技术中，内存中合法进程的进程可执行文件被替换为恶意可执行文件。
在讨论伪进程的检测之前，让我们先了解一下它是如何工作的。关于中空过程注入的详细信息在先前的章节代码注入和钩子中介绍过。我们可以查看作者关于伪进程注入的演示和视频演示，以便更好地理解这个主题。
https://cysinfo.com/7th-meetup-reversing-and-investigating-malware-evasive-tactics-hollow-process-injection/*左右滑动查看更多
2.1 伪进程注入步骤
下面步骤描述了恶意软件通常是如何执行进程伪装的。假设有两个进程A和B，此时，A进程是恶意进程，B进程是合法进程(也称为远程进程)，例如explorer.exe:
•进程A以挂起的方式启动正常进程B。结果，进程B的可执行部分被加载到内存中，并且PEB(进程环境块)识别到合法进程的完整路径。PEB结构的ImageBaseAddress字段指向装载合法进程可执行文件的基地址。
•进程A获得将注入远程进程的恶意可执行文件。这个可执行文件可以来自恶意软件进程的资源部分或来自磁盘上的文件。
•进程A确定了合法进程B的基址，这样它就可以解除合法进程的可执行部分的映射。恶意软件可以通过读取PEB来确定基址(在我们的例子中，是PEB.imagebaseaddress)。
•进程A释放合法进程的可执行部分。进程A将合法进程B中的内存分配为读、写、执行权限。这个内存分配通常是在与之前加载可执行文件的地址相同。
•进程A将恶意可执行文件的PE头和PE段写入到已分配的内存中。
•进程A将挂起线程的起始地址更改为注入的可执行文件的入口点的地址，并恢复正常进程挂起的线程。因此，合法进程现在开始执行恶意代码。
Stuxnet就是这样一种恶意软件，它使用上述步骤执行伪进程注入。具体来说，Stuxnet在挂起模式下创建合法的lasss.exe进程。因此，lasss.exe通过PAGE_EXECUTE_WRITECOPY(WCX)保护加载到内存中。此时(在空化之前)，PEB和VAD都包含关于lasss.exe的内存保护、基址和完整路径的相同元数据信息。
然后，Stuxnet将合法的进程可执行文件(lasss.exe)挖空，并在之前加载lasss.exe的同一区域内，用PAGE_EXECUTE_READWRITE (RWX)保护分配一个新的内存，然后在分配的内存中注入恶意的可执行文件并恢复挂起的线程。
由于掏空了进程可执行文件，导致VAD和PEB之间的进程路径信息存在差异，即PEB中的进程路径仍然包含lasss.exe的完整路径，而VAD不显示完整路径。
此外，在空化之前(WCX)和空化之后(RWX)存在内存保护差异。下面的图表可以帮助你可视化空心化之前发生了什么，以及空心化过程后在PEB和VAD中产生的差异:
使用内存取证技术对震网病毒进行了完整的分析，Michael Hale Ligh在下面的博客文章中有详细介绍：
http://mnin.blogspot.in/2011/06/examining-stuxnets-footprint-in-memory.html*左右滑动查看更多
2.2 识别伪进程注入
为了检测中伪进程注入，我们可以寻找PEB和VAD之间产生的差异，以及内存保护差异。我们还可以查找父子流程关系中的差异。
在下面的Stuxnet示例中，我们可以看到系统上运行着两个lasss.exe进程。第一个lasss.exe进程(pid 708)有一个父进程winlogon.exe (pid 652)，而第二个lasss.exe进程(pid 1732)有一个终止的父进程(pid 1736)。
根据进程信息，可以判断pid为1732的lasss.exe是可疑的进程，因为在一个干净的系统上，winlogon.exe将是lasss.exe在pre-Vista机器上的父进程，wininit.exe将是lasss.exe在Vista和以后的系统上的父进程:
$ python vol.py -f stux.vmem --profile=WinXPSP3x86 pslist | grep -i lsass Volatility Foundation Volatility Framework 2.60x818c1558 lsass.exe 708 652 24 343 0 0 2016-05-10 06:47:24+0000 0x81759da0 lsass.exe 1732 1736 5 86 0 0 2018-05-12 06:39:42$ python vol.py -f stux.vmem --profile=WinXPSP3x86 pslist -p 652 Volatility Foundation Volatility Framework 2.6Offset(V) Name PID PPID Thds Hnds Sess Wow64 Start---------- ------------ ---- ---- ---- ---- --- ------ ------------------ 0x818321c0 winlogon.exe 652 332 23 521 0 0 2016-05-10 06:47:24$ python vol.py -f stux.vmem --profile=WinXPSP3x86 pslist -p 1736Volatility Foundation Volatility Framework 2.6ERROR : volatility.debug : Cannot find PID 1736. If its terminated orunlinked, use psscan and then supply --offset=OFFSET
*左右滑动查看更多
如前所述，我们可以通过比较PEB和VAD结构来检测伪进程。dlllist插件从PEB获取模块信息，显示lasss.exe (pid 1732)的完整路径和它加载的base地址(0x01000000):
lsass.exe pid: 1732Command line : "C:WINDOWS\system32\lsass.exe"Service Pack 3Base Size Load Count 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 [REMOVED]
*左右滑动查看更多
ldrmodules插件依赖于内核中的VAD，它不会向lasss.exe显示完整的路径名称。由于恶意软件解除了lasss.exe进程可执行部分的映射，完整路径名不再与地址0x01000000关联:
$ python vol.py -f stux.vmem --profile=WinXPSP3x86 ldrmodules -p 1732 Volatility Foundation Volatility Framework 2.6Pid Process Base InLoad InInit InMem MappedPath---- --------- ---------- ------ ------ ------ ---------------------------- [REMOVED]1732 lsass.exe 0x7c900000 True True True WINDOWSsystem32ntdll.dll 1732 lsass.exe 0x71ad0000 True True True WINDOWSsystem32wsock32.dll 1732 lsass.exe 0x77f60000 True True True WINDOWSsystem32shlwapi.dll 1732 lsass.exe 0x01000000 True False True1732 lsass.exe 0x76b40000 True True True WINDOWSsystem32winmm.dll[REMOVED]
*左右滑动查看更多
由于恶意软件通常在空化之后和注入可执行文件之前以PAGE_EXECUTE_READWRITE权限分配内存，所以我们可以寻找内存保护。malfind插件在可执行lasss.exe加载的同一地址(0x01000000)识别了可疑的内存保护:
Process: lsass.exe Pid: 1732 Address: 0x1000000 Vad Tag: Vad Protection: PAGE_EXECUTE_READWRITE Flags: CommitCharge: 2, Protection: 60x01000000 4d 5a 90 00 03 00 00 00 04 00 00 00 ff ff 00 00 MZ.............. 0x01000010 b8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 ........@....... 0x01000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0x01000030 00 00 00 00 00 00 00 00 00 00 00 00 d0 00 00 00 ................0x01000000 4d DEC EBP0x01000001 5a POP EDX0x01000002 90 NOP
*左右滑动查看更多
如果希望将malfind检测到的可疑内存区域转储到磁盘，可以在-D后面指定将转储所有可疑内存区域的目录名称。
2.3 进程注入变种
在下面的例子中，我们将看到一个名为Skeeyah的恶意软件，它以一种略微不同的方式执行伪进程注入。这是在代码注入和钩子中介绍的同一个示例。以下是Skeeyah所执行的步骤:
• 它以挂起模式启动svchost.exe进程。作为一个结果，svchost.exe被加载到内存中(在本例中，地址为0x1000000)。
•通过读取PEB来确定svchost.exe的基址。ImageBaseAddress，然后释放svchost.exe的可执行部分。
•它不是在之前加载svchost.exe的同一区域分配内存(0x1000000)，而是在不同的地址0x00400000，具有读、写和执行权限。
•覆盖PEB。svchost.exe进程的imagebaseaddress，带有新分配的地址0x00400000。这会将PEB中的svchost.exe的基址从0x1000000更改为0x00400000(其中包含注入的可执行文件)。
• 将挂起的线程的起始地址更改为注入的可执行文件的入口点的地址，并恢复线程。
下面的截图显示了空化前后的差异。具体来说，空化后的PEB认为svchost.exe在0x00400000处加载。之前表示svchost.exe(加载在0x1000000)的VAD节点不再存在，因为当恶意软件掏空svchost.exe进程可执行文件时，VAD树中删除了该节点的条目:
要检测伪进程的这种变化，可以遵循相同的方法。根据伪进程的执行方式，结果会有所不同。进程列表显示了svchost.exe进程的多个实例，这是正常的。除了最后一个svchost.exe (pid 1824)之外，所有svchost.exe进程都有一个父进程services.exe (pid 696)。
在一个干净的系统中，所有svchos.exe进程都是由services.exe启动的。当我们查看svchost.exe (pid 1824)的父进程时，可以看到它的父进程已经终止。根据进程信息，可以看出最后一个svchost.exe (pid 1824)是可疑的:
$ python vol.py -f skeeyah.vmem --profile=WinXPSP3x86 pslist | grep -i svchostVolatility Foundation Volatility Framework 2.60x815cfaa0 svchost.exe 876 696 20 202 0 0 2016-05-10 06:47:25 0x818c5a78 svchost.exe 960 696 9 227 0 0 2016-05-10 06:47:25 0x8181e558 svchost.exe 1044 696 68 1227 0 0 2016-05-10 06:47:25 0x818c7230 svchost.exe 1104 696 5 59 0 0 2016-05-10 06:47:25 0x81743da0 svchost.exe 1144 696 15 210 0 0 2016-05-10 06:47:25 0x817ba390 svchost.exe 1824 1768 1 26 0 0 2016-05-12 14:43:43$ python vol.py -f skeeyah.vmem --profile=WinXPSP3x86 pslist -p 696 Volatility Foundation Volatility Framework 2.6Offset(V) Name PID PPID Thds Hnds Sess Wow64 Start---------- ------------ --- ---- ---- ---- ---- ------ -------------------- 0x8186c980 services.exe 696 652 16 264 0 0 2016-05-10 06:47:24$ python vol.py -f skeeyah.vmem --profile=WinXPSP3x86 pslist -p 1768 Volatility Foundation Volatility Framework 2.6ERROR : volatility.debug : Cannot find PID 1768. If its terminated or unlinked, use psscan and then supply --offset=OFFSET
*左右滑动查看更多
dlllist插件(依赖于PEB)显示svchost.exe (pid 1824)的完整路径，并报告base地址为0x00400000。
$ python vol.py -f skeeyah.vmem --profile=WinXPSP3x86 dlllist -p 1824 Volatility Foundation Volatility Framework 2.6 ************************************************************************ svchost.exe pid: 1824Command line : "C:WINDOWSsystem32svchost.exe"Service Pack 3Base Size LoadCount Path---------- ------- ---------- ----------------------------------0x00400000 0x7000 0xffff0x7c900000 0xaf000 0xffff0x7c800000 0xf6000 0xffff[REMOVED]C:WINDOWSsystem32svchost.exeC:WINDOWSsystem32ntdll.dllC:WINDOWSsystem32kernel32.dll
*左右滑动查看更多
另一方面，ldrmodules插件(依赖于内核中的VAD)并没有显示svchost.exe的任何条目，如下图所示:
malfind显示在0x00400000地址存在一个PE文件，其中存在一个可疑的PAGE_EXECUTE_READWRITE内存保护，这表明这个可执行文件被注入了，并且没有正常加载:
=WinXPSP3x86 malfind -p 1824 Volatility Foundation Volatility Framework 2.6Process: svchost.exe Pid: 1824 Address: 0x400000Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITEFlags: CommitCharge: 7, MemCommit: 1, PrivateMemory: 1, Protection: 60x00400000 4d 5a 90 00 03 00 00 00 04 00 00 00 ff ff 00 00 MZ.............. 0x00400010 b8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 ........@....... 0x00400020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0x00400030 00 00 00 00 00 00 00 00 00 00 00 00 e0 00 00 00 ................0x00400000 4d DEC EBP0x00400001 5a POP EDX[REMOVED]
*左右滑动查看更多
|
|
攻击者使用不同的空心工艺注射来绕过、偏转和转移司法分析。关于这些规避技术如何工作以及如何使用自定义Volatility性插件检测它们的详细信息，请观看作者的黑帽演讲:“恶意软件作者不想让你知道的东西-规避伪进程注入”：
https://youtu.be/9L9I1T5QDg4或者，您也可以阅读作者在以下链接的博客文章:
https://cysinfo.com/detecting-deception-hollow-techniques/*左右滑动查看更多
（未完待续）
原文始发于微信公众号（安恒信息安全服务）：九维团队-青队（处置）| 使用内存取证检测高级恶意软件（二）
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论