ATT&CK 技术项编号为 T1036 的二进制重命名技术,正在被越来越多的恶意软件所采用,本文介绍如何使用多种方法对该技术进行监控与检测。
二进制重命名是一种逃避检测的技术,用于绕过基于进程名与路径的检测方案。二进制重命名是 MITRE ATT&CK 框架中 T1036 Masquerading 技术的子类。在攻击生命周期的各个阶段都可以观察到这项技术的应用,无论是商业恶意软件开发者还是 APT 都有广泛的使用。二进制重命名最有名的应用就是 NotPetya,NotPetya 重命名了 psexec 程序实现自动化、破坏性的横向感染。
通过检查已执行进程的二进制程序属性、对比预期外进程的名称与路径的方式可以发现这种威胁。这是在对抗基于 JavaScript 的垃圾软件时总结的方法,它们利用渗透工具、横向平移与 APT 级的检测逃避。
对于在攻击生命周期早期发生的攻击,通常涉及到寻找立足点,想要将受监控的二进制程序拷贝到不显眼的路径中。对于交互式攻击或攻击生命周期后期,攻击者往往需要利用自己的黑客工具或者管理工具,而非本地环境中的程序,这些工具仅仅是看似“合法的”。要了解所使用的二进制程序的类型,例如 PE 文件的属性可以和很多检测的锚点相关,便于后续搜索。
考虑到并不是所有团队都有功能强大的 EDR 能力,可以实现大规模的二进制程序属性的可见性。据此,我想创造一个开源的解决方案解决这个问题。
在没有完善的日志记录 / EDR 的情况下,WMI 事件可以为我们提供可见性。WMI 事件订阅是通过触发器和(EventFilter)和处理器(EventConsumer)处理某些系统事件的方法。WMI 事件几乎可以对所有操作系统事件进行操作,例如:登录事件、进程活动、注册表或者文件更改情况。
WMI 提供的能力可以认为是 EDR 用户空间事件跟踪的有限子集,但又无需安装服务或者程序。WMI 事件并不是新鲜事物,早在 2016 年 Fireeye 就讨论了 WMI 作为端点入侵检测系统的可行性。此前我已经构建了基于 WMI 事件的解决方案用于应急响应事件当中,弥补可见性的差距。WMI 与 WMI 事件的完整描述超出了本文所讨论的范围,若要详细了解更多的知识可以查看扩展阅读。
ActiveScript 事件处理器可以通过功能强大的 Windows Scripting Host 为 WMI 事件触发器添加、丰富事件处理逻辑。在此示例中,利用实时“外部” WMI 事件触发器进行进程执行监控,从所有执行的进程中收集进程 ID。Win32_Process 的查询可以进一步提供有关进程的元数据,收集 PE 属性便于检测。此示例中使用的 PE 属性是原始名称,查询高优先级原始名称列表并检测报警。
在条件匹配时,示例程序支持写入应用程序事件日志。事件 ID 为 4,包含相关告警的详细信息。出于性能考虑,进程路径和原始名称都实时记录在告警中,并没有进行哈希计算。
类似的也可以输出到日志中。值得注意的是,可以方便地修改示例程序中关于写入日志文件、事件记录函数与函数调用的部分。
使用WMI事件作为事件来源的一个局限是通常不能得到成熟的检测用例需要的所有数据。为了丰富数据,需要查询Win32_Process类。获取进程元数据会存在一些延迟,因此非常短暂的进程(几分之一秒)可能会存在获取不到的情况。在我自己的测试中,非常短暂的命令(如重命名命令 cdm /c echo <string>
)无法生成WMI数据,在本地ping事件记录中稍有延迟。对于下载、访问 Shell、或者其他常见的交互式命令没有见到问题,但请记住这个局限。
第二个局限是性能,虽然我自己构建的测试中没有资源密集的用例,但生产中可能存在其他限制。我过滤了进程事件,但希望你在部署的时候进行针对性的测试。考虑到性能,程序属性匹配用例尽可能地保持简单,这意味着准确度的降低。但是由于逻辑尽可能的简单,修改、添加功能是很容易的。
另外,在某些环境中,某些目标的原始名称可能存在合法的二进制重命名行为。列出的程序列表可能需要对匹配逻辑进行一些调整来兼容不同的主机环境。
最后,众所周知,WMI事件处理器是难以管理的。我提供了一个带有卸载说明的 Powershell 安装脚本,支持 Powershell 2.0 及以上。
这是一个有趣的开源项目,当我发现vbscript具有查询PE属性的功能时,希望其他人也可以更好地利用这个功能。
示例程序的模板可以在这里找到 WMIEvent-BinaryRename.ps1。
Yara 是一个主要用于恶意软件检测的模式匹配工具。基于字符串或者二进制模式的规则,利用布尔、计数或者正则表达式之类的匹配逻辑。虽然传统上仍然是基于模式的匹配,但是 Yara 是模块化、可扩展的。例如 PE 模块可用于查询常见的二进制程序属性,PE 模块可以支持创建针对 PE 文件格式和文件头的规则,提供了为 PE 文件编写更有效规则的函数。如正在使用的 pe.versioninfo
的 InternalName 属性:
我们的 Yara 规则很有趣,因为我们需要将预期的文件名与实际的文件名进行比较,但比较文件名并不是 Yara 设计的本意。Florian Roth 在 2014 年写了一篇关于“inverse”技术的文章,文中阐述了如何利用 Powershell 脚本获得所有需要扫描的文件,并将每个文件名作为外部变量传递给 Yara 进行扫描。为每个文件都创建一个新的 Yara 实例,传入相关的文件名以进行比较。在下面的代码中,扩展了该用例代码支持 32 位与 64 位机器。
为了保证正确执行,执行路径下必须存在下列文件:
inverseYara.ps1
x86 或 x64 的 Yara 程序
rename.yar
通过 bat 脚本或命令执行如下:
从检测的角度看,这种技术非常有效,但在我的测试中,由于为每个文件都要生成新的 Yara 进程,性能开销导致效率并不理想。值得注意的是,Yara 扫描可以针对没有文件名匹配时聚焦于域内文件的意外位置,但这并不符合二进制重命名的需要。
这种情况下,首选的方式变成了 Powershell。Windows API 通过 FileVersionInfo 类提供了对 PE 属性的访问,并且支持 Powershell 2.0 /.NET 2。输出那些可以辅助分析的额外选项可以显著提升速度并优化逻辑。在下面的脚本输出中,可以看到输出中已经添加了 SHA1 哈希。
任何静态检测能力的最大局限就是请求整块磁盘的性能。利用 Powershell 与本地 Windows API 可以显著优化性能,其他优化措施是将 CPU 优先级设置为仅空闲,并仔细设计逻辑有效过滤,以最小化占用资源。作为目标检测的一部分,围绕性能的其他优化也可以是针对特定感兴趣的位置的查询。
要记住使用 Powershell 方法利用 Windows API。尽管不在磁盘中的二进制重命名并不是一个很大的问题,但如果像 Rookit 一样,则首选 Raw Collection。
希望这篇文章能够对你有所帮助,如果你有任何反馈、问题与改进措施,请随时与我们进行联系。Yara 检测与 Powershell 检测的代码可以在 Get-BinaryRename 找到。
*参考来源:Mgreen27-BinaryRename-1 与Mgreen27-BinaryRename-2,FB 小编 Avenger 编译,转载请注明来自 FreeBuf.COM