使用了非标准扩展: 不支持在此结构上使用“__asm”关键字_[翻译]CobaltStrike 使用Beacon Object Files(BOF)进行 Direct Syscalls...

原文链接:https://outflank.nl/blog/2020/12/26/direct-syscalls-in-beacon-object-files/ 原文作者:Cornelis de Plaa

在这篇文章中，我们将探讨在Cobalt Strike使用BOF进行直接系统调用(direct system calls)。具体来说：

1.说明如何在Cobalt Strike BOF中使用直接系统调用来规避典型的AV和EDR检测。2.发布InlineWhispers：一个脚本，使在BOF代码中使用Direct Syscalls更加容易。3.提供概念验证BOF代码，该代码可用于通过修补LSASS进程内存来启用WDigest凭据缓存和规避凭据保护。

PoC的源代码可以在这里找到：https://github.com/outflanknl/WdToggle

InlineWhispers的源代码可以在这里找到：https://github.com/outflanknl/InlineWhispers

Beacon Object Files

Cobalt Strike最近引入了一个新的代码执行概念，叫做 Beacon Object Files^[1](以下简称为BOF)。这使Cobalt Strike可以在Beacon进程中执行一小段已编译的C代码。

这有什么好处？最重要的是，我们摆脱了名为fork＆run的概念。在BOF出来之前，fork＆run是在Cobalt Strike中运行作业的默认机制。这意味着为了执行大多数开发后功能，将启动一个牺牲进程(使用spawnto参数指定)，随后将攻击的payload作为反射DLL注入该过程。从AV、EDR的角度来看，它具有可以检测到的各种特征，例如进程产生，进程注入和内存中的反射DLL。在许多现代环境中，fork＆run很容易演变成OPSEC(行动安全Operations security)的灾难。使用BOF，我们可以在Beacon当前过程的上下文中运行与位置无关的已编译代码，这更加隐蔽。

尽管BOF概念的引入对于在后渗透开发中绕过AV、EDR迈出了重大一步，但我们仍然需要面对AV、EDR产品HOOK系统API的问题。在2019年6月，我们发布了有关Direct Syscalls的博客文章^[2]，并展示了一个如何使用它绕过AV、EDR软件的示例。到目前为止，我们还没有看到Direct Syscalls在BOF的利用࿰