大概三个月前，一种新的攻击技术出現在安全社区，名叫「进程重镜像」。 此项技术是由 McAfee 安全性精英团队在一篇题目为“进程重镜像和 *** 安全审计解决 *** 绕开”的博闻中发布的，在这类攻击技术发布的几日后，我的一个朋友也是盆友—— Dwight ——取出了定义认证编码（PoC），演试了这类技术，能够在他的 GitHub 上寻找。 尽管此项技术都还没投射到 MITRE ATT&CK 中，但相信它归属于防御力避开战略。

虽然我写这篇 *** 文章的目地是展现用以检验这类攻击的方式，可是它假定你早已读过 McAfee 安全性精英团队发布的 *** 文章而且看了 Dwight 的定义认证编码。 此次攻击的简略概述以下:

进程重镜像是一种攻击技术，它运用了 Windows 电脑操作系统在明确进程镜像 FILE 目标部位全过程中的不一致性。 这代表着攻击者能够删掉硬盘上的二进制文件，并根据将其原始实行详细文件路径更换为受信赖的二进制文件来掩藏该文件的物理学部位。 这相反容许攻击者绕开 Windows 电脑操作系统进程特性认证，将自身掩藏在她们挑选的进程镜像的前后文中。

这类攻击包含三个环节：

· 将二进制文件载入到硬盘ーー这儿假定攻击者能够将二进制文件载入到硬盘。

· 未检验到的二进制载入。这将是进程建立后载入的初始镜像。

· 故意二进制文件被“重镜像”到一个攻击者期待以某类 *** 出現的已经知道的好的二进制文件。 它是能够完成的，由于重新命名镜像时，虚拟注册地址描述符(VAD)不升级。 因而，当应用软件查看时，这会回到不正确的进程镜像文档信息内容。

这使敌人还有机会保护性地避开剖析工作人员和事件响应者的检验工作中。 机构通常沒有搜集到“恰当”的数据信息。 一般 ，数据信息是是非非结构型的、无必需的，而且欠缺下结论需要的实际性关键点。 要是没有高品质的数据信息，机构很有可能会对在其环境中运行的技术置若罔闻。 除此之外，因为过度依靠 EDR 商品的基础配备(比如，Windows Defender 等) ，你将检验的关键点出示给第三方，而第三方很有可能应用或不应用恰当的调用函数来检验这类故意个人行为(比如 GetMappedFileName 能够恰当检验这类重镜像攻击)。 根据这种要素，这类攻击容许敌人取得成功躲避探测。 要掌握大量有关这类攻击的內容和信息内容，请查询有关这一主题风格的初始 *** 文章中的 “技术探索与发现” 一部分。

留意: GetMappedFileName 是应用软件用以查看进程信息内容的 API。 它查验所要求的详细地址是不是在特定进程详细地址室内空间中的内存映射文档内。 假如详细地址在内存映射文档内，它将回到内存映射文档的名字。 这一 API 必须 PROCESS_QUERY_INFORMATION 和 PROCESS_VM_READ 访问限制。 任何时刻当某一句柄具备了访问限制 PROCESS_QUERY_INFORMATION，它也就被授于了 PROCESS_QUERY_LIMITED_INFORMATION 管理权限。 这种访问限制的位掩码是 0x1010。 这很有可能看上去很了解，由于它是 Mimikatz 所期待的访问限制之一。 Matt Graeber 提示过我，在试着检验根据受权浏览的异常浏览 LSASS 时，它是很多乱报的来源于。

透明度

此次攻击发布后，我花了一个星期六的時间建立了一个威协跟踪假定，我细心的科学研究了数据信息个人行为，并找到他们中间的关联。 在查询 Dwight 的 POC 时，我注意到编码中的 Win32 API 启用，从这种启用中，我相信我能将这种 API 启用与特殊的恶性事件关系起來。 由于像很多防御者一样，我对 EDR 商品以及日志纪录工作能力干了假定。

在沒有已经知道 API 到恶性事件 ID 投射的状况下，我逐渐自身投射这种启用。 我一开始投射的是 Sy *** on。 这必须反向Sy *** on 驱动软件将 API 启用投射到恶性事件申请注册体制的恶性事件 ID。 这儿要谢谢 Matt Graeber，谢谢他在这一每日任务中协助了我，而且花时间教我反向的全过程。 建立这一投射就是我完成检验对策的一个重要一部分，沒有它就不太可能完成最后的检验对策。

进程重镜像检验

检验方式

用以这一检验的方式以下：

· 阅读文章进程重镜像攻击的技术汇报。

· 查询Dwight 的 POC 编码。

· 得到有关攻击怎样实行的专业知识后，在数据信息和攻击个人行为中间创建关联。

· 实行攻击。

· 运用前边得到的科学研究专业知识并融合数据信息关联开展鲁棒性检验。

检验流程

当我们访问这一blog的 “Technical Deep Dive”一部分时，我忽然想起：

上面的图片中表明了好多个 API 启用，他们的应用巨大的激起了我的兴趣爱好。

· LoadLibrary

· CreateProcess

依据我还在 Sy *** on 驱动软件內部的反向科学研究，这两个 API 启用全是根据恶性事件申请注册体制布氏漏斗式开展的。 随后，Sy *** on 驱动软件应用必需的键入 / 輸出插口操纵(IOCTL)编码启用这类体制来查看数据信息。 随后将查看的数据信息拉返回Sy *** on 二进制文件中，后面一种将形成有关的恶性事件 ID。

针对所述2个 API 启用的有关全过程如下图所显示：

Sy *** on 恶性事件 ID 1的投射: 进程建立

Sy *** on 恶性事件 ID 7的投射: 镜像载入

依据此项科学研究和 McAffee 文章内容中的“技术揭密”一部分，我准确地了解实行此攻击时将形成哪些数据信息。 Sy *** on 对LoadLibrary 的每一个启用应当有一个 ID是 7的恶性事件，对 CreateProcess 的启用一样应当有一个 ID 是1的恶性事件; 可是，如何把数据交换为可实际操作的数据信息呢？ 尤其是威协跟踪工作人员能够非常容易地应用和控制以考虑她们必须的数据信息？ 因此，大家将关键放到归一化处理和网站安全性上。