简介 - 我们离开的地方

DISCLAMER：这篇文章是与Devid Lana合作完成的。你可以在这里找到他的博客：her0ness - 攻击 EDR 第 2 部分

从我们上次的研究开始，我们继续探索 EDR 解决方案的攻击面，在我们的审查下 STRANGETRINITY。上次，我们重点介绍了 EDR 配置中的排除项（可以理解为白名单），这些排除项允许我们执行其他方式无法执行的操作。这一次，我们的重点将放在 EDR 代理与其server之间的通信通道上。

对于那些不熟悉通用 EDR 体系结构的用户，在大多数情况下，将在系统上部署的代理最终需要与集中式租户通信（译者注：在国内，大部分都是在内网部署一个server）。这通常是因为 EDR 代理需要：

从集中式租户（或者本地server）提取策略并应用新策略
将遥测数据发送回中央服务器

可以想象，这个组件特别重要，任何干扰或篡改都可能产生毁灭性的后果。正如我们上次所做的那样，我们将首先制定一个假设，该假设将在这篇博文的其余部分得到验证。

在这种情况下，正如本节预先宣布的那样，我们的假设如下：

处于有利网络位置的攻击者是否能够拦截和篡改 EDR 客户端-服务器通信？如果是这样，它会造成什么伤害？

漏洞

通常，为了拦截和篡改从一台主机到另一台主机的网络通信，必须满足以下条件之一：

您与受害主机位于同一本地子网中，还可以利用 TLS 通信中的漏洞来拦截加密流量。这是不太可能的情况，因为我们很少（如果有的话）处于类似的情况。
您在受害者主机上站稳了脚跟。这可能需要管理权限来修改网络配置或以某种方式转移特权进程（在本例中为 EDR）的流量。

第二种情况是最现实的，我们假设我们获得了对主机的管理访问权限，并且我们以某种方式想要：

篡改EDR解决方案以执行我们的恶意指令。
阻碍 EDR 的功能并阻止它执行它应该执行的行为

命令执行总是很有趣，但是，我们也意识到，管理访问权限与解除EDR之间的界限也是非常相关的。因为供应商似乎担心管理员用户能够在未经集中式租户（或本地server）批准的情况下卸载他们的软件。在我们看来，随着我们为这个短期冲刺研究分配的时间，这个目标似乎更容易实现，而且我们过去与该供应商的经验表明，这个组件中的错误可能会给我们带来合适的回报。

对于不熟悉这些概念的读者来说，EDR 归根结底是软件，就像许多其他软件一样。这意味着它们需要以某种方式安装，并在某个时候卸载。在早期，可以使用与删除任何其他类型的已安装程序相同的命令从主机中删除 EDR。这种可能的证明是不久前发布的卸载 CrowdStrike 的原子测试。没过多久，攻击者就开始意识到这是一回事，并在他们的武器库中实施了它。此外，还出现了一整类旨在阻止防御性产品功能的攻击，如今，人们经常看到采用多种策略来实现这一目标，从垃圾 BAT 脚本到利用易受攻击的驱动程序。另一方面，供应商开始实施一类通常称为“防篡改”的功能，以防止任何未经授权的程序阻止防御软件的运行。MITRE 在 ATT&CK 项目中捕获了其中的一些知识：削弱防御：禁用或修改工具，子技术 T1562.001。对于IT领域的许多人来说，这个界限似乎很愚蠢，在我们担任顾问期间，我们多次被告知：“这是一个不可能的情况，我们不向用户提供管理访问权限”。尽管这是一个公正的说法，但证据再次比信念和偏见更重要，因为有无数的威胁情报报告记录了攻击者如何使用有效的凭据、利用面向互联网的资产等等来最终处于该位置;这甚至不算在大多数组织中通过滥用 Active Directory 功能来提升特权是多么的普遍，这往往是一个非常有效的反驳论点，几乎无可争议。从根本上说，这整段是要重申这一界限被认为是重要的，而且理所当然地如此。

一般来说，为了改变某物的配置，你需要能够首先读取它（或者在最坏的情况下，通过与特定组件的交互来凭经验确定变化）。本节的其余部分将介绍如何提取 EDR 的配置。

配置提取

技术活动首先对产品暴露的攻击面进行彻底侦察，初步分析是否注册了任何 COM 服务器。幸运的是，这个假设被证明是正确的，EDR 实例化了两个 COM 类，我们将称之为 COMTRINITY_A 和 COMTRINITY_B。

在仔细检查了这些类之后，对它们公开的方法进行了分析，目的是检测是否存在来发挥我们的优势的任何可以利用的功能。遗憾的是，由于在 ACL 级别应用的限制，许多方法最终无法使用，仅允许属于 NT SERVICE\STRANGETRINITYService 解决方案的虚拟服务帐户使用它们。

但是，我们设法找到了一个异常，并且我们将调用 StrangeTrinityAgentStatus（）的特定方法可供 Administrators 组的每个用户部分访问。

调用该方法将返回代理的状态、启用的安全功能和远程租户的 URL。

以下是内容示例：

{
 "agent-unique-id": "8fb4b3fc-4576-11ee-be56-0242ac120002",
 "agent-last-checkin": "2020-02-12",
 "tenant-url": "https://tenant-management.strangetrinity.com",
 "anti-tampering": "TRUE",
 "installed-site": "site123456",
 "agent-version": "2.0",
 "some-other-random-params": "foobar"
}

从上面的片段中可以看出，存在一个名为“防篡改”的字段。这强化了我们的假设，即设置在某种程度上是可配置的。此外，由于这是一项研究工作，而不是黑盒测试，因此使用了 EDR 的云租户来验证这一点。

对 EDR 基于 Web 的功能进行非常简短的探索表明，确实可以从云控制台禁用防篡改功能。我们遵循的下一步是截获从 EDR 代理到租户的通信，尝试对通信协议进行逆向工程，并最终尝试手动触发防篡改功能的撤防。

流量拦截

幸运的是，从代理到租户的通信是使用 HTTPS 协议完成的，这使我们能够依靠一套非常完善的工具进行测试。由于发现流量是用普通 HTTPS 加密的（使用 Wireshark 验证了这一点），我们的想法是在主机上安装一个流氓 CA 并执行 SSL 检查和流量操作。这是企业一直用来监控其网络上流量的一种非常常见的技术。大多数供应商依靠在用户端点上安装受信任的 CA 来允许 SSL 拦截。为简单起见，攻击是使用拦截代理（如 BurpSuite 或 Zed Attack Proxy）执行的，显然，没有必要强调，所有这些工具都可以在不安装其他软件的情况下轻松武器化。

我们采取的设置步骤如下：

向 hosts 文件添加新条目，将管理租户的 DNS 记录解析为 localhost 地址
在端口 443 上启动代理，启用不可见代理
等待代理签到

关于如何配置 Burp（我们实际使用的软件）这个特定场景的更好解释可以在这里找到：不可见代理 - PortSwigger。使用不可见代理是必要的，因为 EDR 代理不具有代理感知能力。

几秒钟后，代理签入并通过 REST API 向管理租户发送了一堆 HTTP 请求。

使用的通信机制是典型的客户端-服务器轮询体系结构，EDR 传感器定期回调以请求租户更新，同时发送定期遥测数据，这不出所料地类似于企业级命令和控制。

作为响应，它收到了另一个 JSON，其中包含其他设置和配置的列表。

"config-data": {
 "sendingData": [
  "sent.data"
 ], 
 "some": "some",
 "other": "other",
 "params": "params",
 "engineData":{
  "os.data" : "data",
  "status.data" : "data",
  "behavioural.data" : "data",
  "reputation.data" : "data",
  "exploit.data" : "data",
 }
 "agent-unique-id": "8fb4b3fc-4576-11ee-be56-0242ac120002",
 "threat-hash": "hash",
 "scanner-module": "behavioural",
 "anti-tampering": "TRUE",
 "installed-site": "site123456",
 "agent-version": "2.0",
 "agent-logging-event": "true",
 "kernel-protection": "true",
 "some-other-random-params": "foobar"
}

现在剩下的就是篡改请求，通过代理手动修改参数设置，将防篡改字段设置为false。

如前所述，防篡改功能通常包括保护 EDR 软件及其组件免遭未经授权的修改的措施。这可能涉及代码完整性检查、PPL 级别保护、敏感数据加密以及防止未经授权更改配置设置的控制等技术。防篡改功能的目标是确保 EDR 解决方案保持正常运行并抵御可能试图破坏其功能的攻击。

此时，将再次获取代理的配置，以确认我们的操作是否有任何影响。令我们非常惊讶的是，如此微小的更改有效地禁用了防篡改功能，这甚至反映在动态检索的配置中。

作为最后的测试，我们生成了一个高完整性的命令提示符，成功地停止了产品的几个组件。我们还修改了注册表项，确保在下次重新启动时，该解决方案将被完全击败。为此，我们主要依赖于用于停止服务的sc.exe二进制文件和用于暂停正在运行的进程的其他实用程序。

概念验证（POC)

以下 Powershell 代码用于检索代理的配置：

$clsid = New-Object Guid “{GUID}”  
$type = [Type]::GetTypeFromCLSID($clsid)

$object = [Activator]::CreateInstance($type)  
$object.StrangeTrinityAgentStatus()**

该披露还包括自定义HTTPs代理的代码，但是，考虑到使用BurpSuite等工具可以获得相同的效果，发布不会为这项研究增加任何价值。

尾声

正如我们从分析中推断的那样，租户（server)和代理之间的通信构成了任何 EDR 解决方案的关键方面。这种通信不仅允许将遥测数据从端点收集和传输到集中式云以进行进一步分析，而且还可以快速实施需要在整个环境中的配置更改。

从攻击者的角度来看，拦截和任意修改这些参数的能力当然可以提供战术和操作优势。这使他们能够获得足够的时间窗口来执行利用后操作，而不会触发来自解决方案的警报，并随后快速恢复通信，使环境恢复到正常状态。实际上，通过篡改通信通道可以发现各种错误。从可以推断的情况来看，该特定组件的开发没有进行适当的威胁建模，也没有进行适当的测试。

话虽如此，与本系列第 1 部分中所做的类似，供应商对披露做出了积极回应并应用了补丁，以便执行相同的攻击不再是普遍的。

如果您担心您使用的产品可能会受到类似问题的影响，建议您重复本研究中概述的步骤并对其进行技术验证。供应商应实施更强的控制和完整性检查，以确保收到的消息在传输过程中不会被修改。