EDR 的阴暗面：将 EDR 重新用作攻击工具

端点检测和响应 (EDR) 解决方案已成为许多企业端点安全策略的关键组成部分，预计到2030 年其市场价值将接近 170 亿美元。这在很大程度上归因于 COVID-19 疫情后远程办公的增加、由此产生的自带设备 (BYOD) 趋势（员工使用个人设备进行与工作相关的活动），以及网络威胁的不断演变。 

EDR 解决方案旨在监控最终用户设备（如笔记本电脑、台式机和服务器），以帮助组织更好地检测和应对勒索软件和恶意软件等威胁。正如Gartner所指出的，EDR 解决方案“记录和存储端点系统级行为，使用各种数据分析技术来检测可疑系统行为，提供上下文信息，阻止恶意活动，并提供补救建议以恢复受影响的系统。”为了执行这些活动，EDR 通常以最高权限运行，同时具有“防篡改”和持久性。  

作为一名安全研究员和前恶意软件研究员，我一直在观察 EDR 解决方案与不断演变的恶意软件之间的持续竞争——随着一种恶意软件变得越来越复杂，另一种恶意软件也变得越来越复杂。我最近的研究项目是在Black Hat Asia 2024上首次展示的，旨在探索如何操纵两者之间的关系，使 EDR 成为恶意攻击工具。具体来说，我想看看我是否可以创建作为 EDR 本身一部分的恶意软件（而不仅仅是能够绕过它），同时保持持久、隐秘和高权限。我把目光投向了市场上使用最广泛的解决方案之一：Palo Alto Networks Cortex 扩展检测和响应 (XDR) 平台。 

下面，我将首先概述这项研究的主要发现和要点。接下来，我将深入介绍作为 Cortex XDR 安装过程的一部分提供的内容文件的详细信息，特别是我在这些文件中发现的有关其勒索软件保护功能的功能的信息。我将提供示例和演示，说明如何使用这些信息开发多种技术来绕过 XDR。然后，我将解释我的研究过程如何确定进一步利用 XDR 行为的方法，从而使我能够开发另一种绕过方法，甚至插入我自己的恶意软件以在 XDR 的某个进程中运行。最后，我将重点介绍供应商的响应，并解释我们如何与更广泛的安全社区共享这些信息，以帮助组织保护自己。

概述 

主要发现 

作为安装过程的一部分，Cortex XDR 包含基于 Lua 的内容文件，其中包含其检测机制的底层逻辑。它利用这些文件中的信息来执行其保护功能。通过分析这些内容文件，我深入了解了 XDR 某些保护措施背后的逻辑。这使我能够设计出规避某些保护措施的方法，例如：

• 加密指定文件夹内的文件，但不影响蜜罐文件以避免被发现。

• 对lsass.exe进程进行内存转储，该进程保存用户凭据和安全令牌等敏感数据。

在我的整个研究过程中，我还找到了利用 Cortex XDR 行为的方法，包括：

• 绕过 Cortex 的文件防篡改保护，最终使我能够加载易受攻击的驱动程序（自带易受攻击的驱动程序 [BYOVD]）并在其中一个驱动程序中修补 Cortex XDR 的管理密码验证。这使我能够更改 Cortex 的逻辑以拒绝任何管理员密码，从而阻止管理员使用 Cortex 管理服务器上的管理员卸载密码或通过对受感染机器的物理访问来删除 XDR。我相信需要对磁盘进行完全格式化并重新安装操作系统和 Cortex XDR 才能删除恶意代码。

• 将恶意代码插入到它的一个进程中，授予我高权限，并允许我保持不被发现和持久的攻击状态。

总结

我们认为这项研究可能会给数百万用户带来重大的安全风险，其影响有以下几个重要启示：

• 主动研究以识别终端产品中的安全风险可能比研究操作系统 (OS) 中的安全风险更有价值。利用操作系统中的风险的攻击者仍必须与另一个守护者抗衡：EDR。但是，如果攻击者突破了最高级别的守护者（即 EDR），他们就可以不受限制地访问大量强大的功能，而无需面对任何守护者。

• 安全产品检测过程背后的逻辑应受到严格保护。这项研究证明，通过让攻击者通过解决方案的内容文件访问这种敏感的检测逻辑，他们更有可能设计出绕过它的方法。我们认为端点安全供应商必须确保：

• 内容文件在磁盘上时是加密的。虽然这些文件最终会在内存中解密，但这会使分析文件和开发绕过方法变得更加困难。 

• 内容文件必须经过数字签名/验证，并且不依赖于可能作为单点故障被绕过的外部防篡改层。 

• 在“允许列表”或“阻止列表”中添加进程或操作应基于多个参数。更具体地说，这些参数不应具有被攻击者操纵的能力。例如，仅根据进程名称将进程添加到“允许列表”是不够的，因为攻击者可以轻松修改该名称，或者根据命令正则表达式检测进程转储。

背景

Cortex XDR 安装过程

Palo Alto Cortex XDR 平台支持 Windows、Mac 操作系统 (OS) 和 Linux 环境。我决定只关注 Windows 代理，并着手首先了解它的工作原理。作为起点，我探索了在安装过程中写入磁盘的文件，并注意到C:ProgramDataCyvera文件夹下有许多其他与 XDR 相关的文件和文件夹。 

在该文件夹中，我发现了另一个名为content的文件夹。它似乎包含策略规则以及基于文本且易于理解的 Lua 和 Python 文件。

Cortex XDR 勒索软件防护 

在进一步检查内容文件夹后，我注意到一个名为ransom.lua 的文件，这让我对 Cortex 的勒索软件保护机制有了很好的了解。本质上，Cortex 将蜜罐文件隐藏在机器的各个位置，以协助检测勒索软件。如果某个进程试图修改这些文件，XDR 会将其识别为可能的勒索软件，并终止该进程。

Cortex 还希望阻止大多数合法进程查看蜜罐文件——这样做是为了防止它们意外修改诱饵文件，从而导致错误警报或进程终止。为此，Cortex： 

• 保存不应能够看到ransom.lua文件中的蜜罐文件的合法进程列表

• 使用微过滤驱动程序使蜜罐文件对这些进程不可见 

研究过程

根据我了解到的有关 Cortex XDR 勒索软件保护如何工作的信息，我确定了我的研究目标。我想要： 

• 首先，看看我是否可以利用从阅读ransom.lua文件中获得的知识来绕过 XDR 的勒索软件保护。 

• 其次，看看我可以使用内容文件中的检测逻辑完成哪些其他恶意操作。 

• 第三，找到一种允许我在 XDR 内部实际运行恶意软件而不是仅仅绕过它的技术。 

绕过技术

Cortex XDR 勒索软件防护绕过

首先，我验证了 Cortex XDR 是否已启动并运行，并且启用了所有服务和保护。我编写了一个非常简单的勒索软件，名为ransom.exe，它会在第一次测试中加密给定文件夹中的所有文件。我在包含重要文件的Documents文件夹中运行了它。正如预期的那样，Cortex 使用其勒索软件保护检测到了这一恶意行为，并且文件未被加密。

为了进行真正的测试，我选择了ransom.lua文件中白名单程序的名称之一——aaplayer.exe，并相应地重命名了勒索软件。我再次在Documents文件夹中运行它，这次成功了。我能够加密那里的所有文件，成功绕过 Cortex XDR 的勒索软件保护。 

为什么？当勒索软件在特定文件夹上执行时，它会列出文件夹中的所有文件，然后对其进行加密。通过为勒索软件赋予与白名单进程之一相同的名称，我能够阻止它查看/列出Documents 文件夹中的蜜罐文件。因此，它只加密文件夹中的合法文件，蜜罐文件不受影响，并使其不被 XDR 检测到。 

要了解此过程的实际操作，请查看下面的演示。 

ProcDump 绕过

在成功绕过勒索软件保护后，我想尝试更多恶意攻击，看看 Cortex XDR 会如何响应。我的下一个测试是尝试转储lsass.exe进程的内存，该进程保存了有关其运行的机器的非常敏感的数据（例如，用户凭据和安全令牌等数据）。

首先，我使用 ProcDump 将lsass内存转储到名为lsass.dmp的文件中。ProcDump 是一个 Windows 命令行实用程序，可用于创建捕获正在运行的进程的内存快照的进程转储文件。 

正如预期的那样，我收到了来自 XDR 的预防警报。并且，它还好心地告诉我，是Regex检测发现了我的问题。

我需要一种方法来运行此命令而不被正则表达式测试发现，因此我在命令中间插入了两个引号并再次执行它。这不会改变命令结果，但我希望它能绕过正则表达式检测。

这成功绕过了由 Regex 检测引起的“可疑进程创建”规则，该规则在我修改命令行之前阻止了我。但是，我收到了来自不同 Cortex 预防模块的四条警报，所有这些警报都与mini-dump-write-dump函数有关。 

因此，我返回内容文件并搜索了这些预防规则。我在一个名为dse_rules_config.lua的文件中找到了所有这些规则。以下是其中一条预防规则的示例，它被称为mini-dump-write-dump rpm deterministic，操作是阻止它。

起初，这看起来像是一条死路，我无能为力。然而，经过仔细检查，我注意到dse_rules_config.lua文件中有一个名为mimikatz_rpm_process_whitelist的列表。由于它包含术语rpm，而该术语也包含在预防规则命名中（例如mini-dump-write-dump_rpm_terminate），所以我认为它们之间可能存在某种关系。 

我尝试将ProcDump程序重命名为listdlls ，它是mimikatz_rpm_process_whitelist中列入白名单的程序之一。我再次执行该命令，它成功了——我能够转储lsass 内存。

要了解此过程的实际操作，请查看下面的演示。 

防篡改绕过

首先，我开始考虑如果我向内容文件添加/删除自己的规则会发生什么。为了弄清楚这一点，我需要了解 Cortex 如何保护其文件免受文件篡改。当我尝试修改文件时，即使以管理员身份，我也被阻止并显示“文件访问被拒绝”错误消息。

这种行为让我相信 Cortex 可能使用微型过滤驱动程序来启用这种保护。微型过滤驱动程序是一种拦截（甚至阻止） IO 请求的已知方法。

有了这些知识，我开始对 Cortex 的驱动程序进行逆向工程。我发现系统上有多个驱动程序在运行，但一个名为cyvrfsfd 的驱动程序引起了我的注意。由于fsfd是文件系统过滤器驱动程序的已知快捷方式，因此它似乎可能是负责保护系统文件的驱动程序。事实上，我能够在这个驱动程序中找到这个微型过滤器正在保护以防止修改的文件和文件夹的列表。

对 cyvrfsfd 驱动程序进行逆向工程时 IDA 的片段，显示了应防止篡改的文件和文件夹列表。

但是它如何保护这些文件的呢？经过更多的逆向工程，我发现了负责文件修改的微过滤器的实现，并推断出当有人试图以写权限打开文件时，它基本上会将路径名与受保护文件的路径名进行比较。

那么，我该如何绕过这种保护呢？这种保护是通过路径检查来实现的，这不足以检查文件的所有更改方式。还有其他方法可以更改文件，我决定采用链接的方法。硬链接允许创建看似不同的文件，但实际上，它只是对磁盘上相同数据的另一个引用。这意味着当您对硬链接文件进行更改时，它会直接修改磁盘上的原始文件。

我尝试使用 Windows 内置实用程序mklink创建此硬链接 — 此操作需要管理员权限。不幸的是，这也被微过滤器阻止了。但为什么呢？创建硬链接需要对目标文件的写入权限，而微过滤器阻止我们这样做。

我想知道使用mklink创建链接是否是唯一的方法。在搜索替代方法后，我偶然发现了一个名为symboliclink-testing-tools的google-project-zero存储库。我发现他们以与mklink不同的方式实现硬链接- 他们没有请求对目标文件的写入权限。当我测试他们的工具时，它起作用了。我能够硬链接文件。 

为了看看我能用这些写权限做什么，我尝试从dse_rules_config文件中删除一条安全规则：检测加载易受攻击的驱动程序（rtcore64.sys 驱动程序）。如果成功，这将允许我执行一种自带易受攻击驱动程序 (BYOVD) 攻击，这种攻击可能非常强大。

删除此规则后，我立即尝试将 rtcore64 易受攻击的驱动程序加载到系统中。不幸的是，这仍然被 XDR 阻止，因为它在启动时已经加载了规则。 

我现在需要想办法在修改规则后强制 XDR 再次加载规则。当我查看名为cytool.exe的代理命令行界面 (CLI) 工具时，我注意到有一个选项可以执行名为“签入”的操作，这基本上就是向管理服务器查询新更新（包括策略更新）。

但是，当我尝试运行签到时，内容文件会再次从管理服务器下载，因此我所做的更改会被覆盖。 

我的解决方案是使用hosts文件将所有流量从 XDR 重定向到localhost ，而 XDR 不会阻止这种行为。而且，这种方法奏效了。运行签入后，我的新策略已加载，而 XDR 未检测到rtcore64驱动程序的加载。

接下来，我利用了 rtcore64 驱动程序中一个已知漏洞 ( CVE-2019-16098 )，该漏洞允许用户模式进程读取/写入内核内存，从而实现权限提升。我利用此漏洞修补了 Cortex XDR 使用的驱动程序之一中的管理密码验证。我以任何密码都可以完成 XDR 的任何任务的方式对其进行了修补。也可以对其进行修补，使任何密码都永远不起作用。这意味着任何用户（即使是最强大的用户，如域管理员）都无法从计算机中删除 XDR，因为 XDR 与管理服务器断开连接（因为我更改了 hosts 文件），并且物理卸载需要密码。由于我们刚刚修补了驱动程序，所以任何密码都不起作用。为了确保 XDR 与管理服务器断开连接，我们甚至可以利用 XDR 的受保护文件列表来保护 hosts 文件免受任何修改。

要了解此过程的实际操作，请查看下面的演示。 

将 XDR 作为恶意软件运行

我发现的绕过方法意义重大，因为它们可以让我在受害者计算机内部执行各种恶意操作。但是，它们并没有达到在 EDR 内部运行恶意软件的真正目的。因此，我继续考虑高级持续性威胁 (APT) 组织在这种情况下可能会做什么。大多数 APT 组织都追求隐身、持久性和高权限。 

我开始考虑是否可以修改 Lua 规则。由于 Lua 实际上是一种编程语言，也许我可以插入自己的恶意代码在 XDR 中运行，而不是简单地更改规则。为了进行健全性测试，我尝试插入一段非常简单的代码，该代码会在桌面上创建一个文件。添加代码并运行检查后，它成功了。

接下来，我编写了一个可以执行命令的简单函数。目标是看看我是否可以在cyserver进程中运行自己的命令。 

但这次发生了一件非常奇怪的事情——当我尝试运行此代码时，作为主要 XDR 进程的cyserver.exe完全崩溃了。io.popen函数是导致该行为的行。我的假设是，我添加的代码调用了未处理的异常，导致cyserver.exe崩溃。

我尝试了更多使用 LUA 运行代码的技术，包括加载恶意动态链接库 (DLL) 和使用其他 Lua 命令运行代码。不幸的是，这些都不起作用。但是，cyserver崩溃的这种行为很快就会派上用场。

在我早期探索内容文件的过程中，我也遇到了一些 Python 文件，并想知道它们在哪里使用。 

我知道我可以修改所有内容文件，包括那些 Python 文件。如果 Cortex 可以运行这些文件，也许我可以操纵 Cortex 来运行我的 Python 脚本。我首先查看了 Cortex 正在运行的进程。我们可以看到所有进程都以最高权限运行。

我看到了主cyserver进程，它下面有一些工作进程，还有另一个进程，名字很有趣：cortex-xdr-payload.exe。当我查看进程的属性时，它似乎有一个命令行，这让我相信它可能是某种配置文件。我还注意到名称包含“service_main.json”，这似乎很有趣。 

当我打开该文件查看其内容时，它似乎是一个配置文件，描述了名为service_main.py的服务的运行参数。 

该脚本看起来像一个循环运行的服务，并尝试从其他服务获取待处理的任务并执行它们。 

好消息是我知道我可以更改文件内容并插入我自己的恶意代码。坏消息是这个 Python 脚本已经加载到cortex-xdr-payload进程中，这意味着即使我修改了这个脚本，也不会真正影响cortex-xdr-payload进程。

为了让cortex-xdr-payload进程重新加载这个 Python 文件，我尝试运行之前使用的签入技巧，希望它能让进程再次加载修改后的 Python 文件。但它没有奏效；进程在签入期间保持活动状态，并且没有加载新的 Python 文件。 

回想起io.popen函数之前是如何导致cyserver崩溃的，我想我可以利用这种行为。我修改了 Python 主服务脚本，导致cyserver崩溃，然后立即将其重新打开。这导致我的代码运行，让我能够以 NT/系统权限（最高权限之一）从后门访问机器。由于我的恶意软件位于cyserver内部，并将从其某个进程运行，因此它是不可检测的、隐秘的、持久的和高权限的。   

要了解此过程的实际操作，请查看下面的演示。 

供应商回应 

所有问题均于 2023 年报告给 Palo Alto Networks，并于 2024 年 2 月收到了以下回复：

“安全是我们最优先考虑的事情。SafeBreach 在 [10] 个月前就通知了我们其研究情况，当时我们通过自动内容更新解决了该功能绕过问题。”  

结论  

本研究探讨了让 EDR 解决方案的敏感检测逻辑易于访问可能带来的安全隐患。我们展示了恶意行为者如何利用这些信息来逆向工程绕过 EDR，从而给数百万用户带来重大的安全风险。为了帮助减轻本研究发现的漏洞的潜在影响，我们采取了以下措施： 

• 负责任地向 Palo Alto Networks 披露了我们的研究结果，并与他们会面，讨论针对我们发现的问题的可能解决方案。如上所述，他们发布了修复程序。我们强烈建议所有 Cortex XDR 用户确保其软件版本是最新的，以防止任何此类攻击的漏洞。我们还强烈建议其他端点安全供应商确保：

• 内容文件在磁盘上时是加密的。虽然这些文件最终会在内存中解密，但这会使分析文件和开发绕过方法变得更加困难。 

• 内容文件必须经过数字签名/验证，并且不依赖于可能作为单点故障被绕过的外部防篡改层。 

• 在我们最近的Black Hat Asia 2024演示中，与这里更广泛的安全社区公开分享了我们的研究成果，以提高人们对这些问题的认识。

• 提供了一个研究存储库，其中包含能够验证这些漏洞的工具，并作为进一步研究和开发的基础。 

• 在 SafeBreach 平台中添加了原始攻击内容，使我们的客户能够根据本研究中概述的漏洞验证他们的环境，从而显著降低他们的风险。