对C2 Havoc的流量检测分析含检测脚本

免责声明：

本文所涉及的任何技术、信息或工具，仅供学习和参考之用。请勿利用本文提供的信息从事任何违法活动或不当行为。任何因使用本文所提供的信息或工具而导致的损失、后果或不良影响，均由使用者个人承担责任，与本文作者无关。作者不对任何因使用本文信息或工具而产生的损失或后果承担任何责任。使用本文所提供的信息或工具即视为同意本免责声明，并承诺遵守相关法律法规和道德规范。

简介

Havoc是开源的，使用简单，几乎没有以防御为重点的覆盖范围，这使它成为对手的热门选择。随着时间 的推移，它可能会变得更加流行，特别是像Cobalt Strike这样的其他工具已经有了广泛的防御覆盖范围。一些组织，如ZScaler、Critical Start和The Stack，已经分析了在野外积极使用的针对政府组织的哈弗恶 魔。

在2022年第四季度至2023年第一季度期间， Havoc的覆盖范围有所增加，因为它可以用来绕过最新版本 的Windows 11 Defender。此后，威胁行为者利用Havoc，利用第三方工具和插件绕过AV和EDR解决方 案，增强了他们在攻击中的灵活性。

在2023年第二季度至第四季度， Spamhaus发布了其僵尸网络威胁更新报告，显示在此期间， Havoc作 为后门的使用增加了22%。下图显示了整个2023年哈沃克使用量的总体变化。

2023年第二季度至第三季度，使用量下降了36%。这种下降可能归因于绕过Defender的新颖性减弱，因 为微软不断更新其安全措施，以保护用户免受新出现的威胁。到年底，哈沃克的使用量增加了22%。这 一趋势表明，随着对Havoc的不断更新和对其他C2框架的广泛研究， Havoc将不可避免地被威胁行为者 更多地使用。

该图是根据Spamhaus 2023年第2季度、第3季度和第4季度的威胁报告创建和提供的。

详情

为了捕获分析Havoc代理所需的所有流量和伪影，我们首先建立了一个专门用于检测工程的系列，具有高 保真日志收集和EDR功能。这是使用沉浸式实验室的Cyber Range模板进行部署的。您可以按照Havoc C2的文档并阅读本报告，手动部署自己的基础设施，从而获得相同的结果。

该系列具有以下基本组成部分：

• 用于部署代理的外部主机（扮演攻击者角色）
• 事件日志记录

○ Symon

○ 有弹力的

• 网络日志记录

• 完整数据包捕获

○ DNS日志记录

○ TLS机密

● EDR

○ 迅猛龙

• 重置/恢复

Figure 0-1

运行环境要求

运行Havoc所需要的只是一个公共IP地址上的Kali Linux实例。Ubuntu 20.04/22.04、基于Debian的发行 版、 Arch发行版和MacOS也可以工作，不过安装和设置Havoc的步骤会因您使用的发行版而异。Havoc 安装文档涵盖了这些差异。只需要一个公共IP地址上的单个AWS EC2 （或类似）实例，就可以轻松地打 开所需的TCP、 HTTP/s和DNS端口。

Havoc teamserver

Havoc C2框架分为两个组件：团队服务器和客户端。teamserver处理连接的攻击性操作员并管理侦听 器，以及回调解析和从demon（代理）下载屏幕截图和文件。客户端是操作员将看到的用户界面；操作 员可以指定代理任务并接收输出，例如命令输出或战利品。Loot是Havoc定义的一个术语，包括屏幕截 图和文件下载。

有关如何使用Havoc的更多详细信息，请参阅Havoc文档。

安装与配置

可以借鉴sjsjjs师傅的文章写的很细。

从teamserver和数据库获取加密密钥

确定获得加密密钥的可靠和可重复的方法。对一个havoc进行逆向工程并没有产生可操作的结果。需要一 种方法来确定密钥是什么，这样它们就可以用来解密和检查内存和网络流量，为此，采用了与Sliver C2 研究相同的技术。由于Havoc是开源的，确定了负责生成加密密钥的源代码，并在代码中添加了打印语 句。

Figure 0-1

在修改aes.go、重新编译teamserver并运行demon后，密钥被打印为标准输出。

Figure 0-2

既然知道了密钥是什么，就利用这些知识开发了一种从数据包捕获和内存转储中获取密钥的方法，发现 的另一种方法是使用SQLite从数据库中获取密钥。这包括从teamserver.db运行sqlite3，并运行下面的查 询，将AgentID替换为您的demon的代理ID。

Figure 0-3

下面的输出显示了Key和IV，但它们是Base64编码的。

Figure 0-4

解码后，我们得到了密钥。

Figure 0-5

这些密钥与之前显示的密钥不同，因为我们使用了两个不同的demons来测试这些方法。然而，使用上述 方法将始终打印密钥。

从数据包捕获中获取加密密钥

在获得密钥后，我们开发了一种方法来帮助防御操作员从数据包捕获和内存中获取密钥，详细信息如 下。

设置好所有内容后，我们在启用Wireshark数据包捕获的情况下，在目标机器上运行demons。这使我们 能够监控demon和teamserver之间的所有HTTP和TCP流量。

在分析捕获中的第一个数据包时，我们注意到第一个字节，这是一个神奇的字节值，如下图中的红框所 示。

Figure 0-1

在检查Havoc C2 GitHub存储库后，我们确定了在Define.h文件中找到的0xDEADBEEF魔术值的定义。

Figure 0-2

Havoc使用一种称为beaconing的标准轮询技术，即代理定期与teamserver进行检查。该间隔由C2操作 员设置为睡眠时间值。在分组捕获中识别C2通信可以通过识别该信标行为来表征。

对于Havoc，对服务器的请求包含来自任何命令的响应或对任何作业的请求。从服务器到客户端的响应包 含指示植入执行的下一个任务，例如，运行shell命令，进一步浏览数据包，我们看到POST请求和HTTP 状态代码200确认的连续通信这些都是持续不断的要求；它们的节奏由代理上设置的睡眠时间决定，代理 在内存中对自己进行加密以避免被检测到。

Figure 0-3

默认睡眠值为两秒，但攻击者很容易更改此值。为了避免EDR在内存中检测到， Havoc实现了一种睡眠技 术，该技术对内存中自己的有效载荷进行加密。这些睡眠技巧包括：

• Folage–创建一个新线程，使用NtApcQueueThread对面向返回的编程（ROP）链进行排队，加密 demon并延迟执行。
• Ekko–使用RtlCreateTimer对ROP链进行排队，该ROP链对内存中的恶魔进行加密，从而延迟其执 行。这种技术有一个GitHub存储库。
• WaitForSingleObjectEx–没有模糊处理，只是将执行延迟到设置睡眠的时间，默认为两秒。

通过查看捕获中的数据包，并使用Wireshark的过滤器功能，我们对十六进制进行了过滤，搜索之前从teamserver获得的加密密钥。我们还确定了代理ID，并根据teamserver中显示的ID进行关联。这种模式 与使用不同睡眠技术配置的不同代理的多次测试保持一致。

加密密钥似乎是在第一个非签入HTTP POST请求中从代理发送到teamserver的，如下图所示，以及魔术 字节头、代理长度和AgentID。

Figure 0-4

Figure 0-5

解密流量

为了识别流量的位置，我们必须识别长度比签入或共享密钥更大的数据包。我们确定了一个长度为3673 字节的POST数据包，这是迄今为止最大的数据包。在这一点上，我们只能猜测这是一个命令。我们需要 一种方法来验证这一假设。

Figure 0-1

我们通过复制值并将其带到CyberChef中来实现这一点，这样我们就可以尝试使用密钥对其进行解密，并 可能看到命令输出。对于CyberChef，我们需要加密方法（AES256）、密钥IV和模式，我们知道这是CTR，因为Havoc的GitHub存储库中的AESCrypt.h文件也表明了这一点。

Figure 0-2

将这些添加到CyberChef并解密没有得到任何结果，直到我们开始从输入开始一个接一个地删除字节，下 图显示了发送到teamserver的命令输出。

Figure 0-3

下图显示了基于CyberChef输出的输出起点的大致位置。

Figure 0-4

从这里开始的自然方向是尝试在pcap中发现命令；然而，这是不可能的，因为它们是通过信标对象文件 （ BOFS）发送的。发现攻击者使用的命令的唯一已知方法是捕获和解密输出，并从中推断，我们确定了 从标头字段发送的一些命令。然而，大量功能被实现为BOFS，并且都共享相同的command_id。这使得 在不分析BOF或响应的情况下很难理解正在执行的确切命令。我们发布了一个工具，可以在GitHub repos中找到，如果你有AES密钥，它可以提取并保存所有发送的BOFS及其响应。

从内存中获取加密密钥

我们通过使用sqlite3从teamserver.db获取密钥开始了这一过程，如前面“从teamserver和数据库获取加 密密钥”部分所述。我们还去了受害者的机器并丢弃了内存，然后，我们需要使用Volatility为我们的demon找到进程PID，称为chrome-updater.exe。我们使用下面的命令对内存转储文件执行此操作。

Figure 0-1

我们可以看到过程PID是5544。

Figure 0-2

有了进程PID，我们就可以转储chrome-updater.exe的进程内存。

Figure 0-3

  接下来，我们面对chrome-updater.exe进程的内存转储。我们在一个十六进制编辑器中打开它，开始寻 找密钥。我们想确定这些密钥是否存在于内存中，以及是否可以通过可扫描、 一致的结构进行识别。

  进行了多次测试，得到了相同的结果，如下图所示。

Figure 0-4

Figure 0-5

该结构在内存和数据包捕获方面完全相同，具体如下。

Figure 0-6

DE AD BE EF是Havoc的神奇签名，虽然它可以在源代码中进行修改，但它是默认值。接下来的四个字节 实际上是AgentID ，00 63是从客户端发送到团队服务器的DEMON INIT命令。

检测内存中的Havoc C2

通过建立一种可靠的方法来从数据包捕获和内存中获得加密和IV密钥，创建了一个YARA规则来专门检测 内存中的demon INIT请求。

Figure 0-1

我们还创建了一个用于检测内存中Havoc C2的Volatility插件，可以在我们的GitHub存储库中找到。下图 显示了预期输出的示例。此结构不会从内存中删除，因此可以追溯运行规则来识别Havoc代理操作。

Figure 0-2

我们还创建了一个Python脚本来解析来自数据包捕获的Havoc C2流量。使用要求在GitHub存储库中。

该脚本要求C2流量是通过HTTP发送的，或者您可以使用TLS MASTER机密之类的东西解密HTTPS流量的 TLS层。Heimdall范围旨在保存所有这些机密，以便进行pcap解密。

如果您没有加密密钥所在的第一个数据包，您可以从内存中获取密钥，如前所述，并使用它们来解密数 据包捕获流量。

以下是预期输出的示例：

Figure 0-3

利用SIEM检测Havoc C2

如果攻击者选择从teamserver发送shell命令，例如下面的命令，您可以在启用PacketBeat的Elastic中获 取它。

Figure 0-1

交流群

广告

原文始发于微信公众号（影域实验室）：对C2 Havoc的流量检测分析含检测脚本