背景：

大约3个月前，InfoSec社区介绍了一种称为“进程重映像（Process Reimaging）”的新型攻击技术。该技术由McAfee安全团队在博客中发布，标题为“我信任NTDLL——进程重镜像和绕过终端安全解决方案”。在这种攻击技术发布几天后，我的一位同事兼朋友Dwight Hohnstein给出了演示该技术的POC的代码，可在他的Github上找到。尽管该技术没有被归类到MITRE ATT&CK，但我相信它将属于“ 防御逃避 ”战术分类。

尽管此博客的目的是展示用来检测这种攻击的方法，但它假定您已阅读了McAfee团队发布的博客并阅读了Dwight的POC代码。攻击的的简要概述如下：

进程重镜像是一种利用Windows操作系统在确定进程镜像的FILE_OBJECT位置时存在的不一致的攻击技术。这意味着攻击者可以投递一个恶意二进制文件到磁盘上，并通过在执行初始阶段将完整文件路径替换为可信的二进制文件路径来隐藏恶意文件的物理位置。反过来，这允许攻击者绕过Windows操作系统的进程属性验证，允许在任选的进程镜像上下文中隐藏他们自身。

此攻击涉及三个阶段：

1. 投递二进制文件到磁盘。——这个假设指攻破系统并可以投递二进制文件到磁盘。
2. 加载未检测的二进制文件。这里指进程创建后加载的最初二进制镜像。
3. 恶意二进制文件被“重镜像”为想要显示成的一个已知无害二进制文件。这是可以实现的，因为虚拟地址描述符（Virtual Address Descriptors，VADs）在镜像被重命名后不会更新。因此，这允许当其它应用查询时，返回错误的进程镜像文件信息。

这使攻击者有机会防御性地逃避分析人员和应急响应人员的检测。通常的组织都没有收集到“正确”的数据。常常，收集的数据是非结构化的、免费的并缺少得出结论所需的实质性细节。如果没有高质量的数据，组织可能就不会发现穿越他们环境的程序采用的技术。而且，由于过度依赖EDR产品（如，Windows Defender，等等）的基本配置，您会将检测到的恶意活动的详细信息提供给第三方，第三方可能会也可能不会采用正确的函数调用来检测此恶意活动（如，使用GetMappedFileName正确地检测这种重镜像攻击）。基于这些因素，此攻击可使攻击者成功逃避检测。有关该攻击的更多细节信息，请查阅该主题的原始博客“技术深度学习”部分（译者注：McAfee原文中）。

注释：GetMapperedFileName是应用程序用来查询进程信息的API。它检查所请求的地址是否在指定进程地址空间中的内存映射文件内。如果地址在内存映射文件内，它会返回内存映射的文件名。该API需要PROCESS_QUERY_INFOMATION和PROCESS_VM_READ访问权限。任何时候，只要句柄具有PROCESS_QUERY_INFORMATION访问权限，它也会被授予pROCESS_QUERY_LIMITED_INFORMATION 。这些访问权限的位掩码为0x1010。这看起来很熟悉，因为这是使用Mimikatz所需的访问权限。Matt Graeber提醒我注意尝试基于授予的权限检测对LSASS的可疑访问时会有许多来源。

透明度：

该攻击发布后，我花费了一个星期六创建捕获假设，仔细研究数据的访问行为，并查找其关系。当阅读Dwight的POC时，我注意到代码中的Win32 API调用，据此，我确信我可以将这些API调用和特定事件关联起来。因为像许多防御产品一样，我做了一些假设像EDR产品和他们的记录功能。

没有已知的API到事件ID的映射，我自己开始映射这些调用。我开始时（并持续）专注映射的Sysmon方面。这涉及逆向工程Sysmon驱动来映射API调用到事件注册机制，再到事件ID。非常感谢Matt Graeber，他帮助我完成了这项任务，并花时间教我逆向工程的过程。创建此映射是我实施的“检测策略”的重要部分，没有它就不可能实现。

进程重映像检测：

检测方法：

进行这项检测的研究方法如下：

1. 阅读“进程重映像”攻击的技术文章。
2. 通读Dwight的POC代码。
3. 获得攻击是怎么执行的相关知识，在数据和攻击行为间建立关系。
4. 执行攻击。
5. 结合研究结果和数据关系进行可靠的检测。

检测浏览

当浏览 技术深度学习 部分时，这很醒目：

https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/in-ntdll-i-trust-process-reimaging-and-endpoint-security-solution-bypass/

上图展示了一些API调用，这些引起了我的兴趣。

1. LoadLibrary
2. CreateProcess

基于我对Sysmon驱动内部的研究，这两个API调用均被应用了某个事件注册机制。随后，该注册机制被Sysmon驱动使用输入/输出接口控制（IOCTL）代码调用来查询数据。查询的数据将会被传回Sysmon二进制文件，随后产生相关的事件ID。

上述两个API调用对应的过程如下所示：

Sysmon事件ID1的映射：进程创建

Sysmon事件ID 7 的映射：镜像加载

基于这项研究和McAfee文章中技术深入探讨部分，我知道了攻击执行时，会产生什么数据。Sysmon对每个LoadLibrary调用产生事件ID 7，CreateProcess调用产生事件ID 1；然而，我如何将数据转化为可操作的数据？ 威胁猎杀者可以轻易使用和操作以满足他们需求的数据？为此，我们专注于数据标准化和数据质量。

数据质量源自数据标准化。数据标准化是将数据转化为可以轻松分析的通用可读格式的过程。数据质量是确保环境收集正确数据的过程，可以用来定位特定的攻击技术。这可以通过对比非恶意数据产生的行为和攻击发生过程中的数据产生的行为之间的关系来实现。

例如，当创建一个进程是，OriginalFileName（Sysmon一个新添加项）应该与Sysmon事件ID 1中的镜像（Image）部分匹配。假设您要启动PowerShell，当你启动PowerShell，OriginalFileName将会是 Powershell.EXE, Image会是 C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe。如果这两项不匹配，则表明可能存在恶意活动。进程重镜像后，应用程序调用GetMappedFileName API来获取进程镜像文件，Windows会发送回错误的文件路径。

可以在事件ID 1的Image字段和事件ID 7中的ImageLoaded字段之间建立联系。因为事件ID 1 和 7 都有OriginalFileName字段，因此分析人员可以对两个事件的数据执行JOIN操作。该JOIN的结果会显示同样的正在创建的进程的进程路径和进程正在加载的Image相同。通过这种相关性，可以确定这两个事件来自同一活动子集。

上面的关系基于攻击的这一部分特征：

我们进行检测基于的函数片段：https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/in-ntdll-i-trust-process-reimaging-and-endpoint-security-solution-bypass/

尽管使用Sysmon事件ID 1 和 Sysmon 事件ID 7可以建立关系，但是还可以基于用户模式APINtCreateFile建立另一个关系。这会利用事件注册机制FltRegisterFilter创建的ID 11 事件——Sysmon中的文件创建。

可以在Sysmon事件ID 1 中的Image字段上关联此关系，该字段应该与Sysmon事件ID 11的TargetFilename字段匹配。要确保事件由同一进程引起，Sysmon事件ID 1 的ParentProcessGuid也应该与Sysmon 事件ID 11 的ProcessGuid字段匹配。

既然研究已经完成，就必须测试下假设。

数据分析

下面显示了正在执行的攻击指令。进程（phase1.exe）通过加载一个二进制文件（svchost.exe）被创建，然后重镜像为lsass.exe。

.\CSProcessReimagingPOC.exe C:\Windows\System32\svchost.exe C:\Windows\System32\lsass.exe

下面的SparkSQL代码是上述讨论的分析版本：

使用Jupyter Notebook和SparkSQL运行查询。Gist

我尝试使JOIN功能对用户尽可能可读。需要注意的一点是，该查询是从Sysmon的原始数据日志中提取的。SIEM管道内没有执行任何转换。

下面是使用SparkSQL在Jupyter Notebook中完成的join和数据相关性的直观表示。

该查询还检查了是否将创建的文件随后移动到其他目录，以及文件的OriginalFileName是否不等于Sysmon事件ID 1的Image。（例如，使用镜像创建的进程——“ApplyTrustOffline.exe”和OriginalFileName——“ApplyTrustOffline.PROGRAM”）检查之后，查询会仅仅返回重映像攻击的结果。

查询中JOINs的可视化视图

上面的SQL查询的输出可以在下面看到。在攻击貌似“重复”该事件后，您可以在查询输出的数据中找到。事实并非如此。每次攻击运行，会有Sysmon事件ID 11（FileCreate）在每个Sysmon事件ID 1（进程创建）后出发。这于上面讨论的攻击行为有关。

查询输出

与下面所进行分析相关的数据集和Jupyter Notebook可以在我的Github上获得。我鼓励每个人都拉去它以进行自己的数据分析。如果您没有实验室进行试验，这里可以找到一个：https://github.com/jsecurity101/mordor/tree/master/environment/shire/aws。

下面细分了各个阶段以及已运行的数据集的信息。这与上面的查询一致：

要记住的一件事是当恶意二进制文件被重映像为对抗者选择的二进制文件（阶段3）时，您不会看到“phase1.exe”被重映像成“lsass.exe”。这是攻击的行为。Windows将发回不正确的文件对象。这不会展示出该检测结果。我们的目标是发现攻击的行为，一旦做到这点，您可以按照“phase1.exe”的ProcessGuid或者去它的完整路径来找到它替换的二进制文件Image。“Phase1.exe”会出现在该重映像二进制的上下文中。

重映像执行后，phase1.exe属性的图片

结论：

进程重映像确实引起了我的兴趣，因为它似乎专注于在雷达下飞行以避免被发现。攻击者利用的每种技术会具有符合攻击行为的数据。这是可以利用的，但只有在我们了解我们的数据和数据源后才可以。从基于特征的搜索转向更多的数据驱动搜索方法将有助于提高检测的鲁棒性。

致谢：

非常感谢Matt Graeber帮助我Sysmon驱动的逆向工程。感谢Dwight Hohnstein，他提供了POC代码。最后，感谢Brian Reitz在SQL无法工作时提供的帮助。

参考/资源：

• In NTDLL I Trust — Process Reimaging and Endpoint Security Solution Bypass
• Dwight’s Process Reimaging POC
• Microsoft Docs

原文：https://posts.specterops.io/you-can-run-but-you-cant-hide-detecting-process-reimaging-behavior-e6bb9a10c40b
编译：看雪翻译小组 sudozhange
校对：看雪翻译小组 玉林小学生

[培训]《安卓高级研修班(网课)》月薪三万计划，掌握调试、分析还原ollvm、vmp的方法，定制art虚拟机自动化脱壳的方法