背景

侦测和识别敌方指挥与控制(C2)通道的能力一直是强大防御能力的最重要因素之一。 攻击者的 C2机 制的检测不仅允许威胁狩猎者以 C2 特征和行为为中心来寻找其他被入侵的端点，而且还揭示了许多关于攻击者的能力和复杂性的信息。 从斩杀链的 C2阶段提取的威胁指标(IOC)也可以通过威胁反馈和威胁情报伙伴关系共享，以深入了解攻击者的目标、动机，并更好地了解对手活动的规模。

考虑到这一因素在斩杀链中的重要性，蓝队花费了大量精力开发防御技术来检测 C2通信。 这种努力的增加意味着使用传统 C2通道的对手很可能在现代和成熟的企业环境中会被发现，在这些环境中，特定的努力已经被用于防御性安全方面。

一个典型的蓝队将依靠来自网络代理或某种形式的网络传感器设备的数据，使他们能够查询“唾手可得”的C2特征 ，例如: 最近看到或最近注册的域名、不寻常的用户代理、一般信标行为，以及信誉分数低或未知的域名。 更先进的组织也将有能力将异常网络活动链接回单个端点进程，而不是整个端点。 这为 C2检测带来了一个全新的能力水平，因为防御者现在能够将上面列出的 C2特征与其他可疑指标结合起来，例如: 正在进行定期网络连接的未签名应用程序、进程注入事件之后的网络连接以及每个进程的异常网络活动。

这些防御技术的发展迫使更有能力的对手使用神秘的 C2通道来避免被发现。 近年来，我们看到一些著名的高级持续性渗透攻击组织使用流行的网络服务，如 Instagram [1]、 Photobucket [2]和 Google Drive [3]作为他们的 C2通信机制，这是因为他们有良好的域名声誉，并且在目标网络上很常见。

这些更先进的 C2通道的实现意味着运行对手仿真的红队也必须采用复杂的 C2机制来避免蓝队检测，并提供 APT 或接近相同 APT 能力的真实模拟。 这主要是在每个红队的基础上通过自定义内部工具实现的，几乎没有开源框架来满足红队威胁仿真的秘密 C2通道的需求。

C3 介绍

为了满足这个要求，MWR 实验室最近发布了他们的 C3(自定义指挥和控制-Custom Command and Control)框架，允许红队快速开发和使用 C2通道。 正如 C3[4]发布时的博客文章中所描述的，C3是一个扩展其他红队工具的框架，比如 COTS Cobalt Strike 产品，允许红队通过 Slack、 OneDrive、 WhatsApp 等流行的合法应用打通他们的 C2流量。

从威胁狩猎的角度来看，C3的发布对有效的威胁检测提出了一个有趣的挑战。 该框架的发布降低了主流攻击者利用流行应用程序的合法功能来掩盖受损端点和 C2服务器之间的通信的门槛。 由于这一点，很可能组织将开始看到越来越多的攻击者正在使用他们隐秘的 C2 通道，比如 C3 框架中提供的通道。

为了防御使用新技术和先进技术的攻击者，Countercept 的威胁狩猎小组分析了大量端点机器数据，以便快速检测整个斩杀链上的威胁。 这些数据提供的覆盖范围意味着，当攻击者在斩杀链的一个元素(例如命令和控制阶段)使用新技术时，我们通常能够在其他元素检测到它们，然后从这些信息中枢转到分析攻击路径的其余部分。 对于先进的 C2通道——比如 C3框架提供的通道——我们更有可能在斩杀链的交付、开发、安装和操作阶段检测敌手。 

然而，有必要为以下情况做好准备: 我们要么无法访问这些数据(例如当客户在攻击者已经入侵网络后联系我们启动事件响应(IR)调查) ，要么攻击者正在使用复杂的工具、技术和程序(TTP) ，允许他们在不被发现的情况下进行斩杀链的初始步骤。 基于这个原因，我们决定研究如何能够在不依赖于斩杀链其余部分的历史数据的情况下检测到 C3的使用。

设置场景

挑战声明

一个系统被入侵，攻击者利用 C3 来伪装 C2 通信。 攻击者也可能决定将恶意代码注入端点上的一个合法进程，然后使用一个秘密的 C2 通道，该通道与注入进程的典型网络行为相匹配。

本文档的检测部分分为两部分: 注入和非注入。 非注入部分涉及到一个场景，攻击者在端点上执行了 C3有效载荷，并使用 C3模块来伪装 C2通信。 在这个示例中，没有进行内存注入。 第二部分稍微复杂一些，在攻击者利用一个端点，然后将恶意代码注入一个合法进程的情况下进行工作。 然后，攻击者开始使用一个秘密的 C2通道——比如 C3提供的通道——这与他们注入的进程相匹配。

对于本文档的注入部分和非注入部分，我们将处理攻击者使用 Slack C2通道的场景，这意味着所有 C2通信都应该伪装成 Slack 应用程序通信(由“Slack” C3模块提供)。 虽然我们在本文中只关注一个模块，但是大多数所讨论的检测技术的基本原理应该可以扩展到 C3 提供的其他 C2 通道。

检测-非注入

未签名的二进制文件

蓝队可以使用 Sysmon 和 Windows (ETW)的事件跟踪(Event Tracing)提供程序来记录和检查由进程创建的 DNS 请求。 这是一个非常丰富的威胁狩猎数据源，因为它允许防御者将网络活动链接回一个在端点上运行的特定进程，从而能够在不同的数据源之间转换。

使用这个数据集，我们可以通过查询任何正在向“slack.com”域名或相关子域名发出DNS请求的未签署的可执行文件来寻求快速的胜利。 在一个典型的环境中，我们只能期望看到有签名的可执行程序(如 chrome、 slack、 svchost 和 AV 软件)创建了连接到 slack.com 等流行域名的 DNS 连接。

DNS 查询异常

我们还可以将合法的slack可执行文件发出的DNS请求与使用C3 slack模块的植入物发出的请求进行比较。 比较结果发现了一些有趣的差异。 从下面的图片可以看出，C3 slack 模块大量使用“slack.com” DNS 查询，除了偶尔使用“files.slack.com”查询之外，几乎没有什么变化。“ files.slack.com”是攻击者试图从受损端点上传大量数据时使用的查询。

当我们将这些数据与合法的 Slack 可执行程序发出的 DNS 请求进行比较时，我们可以看到查询的变化有明显的不同。 我们观察到，合法的 Slack 可执行程序通常会对19个不同的域名发出 DNS 请求：

值得注意的是，这个列表被精简到只包括 Slack 拥有的域名。完整的 DNS 查询列表包括域名，如 bugsnack.com， fonts.gstatic.com 和各种 giphy.com 子域名，这些 DNS 查询的存在和频率显然取决于用户在 Slack 上的活动和所使用的插件类型。

从检测的角度来看，合法的 Slack 可执行文件和 C3 Slack 模块使用的 DNS 查询的差异提供了一种潜在的检测方法。 这是一个相对直接的过程，监控由可执行文件查询“*.slack.com”所进行的DNS查询，然后查看所查询的DNS名称是否符合合法的slack可执行文件的DNS配置文件。

检测-注入

当我们考虑到攻击者可能试图将恶意代码注入进程，然后利用与源进程的典型网络行为相匹配的 C2 通道时，检测秘密的 C2通道就变得更有趣了。 为了这项研究的目的，我们使用了这样的场景: 攻击者首先将他们的恶意代码注入到一个合法的 Slack 进程中，然后使用类似于 C3 Slack 模块的 C2通道从该进程中发出信号。 在这种情况下——从高层次的角度来看——我们最初只会看到一个 Slack 进程与合法的 Slack 域名进行对话，这显然是预期的行为，而不是一个会让蓝队感到可疑的事件。

然而，通过注入 Slack 进程，攻击者无疑会改变该进程的行为。 我们可以尝试识别这些变化，以便检测攻击者正在使用的隐秘的 C3 通信功能。

追踪网络连接

使用 ETW 提供程序，我们还可以跟踪网络连接到创建连接的进程中的模块。 通过将合法的 Slack 进程创建的网络连接与攻击者注入的 Slack 进程创建的连接进行比较，我们可以看到一些有趣的区别。

如果我们查看一下30天期间内正常的 Slack 部署的网络连接，我们可以看到连接源自主要的可执行程序(slack.exe) ：

相比之下，如果我们看一个这样的例子，攻击者已经注入到 Slack 可执行文件中，并使用它向外发出信号到 C2 服务器，我们可以看到这些连接来自 ntdll.dll 模块，而不是核心 Slack 可执行文件:

为了确认这个Slack进程正在被攻击者使用，我们可以在 ntdll.dll 模块的第一个实例创建 Slack 进程的网络连接之前查找线程注入事件。 正如我们在下面的图片中看到的，我们的怀疑得到了证实，因为在一个线程注入事件之后立即发生了一系列源自 ntdll.dll 模块的网络连接:

数据包总数异常

需要记住的一个关键点是，无论攻击者注入了什么进程，它们几乎总是会导致该进程以不同的方式运行。 根据这些知识，我们可以研究当攻击者从注入的进程发出信标时可能发生的其他基于网络通信的变化。

上面的散点图显示了一个12小时的时间段，涵盖了一家中型公司的正常工作日，Slack 用于日常业务沟通。 Y 轴显示 Slack 可执行文件每五分钟传输的数据包数量。 对于网络上的绝大多数主机，我们可以看到 Slack 可执行文件每五分钟传输0到10个数据包，偶尔高峰期在10到20个数据包之间，这很可能是由于文件上传和下载。

然而，图中标记为“被入侵的端点”的主机的数据包数量可以清楚地看到，它的基线数量提高到每5分钟传输15至20个数据包，偶尔会出现高达25个数据包的峰值。 在我们的测试中，这个端点是攻击者注入 Slack.exe 进程并使用合法的 Slack 域名打开 C2通道的地方。 我们可以清楚地看到，这组操作已经导致 Slack 可执行文件以一种不正常的方式运行，进程的整个网络配置文件被提高到高于在网络上运行的其他 Slack 进程的配置文件。

其他的检测注意事项

攻击者的行为

除了已经讨论过的异常情况和技术之外，重要的是要记住，C2机制的目的是启用对手连接，并允许攻击者在端点上执行未来的操作。 这些行动的结果也可以用来促进检测，例如，数据外泄几乎总是会导致从端点进程通过目标网络边界流动的流量水平增加和扩展。

此外，一旦端点上的攻击者 TTP 搞的不好，通常会导致 C2机制的识别。 在下面的图片中，我们可以看到攻击者通过 C3中继部署了一个简单的持久化机制。 如此明显的行动通常会引发对父进程的详细审查，在这种情况下，这可能会导致 C2 机制被识别到。

这个明显的恶意攻击行为的例子很好地说明了，当低技能的攻击者使用高级的框架(如 C3)试图减少被检测到的机会，但是却缺乏必要的技能和经验来保持在框架之外不被发现。

总结

为了让蓝队能够有效地进行威胁狩猎，并拥有最好的能力来检测攻击者，他们需要持续访问高质量的数据，以便能够在斩杀链中的尽可能多的阶段进行检测。 虽然我们能够找到几种方法来检测 C3 的存在，而不依赖于斩杀链的初始阶段的历史数据，但很明显，当攻击者使用先进的方法(如 C3模块提供的方法)来掩盖他们的 C2 通信行为时，检测他们的存在是特别困难的。 因此，蓝队必须确保他们在斩杀链的其他阶段有详细的覆盖范围，以便在攻击者能够安全访问被入侵的网络之前发现并阻止攻击者。

如果你能够建立网络上“正常”的样子，那么检测更高级的攻击者 TTP 就会变得非常容易。 通过确保防御者能够从网络上的所有端点提取数据，不仅能够确保适当的覆盖范围，而且还能够通过比较他们所访问的数据，使他们能够寻找偏离正常活动的数据。

鉴于攻击者 TTP 的性质在迅速变化，拥有内部攻击和防御团队的规模更大、更成熟的机构应该相互传授知识，以进一步发展自己的能力。 MWR 实验室和 Countercept 有着长期的合作历史，以促进他们的总体目标，最近的例子就是 C3项目。 我们在这篇博文中详细介绍的威胁狩猎研究的结果将被注入到 C3的开发过程中，以确保该框架继续成为红队在对抗仿真活动中所使用的有价值的工具。

参考资料

[1] https://www.welivesecurity.com/2017/06/06/turlas-watering-hole-campaign-updated-firefox-extension-abusing-instagram

[2] https://securingtomorrow.mcafee.com/mcafee-labs/vpnfilter-botnet-targets-networking-devices

[3] https://www.fireeye.com/blog/threat-research/2018/08/fin7-pursuing-an-enigmatic-and-evasive-global-criminal-operation.html

[4] https://labs.mwrinfosecurity.com/tools/c3

本文翻译自：https://labs.f-secure.com/blog/hunting-for-c3/如若转载，请注明原文地址：