杀软EDR逃避——VBA清除技术深解析

2024-10-19 1 0

一、前言

现在的互联网威胁环境中,APT攻击不断更新工具和技术,更多APT攻击都在试图绕过安全防护系统,执行恶意操作。其中,VBA(Visual Basic for Applications)宏脚本作为一种常见的攻击载体,已被众多APT组织和攻击者利用来传播恶意软件。这项技术是在2019年的时候被捕获,因为国外各大安全公司对样本进行分析,明确的表示该技术确实是存在逃避性,随后该技术被公开,OfficePurge工具也在Github上公开。并且对于现在的杀软件和EDR(端点检测与响应)工具的不断升级更新换代,而且YARA方式捕获也在不停更新,攻击者开始采用更先进的技术来逃避检测。本文将深入探讨其中一种的逃避技术,在我个人想法当然在现今并不是说很高效的一种技术方式,并且这种攻击方式比较适合欧洲、南美、北美这些地区,好了,好了,不叨叨了那么进入正题 ——VBA清除(VBA Purging)

二、什么是VBA清除(VBA Purging)?

VBA Purging是一种特定的混淆技术,旨在绕过用于检测恶意软件的分析机制。通常,当将VBA宏嵌入到Microsoft Office文档时,VBA代码会存储在两个主要部分中:

  1. PerformanceCache:这是编译的VBA代码部分,包含预编译的字节码,用于加速宏的执行。
  2. CompressedSourceCode:这是压缩后的VBA源代码部分,存储着未编译的VBA宏源代码。

在VBA Purging过程中,攻击者会通过修改文档结构,完全删除PerformanceCache(编译的代码)以及相关的流,如_SRP_流。这些流通常包含与编译代码相关的版本信息和数据。此外,攻击者还会将MODULEOFFSET设置为0,表示该模块没有编译代码。这一操作告诉解析器,文档中的VBA宏没有编译的版本,从而引发检测工具的误判。

通过移除PerformanceCache及其相关的组件,VBA Purging可以有效地阻止静态分析工具(如防病毒程序和YARA规则)检测通常存在于编译VBA宏中的恶意或可疑字符串。虽然文档中的CompressedSourceCode(压缩的VBA源代码)仍然保留,但许多依赖编译代码进行分析的检测工具将无法检测到其中的恶意内容。

这种技术对攻击者非常有利,因为它显著降低了文档在环境中的检测率。例如,在VirusTotal等多引擎检测环境中,经过VBA清除的文档比未清除版本的检测率低得多。即使VBA宏中的恶意代码仍然存在并可执行,杀软几乎是可以过的。

这种技术展现了攻击者在对抗防御和逃避杀软时的灵活性等,特别是在利用Office文档作为载体传播恶意软件时。通过清除关键的编译信息,攻击者能够有效规避传统的安全防护策略,并且在受害者不知不自觉情况中进行恶意操作盗取等行为。

1、清除技术中的三项

  • 删除PerformanceCache(编译的VBA代码)
    攻击者在VBA清除过程中,通过删除VBA宏中存储的PerformanceCache,即编译后的VBA字节码。这部分代码原本用于加速宏的执行,但在清除后,它会被从文档中移除,使得安全工具无法解析其中的恶意代码。

  • 删除_SRP_流
    与PerformanceCache一起,攻击者还会删除与编译代码相关的_SRP_流。这些流包含关于VBA代码的版本信息和其他元数据,通过清除这些流,文档中与编译代码相关的所有信息都会被移除。

  • 设置MODULEOFFSET为0
    这一操作将MODULEOFFSET(模块偏移量)设置为0,意味着该模块中没有编译的代码。这一操作会误导安全工具,告诉它们没有预编译的VBA代码存在,从而绕过检测。

看完上面的内容你的思维也是这样的一个结果,VBA清除是一种修改或移除Office文档中VBA项目流(VBA Project Stream)的方法。这一过程主要是通过清除或损坏包含VBA宏代码的结构信息,导致防病毒软件或EDR无法正确解析或检测其中的恶意代码。

三、VBA清除技术示例

在实际样本中,VBA Purging 的技术可以通过简单的工具实现,这章节我将通过一个示例展示如何利用 VBA Purging 来移除编译代码,并逃避安全工具的检测。为了演示,我们将使用oledump.py工具来分析一个经过 VBA 清除的文档,并验证 PerformanceCache 数据是否已经被清除。

1、示例分析

首先,我们使用oledump.py工具结合选项-i对目标文档进行分析。该工具可以显示文档中的 OLE 流以及宏的结构信息。运行命令后,输出结果如下:

杀软EDR逃避——VBA清除技术深解析插图

这里可以看到一共有7个A顺序项,分别A-A6,在工具帮助下VBA 项目结构和各个流的信息,都可以进行查看,这里废话一下,对每个项简单讲讲,后面整个VBA清除技术都比较清晰一些。我们先看A项:

A: xl/vbaProject.bin   #表示在 Excel 文件的 VBA 项目流所在的路径。这个路径是 Excel 宏嵌入文档时默认存储 VBA 项目的位置。

A1项:

A1:       478             'PROJECT'   #'PROJECT'是描述 VBA 项目的一部分,包含VBA项目的基本元数据,比如项目名称、版本等。

A2项:

A2:        65             'PROJECTwm'  #A2流为 65 字节,名为 'PROJECTwm'。这通常包含与 VBA 项目窗口信息相关的内容,例如用户界面配置等。

A3项:

A3: m     170       0+170 'VBA/Sheet 1'   #A3是一个包含 VBA 宏代码的流。m表示这个流包含编译的VBA代码,但数据量较小,大小为 170 字节,其中 0+170代表 编译字节码的大小为0,源代码的大小为170 字节'VBA/Sheet 1'是与工作表 1 相关的 VBA 代码。

A4项:

A4: M    2359      0+2359 'VBA/ThisWorkbook'  #A4是另一个包含 VBA 宏代码的流。M表示这部分是带有宏的模块。2359 字节的数据,其中 0+2359表示 编译的字节码为 0,源代码为 2359 字节

'VBA/ThisWorkbook'是工作簿对象(ThisWorkbook)的 VBA 代码。这表示了ThisWorkbook对象中含有宏,但编译后的代码已被清除,只剩下源代码。

A5-A6项:

A5:         7             'VBA/_VBA_PROJECT'  #A5流的大小仅为 7 字节,名为 'VBA/_VBA_PROJECT',这是与 VBA 项目本身相关的配置或其他信息,可能与项目属性或结构的低级别信息有关。

A6:       216             'VBA/dir'  #A6216 字节大小的流,名为 'VBA/dir'。这个流通常包含项目的目录结构信息,包括模块的引用、模块名称、模块属性等。

从上面的输出分析结论:

A3A4这两个流中的 VBA 宏(分别关联到 Sheet 1ThisWorkbook)已经进行了VBA清除(VBA Purging)操作。这体现在两个模块的 编译代码大小为 0(0+1700+2359),但仍然保留了源代码(分别为 170 和 2359 字节)。这表明编译字节码已经被清除,攻击者可能试图通过此操作来规避静态分析工具的检测。

四、VBA清除和未清除的对比分析

杀软EDR逃避——VBA清除技术深解析插图1

图1-VBA清除样本

杀软EDR逃避——VBA清除技术深解析插图2

图2-未清除样本

图1-这里的 0+548表示 编译字节码大小为0,而源代码为 548 字节。这意味着文档的 VBA 宏已被清除,只剩下未编译的源代码,编译后的字节码已不存在。这种操作可以规避许多基于静态分析的安全工具的检测。

图2-这里的 1299+81表示这个 VBA 宏同时包含 1299 字节的编译字节码81 字节的源代码。这意味着该文档中的 VBA 代码尚未进行清除操作,包含完整的编译后代码和源代码。

对比总结

  • 清除文档(图1)只保留了源代码,编译字节码被完全移除,因此可以逃避大部分防病毒和静态分析工具的检测。这是攻击者经常使用的一种手段,称为 VBA Purging,其目的是降低恶意文档在安全工具中的检测率。
  • 未清除文档(图2)仍然保留着完整的编译字节码和源代码。这使得许多基于静态分析的工具能够对编译后的内容进行扫描和检测,从而更容易发现其中的恶意代码。

通过清除 VBA 的编译部分,攻击者能够有效地隐匿恶意代码,并使文档在 VirusTotal 等多引擎检测环境中的检测率大幅降低。这种技术对攻击者具有较高的实用性,特别是在绕过传统防护手段的场景中。

五、结束语

通过上面的全部内容基本可以了解VBA清除(VBA Purging通过移除编译后的 VBA 宏字节码,攻击者可以大幅降低恶意文档的检测率,使传统的防病毒软件和静态分析工具难以察觉其中的威胁。这种技术揭示了基于文件宏的攻击仍然是网络攻击中的一个安全隐患,毕竟现在国内的Office办公软件会自检文档是否存在宏这类的,所以大概内容就是这么多,拜拜。

六、YARA

rule FEYE_OLE_VBAPurged_2 {
    meta:
        author = "Michael Bailey (@mykill), Jonell Baltazar, Alyssa Rahman (@ramen0x3f), Joseph Reyes"
        description = "This file has a suspicious _VBA_PROJECT header and a small _VBA_PROJECT stream. This may be evidence of the VBA purging tool OfficePurge or a tool-generated document."
    strings:
        $vba_proj = { 5F 00 56 00 42 00 41 00 5F 00 50 00 52 00 4F 00 4A 00 45 00 43 00 54 00 00 00 00 00 00 00 00 00 }
        $cc61 = {CC 61 FF FF 00 00 00}
    condition:
        uint32(0) == 0xe011cfd0 and ( uint32(@vba_proj[1] + 0x78) >= 0x07 ) and ( uint32(@vba_proj[1] + 0x78) < 0xff ) and $cc61
}

4A评测 - 免责申明

本站提供的一切软件、教程和内容信息仅限用于学习和研究目的。

不得将上述内容用于商业或者非法用途,否则一切后果请用户自负。

本站信息来自网络,版权争议与本站无关。您必须在下载后的24个小时之内,从您的电脑或手机中彻底删除上述内容。

如果您喜欢该程序,请支持正版,购买注册,得到更好的正版服务。如有侵权请邮件与我们联系处理。敬请谅解!

程序来源网络,不确保不包含木马病毒等危险内容,请在确保安全的情况下或使用虚拟机使用。

侵权违规投诉邮箱:4ablog168#gmail.com(#换成@)

相关文章

[Meachines] [Easy] Sightless SQLPad-RCE+shadow哈希破译…
一文了解软件分析代码审计
K8S攻击面与检测规则实现
暴露内核内存并通过滥用COW机制实现一个注射器
403bypass问题简析
0day的产生 | 不懂代码的”代码审计”

发布评论