欢迎来到 黑吧安全网 聚焦网络安全前沿资讯,精华内容,交流技术心得!

一文读懂进程重镜像技术(附检测方案)

来源:本站整理 作者:佚名 时间:2019-11-07 TAG: 我要投稿

大约三个月前,一种新的攻击技术出现在安全社区,名为「进程重镜像」。 这项技术是由 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 映射的情况下,我开始自己映射这些调用。 我一开始映射的是 Sysmon。 这需要逆向Sysmon 驱动程序将 API 调用映射到事件注册机制的事件 ID。 这里要感谢 Matt Graeber,感谢他在这个任务中帮助了我,并且花时间教我逆向的过程。 创建这个映射是我实现检测策略的一个关键部分,没有它就不可能实现最终的检测策略。
进程重镜像检测
检测方法
用于这一检测的方法如下:
· 阅读进程重镜像攻击的技术报告。
· 查看Dwight 的 POC 代码。
· 获得关于攻击如何执行的知识后,在数据和攻击行为之间建立关系。
· 执行攻击。
· 应用前面获得的研究知识并结合数据关系进行鲁棒性检测。
检测步骤
当我浏览这个博客的 “Technical Deep Dive”部分时,我突然想到:

https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/in-ntdll-i-trust-process-reimaging-and-endpoint-security-solution-bypass/
上面的图片中显示了几个 API 调用,它们的使用极大的激发了我的兴趣。
· LoadLibrary
· CreateProcess
根据我在 Sysmon 驱动程序内部的逆向研究,这两个 API 调用都是通过事件注册机制漏斗式进行的。 然后,Sysmon 驱动程序使用必要的输入 / 输出接口控制(IOCTL)代码调用这种机制来查询数据。 然后将查询的数据拉回到Sysmon 二进制文件中,后者将生成相关的事件 ID。
对于上述两个 API 调用的相关过程如下图所示:

 Sysmon 事件 ID 1的映射: 进程创建

Sysmon 事件 ID 7的映射: 镜像加载
根据这项研究和 McAffee 文章中的“技术揭秘”部分,我确切地知道执行此攻击时将生成什么数据。 Sysmon 对LoadLibrary 的每个调用应该有一个 ID是 7的事件,对 CreateProcess 的调用同样应该有一个 ID 是1的事件; 但是,如何将数据转换为可操作的数据呢? 特别是威胁追踪人员可以很容易地使用和操纵以满足他们需要的数据? 为此,我们将重点放在数据标准化和数据质量上。

[1] [2]  下一页

【声明】:黑吧安全网(http://www.myhack58.com)登载此文出于传递更多信息之目的,并不代表本站赞同其观点和对其真实性负责,仅适于网络安全技术爱好者学习研究使用,学习中请遵循国家相关法律法规。如有问题请联系我们,联系邮箱admin@myhack58.com,我们会在最短的时间内进行处理。
  • 最新更新
    • 相关阅读
      • 本类热门
        • 最近下载