修改Metasploit x64模板实现反病毒规避

Joff Thyer //
提示： 本博文中引用的技术和工具可能已过时，不适用于当前情况。然而，这篇博文仍可作为学习机会，并可能更新或集成到现代工具和技术中。

在对拥有Windows桌面的组织进行渗透测试时，许多测试人员现在会使用Veil的Powershell Empire等工具直接将shellcode注入内存。毫无疑问，这是一种绝妙的技术，因为它避免了写入磁盘并直接撞上大多数端点保护解决方案的直接检测。

xkcd: 恶意软件水族馆 通常情况下，我们希望通过使用实际的恶意软件可执行文件，并在测试期间尝试不同的命令和控制技术来进行更彻底的测试。我们希望改变技术，以找出防御技术的截断阈值设置在哪里，并能够全面报告哪些技术在系统上有效，哪些无效。在大多数环境中，最常部署的端点保护技术是反病毒引擎。

反病毒在检测Metasploit框架中的现成32位恶意软件可执行文件方面变得非常有效，但在64位领域往往不足。此外，我们发现网络驻留防御对Metasploit的32位第二阶段载荷调整得很好，但对64位第二阶段载荷的检测能力较差。根据我的经验，反病毒引擎不仅查看shellcode，还会匹配构成由msfvenom命令生成的Metasploit可执行文件的存根加载器的汇编代码。

当生成Metasploit载荷时，它们在32位和64位情况下都使用标准模板可执行文件。标准模板是框架数据目录中的预编译可执行文件。除了模板之外，Metasploit项目还在框架中提供了源代码目录。

特别关注Windows，我们可以在KALI发行版的“/usr/share/metasploit-framework/data/templates/src/pe/exe”目录中找到32位模板的C源代码和64位模板的汇编源代码。

在32位和64位情况下，模板源具有非常相似的功能。它在内存中分配一个4096字节的缓冲区，并将字符串“PAYLOAD:”放在此缓冲区的开头。字符串“PAYLOAD:”作为常量放入缓冲区，指示“msfvenom”在创建新载荷可执行文件时使用的起始位置。

该起始位置是内存中的一个地址，msfvenom知道可以用于将shellcode复制到其中。可用于shellcode的缓冲区大小是模板EXE中分配的缓冲区大小减去八（字符串“PAYLOAD:”的长度）。Msfvenom将获取所选载荷，使用适当的编码器（如果指定）进行编码，并在选择时预置无操作（NOP）滑板字节。

32位情况下的最终可执行文件是从C源代码编译的。在C源代码中，通过将载荷缓冲区转换为指向函数（没有函数参数）的指针来调用shellcode。

64位情况下的最终可执行文件是从汇编代码编译的。汇编代码函数分配一个可执行的内存缓冲区，将shellcode复制到该内存中，并使用CALL指令执行它。这是许多不同工具使用的非常相似的技术，包括我们都在使用的强大Powershell工具。

32位EXE模板的源代码

64位EXE模板的汇编源代码

有了这些知识，我决定看看一个单一的反病毒引擎（Avast）在我仅仅获取64位可执行模板并将其复制到Windows系统时的反应。注意，我甚至没有在EXE中放入任何shellcode载荷，只取了模板本身。

Avast立即触发警报并不令人惊讶。让我们面对现实，匹配模板的汇编操作码是一种非常容易触发警报的方式，而无需实际检查shellcode载荷。

Avast告诉我这很糟糕！

专注于64位情况，我绝对没有理由不能重新编译此汇编代码并尽可能多地修改它。我们只需要确保在某个时刻，它调用两个必需的代码位，将载荷复制到我们分配的可执行内存段中，然后执行它。

案例1： 为了我的第一层乐趣，我简单地重新编译了相同的源汇编代码。不出所料，Avast标记了这一点。

案例2： 我将缓冲区长度更改为8192字节，并重新编译。除了缓冲区长度之外，没有更改任何内容。Avast完全未能通过此测试，没有标记任何警报。我怎么知道？嗯，我在运行Avast的系统上编译了它。注意，编译汇编代码的指令在源代码的命令中有帮助地列出。

x64汇编列表的最后部分

案例3： 我将汇编代码中的所有值修改为8192，然后使用新生成的可执行模板创建了两个不同的载荷。其中一个载荷在shellcode上使用了64位XOR编码，而另一个根本没有使用编码。

然后，我将载荷文件复制到运行Avast的Windows 7机器上。我强制Avast扫描它们，它们顺利通过！然后我执行了它们，shell就是我的了。

在案例3中，我对Avast的深度扫描特别感到好笑，它似乎表明它正在非常努力地查看发生了什么！但然后，它告诉我一切正常，恶意软件被愉快地执行了。

具有8192缓冲区长度的新汇编源代码列表。

使用新模板且无编码的64位载荷。

使用新模板和XOR编码的64位载荷。

Windows系统目录中的新载荷！

继续扫描我的目录…

我很安全，真是松了一口气！

哦不，我可能会在这里被抓住！ 噗…

现在是shell时间。

结论： 我的理论和实践经验是，反病毒供应商正在查看模板而不是shellcode本身。在这个具体实例中，我们仅通过微小的汇编代码修改和绝对无编码的64位shellcode载荷立即取得了成功。

为什么选择Avast？没有具体原因，只是我需要一个快速的解决方案来执行我的测试。我将用其他反病毒引擎重复实验，看看我的效果如何。这种技术有许多可能的变化，但就像生活中的许多事情一样，最好从简单开始，并根据需要逐步增加。狩猎愉快！

您可以直接从Joff本人那里了解更多信息，通过他的课程：

• 正则表达式，您的新生活方式
• 企业攻击者模拟和C2植入开发
• Python简介 提供现场/虚拟和点播形式！

服务检测 – Tomcat Manager，从“信息”到“哎呀”密码喷洒及其他RPCCLIENT的乐趣