Windows 11 24H2 上的进程镂空技术

Process Hollowing on Windows 11 24H2  hasherezade's 1001 nights

进程镂空技术 (又称 RunPE)^[1]可能是最古老且最流行的进程伪装技术 (它允许恶意可执行文件在良性进程的掩护下运行)。这种技术被广泛应用于各种 PE 加载器、概念验证和攻击工具中。它也曾在涉及我的库 libPEconv^[2] 的演示中使用过。最近我收到了一个用户在 GitHub 上提出的问题，反映该演示在最新的 Windows 11 24H2 上不再有效^[3]。这个Windows 版本于 2024 年 10 月 1 日发布^[4]，虽然还很新，但正在逐渐普及。在寻找解决方案的过程中，我发现许多人在使用不同的 RunPE 实现时都遇到了相同的问题，这实际上是该技术本身的问题。然而，我发现的答案并没有真正触及问题的根源，所以我决定深入研究。在这篇简短的博客中，我描述了我的发现，希望能帮助遇到相同问题的其他人。

观察到的症状

在 PE 被植入到新创建的挂起进程后，我们恢复进程，植入程序应该使用典型的 Windows 加载器机制加载。然而，当我们在 Windows 11 24H2 上恢复 64 位进程时，加载会被中断并报错：0xC0000141。

根本原因

这个问题源于 Windows 加载器中实现的变化。然而，与一些人猜测的不同，执行并不是被控制流保护 (Control Flow Guard) 所阻止。事实证明原因要简单得多。

RunPE 的实现涉及将 payload 加载到新分配的内存中。根据技术的变体，可以通过两种方式实现：

• 取消映射原始 PE，在完全相同的地址分配内存，并在那里写入植入程序
• 分配新的内存区域，在那里写入植入程序，然后在 PEB 结构中将新区域设置为主模块的基地址

在这两种情况下，新的 PE 都存储在私有内存 (MEM_PRIVATE) 中，这与通常映射为镜像 (MEM_IMAGE) 的正常 PE 不同。这在后续过程中会产生重大差异。

在加载过程中，会依次调用以下函数：

LdrpInitializeProcess -> LdrpProcessMappedModule -> RtlpInsertOrRemoveScpCfgFunctionTable -> ZwQueryVirtualMemory

函数ZwQueryVirtualMemory旨在检索内存中每个模块的属性。它使用新参数`MemoryImageExtensionInformation`^[5]调用，该参数只能用于镜像 (MEM_IMAGE)。由于植入的 PE 不是镜像而是 MEM_PRIVATE，该函数会失败并返回错误 (STATUS_INVALID_ADDRESS)。

这进一步导致加载以观察到的错误终止。

解决方案

我们可以通过两种方法解决这个问题：

1. 使用将植入程序存储为 MEM_IMAGE 而不是 MEM_PRIVATE 的替代技术
2. 修补 NTDLL 以绕过检查

替代技术

虽然 RunPE 仍然是最知名和最流行的进程伪装技术，但同时也发展出了多种替代方案，使用这些方案我们可以将植入程序映射为 MEM_IMAGE 而不是 MEM_PRIVATE。

有一组技术首先创建一个节 (使用NtCreateSection)，然后使用本机 API NtCreateProcessEx从该节创建进程。这组技术包括：

• 进程分身 (Process Doppelganging)^[6] (概念验证^[7])
• 进程幽灵 (Process Ghosting)^[8] (概念验证^[9])
• 进程疱疹 (Process Herpaderping) (概念验证^[10])

然而，这组技术使用起来不如经典的 RunPE 方便。它涉及手动填充大量结构。另一个问题是，这种进程会与正常创建的进程有所区别，因为它是从未命名模块创建的 (GetProcessImageFileName返回空字符串)。这在 RunPE 的情况下不会发生。因此，虽然它们是技术库的不错补充，但并不能完美替代经典方案。

随着时间推移，出现了更多进程伪装选项。进程分身和进程幽灵启发了混合技术的产生，这些技术在实现上更接近进程镂空，但包含了使用 MEM_IMAGE 映射 PE 这一重大改进。这些混合技术包括：

• 事务性镂空 (Transacted Hollowing)^[11] (概念验证^[12])
• 幽灵镂空 (Ghostly Hollowing) (概念验证^[13])
• Herpaderply Hollowing (概念验证^[14])

对于这些技术，GetProcessImageFileName返回目标路径，进程更像是正常加载的进程。payload 被映射为未命名的 MEM_IMAGE。

后来，我想出了另一种加载器变体，它可以将 payload 映射为命名的 MEM_IMAGE，使其更类似于合法加载的 PE。实现细节和与其他技术的比较可以在以下仓库中找到：

• 进程覆写 (Process Overwriting) [概念验证^[15]]，[常见问题^[16]]

根据我最新的测试，事务性/幽灵镂空以及进程覆写在 Windows 11 24H2 上都能成功加载 PE，无需任何额外更改或补丁。

演示 (Windows 11 24H2 上的进程覆写)：

修补 NTDLL

如果出于某种原因，我们坚持使用原始 RunPE，并从 MEM_PRIVATE 运行我们的 payload，这仍然是可能的。但是，这将需要修补导致错误的函数 (ZwQueryVirtualMemory)。当然，我们希望补丁对其余执行的影响最小，所以它必须只过滤当我们查询包含 payload 的特定内存区域时的特定情况。

首先，我们检查我们的加载器是否运行在 Windows 11 24H2 或更高版本上，因为较低版本没有这个问题。此外，只有 64 位进程会受到影响。

补丁的功能可以用以下伪代码描述：

• 如果 MEMORY_INFORMATION_CLASS != MemoryImageExtensionInformation -> 调用原始的ZwQueryVirtualMemory
• 如果 ImageBase != implant_ptr -> 调用原始的ZwQueryVirtualMemory
• 否则 – 返回一个良性错误：STATUS_NOT_SUPPORTED

补丁的完整实现可以在这里找到：

https://github.com/hasherezade/libpeconv/blob/master/run_pe/patch_ntdll.cpp^[17]

最终，我们的植入程序的加载不会被中断，我们可以在 Windows 11 24H2 上愉快地使用进程镂空技术！

参考资料