EDR 规避与硬件断点的盲侧技术

【翻译】EDR Evasion with Hardware Breakpoints The Blindside Technique

使用 Windows 事件跟踪（ETW）和 Windows 反恶意软件扫描接口（AMSI）的概念验证（PoC）技术已经存在一段时间。这些包括@rad9800创建的TamperingSyscalls和由EthicalChaos创建的无进程补丁 AMSI 绕过等深入工作——但在这两种情况下，攻击都是通过在当前进程内存中钩住特定函数来操纵它以达到意图之外的目的。

Cymulate 进攻研究小组能够将该方法扩展为一种名为“盲侧”的新技术，使该方法能够在更广泛的范围内工作。盲侧技术加载一个未被监控和未被钩住的 DLL，并利用调试技术来运行任意代码。

这使得在许多商业 EDR 和 XDR 平台的监视下，可以执行的代码更加灵活。

硬件断点和调试寄存器（DR0-DR7）概述

由于盲侧依赖于硬件断点，因此理解这些断点和调试寄存器的功能至关重要。

什么是硬件断点和调试寄存器？

硬件断点在 x86 和 x64 处理器上均可用，包含八个调试寄存器：DR0 – DR7。这些寄存器的长度为 32 位或 64 位，具体取决于处理器类型，并控制调试操作的监控。

与软件断点（Windows 开发人员更为熟悉）不同，硬件断点允许“内存断点”，当指令尝试读取、写入或执行指定内存地址时（基于断点配置）触发。然而，限制在于任何时候只能激活少数几个硬件断点。

调试寄存器（DR0-DR7）的功能

• DR0-DR3：保存断点的线性地址，称为调试地址寄存器。当指令与这些寄存器中的地址匹配时，断点被触发。
• DR4-DR5：这些是保留的调试寄存器，在此技术中未使用。
• DR6：称为调试状态寄存器，报告在上一个异常期间采样的调试条件。
• DR7：调试控制寄存器在盲侧技术中至关重要，因为它控制每个断点及其条件。

这些调试寄存器的主要功能是设置和监控最多 4 个编号为 0 到 3 的断点。对于每个断点，可以指定以下信息：

• 断点发生的线性地址。

• 断点位置的长度（1、2 或 4 字节）。

• 在该地址执行的操作将生成调试异常。

• 断点是否启用。

• 在生成调试异常时，断点条件是否存在。

调试异常

在硬件断点的异常中，有两个后果：调试异常（#DB）和断点异常（#BP）。对于盲侧技术而言，调试异常（#DB）是最重要的。当断点被触发时，执行将被重定向到处理程序——通常是调试程序或更广泛软件系统的一部分。需要注意的是，盲侧技术中的异常仅在单步异常时触发。

设置盲侧技术

第一步：断点处理程序

在准备利用该技术时，首先需要建立一个断点处理程序。以下是 C++ 中处理程序的示例：

该函数首先检查 EXCEPTION_POINTERS 结构的 ExceptionRecord 成员中的异常代码是否为 EXCEPTION_SINGLE_STEP，这表示发生了单步异常。如果是这种情况，函数接着检查结构的 ContextRecord 成员中的指令指针（Rip）是否等于第一个调试寄存器（Dr0）的值。如果这也为真，函数将打印一些关于异常的信息，包括异常地址、某些寄存器的值和堆栈指针（Rsp）的值。

最后，函数设置恢复标志（RF），并返回 EXCEPTION_CONTINUE_EXECUTION 以指示执行应继续。如果异常代码不是 EXCEPTION_SINGLE_STEP，函数将返回 EXCEPTION_CONTINUE_SEARCH 以指示应继续搜索处理程序。

技术设置第二部分：设置断点

在处理程序配置好以处理异常后，下一步是创建实际的断点。

使用 C++，以下是断点配置的示例：

该函数接受两个参数。第一个是系统应在其上设置断点的地址，第二个是启用或禁用断点。该技术然后获取被操作的指定线程的当前上下文，并将其存储在上下文变量中。如果 setBP 变量为真，代码将 DR0 设置为攻击者希望断开的地址。请注意，该技术也可以使用 Dr1、Dr2 或 Dr3 来存储地址（如有必要）。随后，执行将 Dr7 的第一个位设置为 1 以启用断点，并清除第 16 和第 17 位以中断执行。

相反，如果 setBP 变量为假，代码将清除 Dr0，并对 Dr7 的第一个位执行相同操作。最后，代码设置线程的上下文以进行更新。

利用盲侧

在研究此主题时，Cymulate 回顾了众多研究专业人员创建的通用方法的重要工作。Cymulate 进攻研究小组意识到，与已知技术不同，可以创建一个新的调试模式进程，在 LdrLoadDll 上设置断点，并强制仅加载 ntdll.dll。这创建了一种情况，结果是一个干净版本的 ntdll，没有钩子。攻击者可以将干净的 ntdll 的内存复制到现有进程中，并解除所有先前钩住的系统调用。

当进程首次创建时，ntdll.dll 将自动加载，但其他 DLL 也会参与其中。通过利用此技术，断点通过钩住 LdrLoadDLL 来阻止加载其他 DLL，并创建一个仅包含 ntdll 的独立、未钩住状态的进程。

逐步解析盲侧技术

在查看整个过程中，盲侧技术的应用可以允许一个未被监控的进程在 Windows 会话的上下文中运行，如下所示：

第一步：创建一个新的调试模式进程

第二步：查找 LdrLoadDll 的进程地址

由于创建的进程是一个目标子进程，它将具有相同的 ntdll 基地址和相同的 LdrLoadDll 地址。这意味着必须识别 LdrLoadDll 的地址。

第三步：设置断点

找到 LdrLoadDll 地址后，下一步是对远程进程设置断点。

该函数接受两个参数：应设置断点的地址和应设置断点的线程的句柄。

该函数首先初始化一个 CONTEXT 结构，并将其 ContextFlags 成员设置为 CONTEXT_DEBUG_REGISTERS 和 CONTEXT_INTEGER 的按位或，这指定该结构应填充线程的当前调试寄存器和整数寄存器。然后，它将第一个调试寄存器（Dr0）的值设置为指定地址，并将 Dr7 寄存器的第 0 位设置为启用断点。

第四步：等待断点触发

接下来，函数调用 SetThreadContext() 函数将更新的上下文应用于线程。然后，它进入一个无限循环，使用 WaitForDebugEvent() 函数等待调试事件。当接收到调试事件时，函数检查它是否是具有 EXCEPTION_SINGLE_STEP 异常代码的异常调试事件。如果是这种情况，函数使用 GetThreadContext() 函数检索线程的当前上下文，并检查异常地址是否与指定地址匹配。

如果异常地址与指定地址匹配，函数将重置 Dr0、Dr6 和 Dr7 寄存器，并不返回任何内容，这样做是为了阻止 LdrLoadDll 加载其他 DLL。否则，它将重置断点并通过调用 ContinueDebugEvent() 函数与 DBG_CONTINUE 参数继续执行。这个循环将持续，直到 WaitForDebugEvent() 返回 0，表示没有更多的调试事件可用。

第五步：内存加载和解除钩子

然后需要将 ntdll 的内存复制到目标进程中，并解除任何系统调用的钩子。

该函数有一个参数，即调试的进程的句柄。调试进程的基地址将与 ntdll 的基地址相同。在使用 NtReadVirtualMemory 读取 ntdll 的内存后，freshNtdll（分配的缓冲区将存储该内存信息）。现在可以安全地终止原始进程，因为不再需要它。

第六步：覆盖钩子

接下来，需要遍历所有内容以找到 ntdll 的.text 段的虚拟地址，将保护更改为 PAGE_EXECUTE_READWRITE，并将新映射缓冲区（freshNtdll）的.text 段复制到原始钩住的 ntdll 版本，从而导致钩子被覆盖。

第七步：清理

结束此技术的最后一步是恢复原始保护。

缓解盲侧

盲侧技术并非免于缓解。尽管它可以绕过依赖钩子检测行为的 EDR（端点检测与响应）解决方案，但有几种策略可以降低其有效性，并在使用时提醒安全团队。

1. 监控 SetThreadContext 函数的使用

第一个缓解方法是监控 SetThreadContext 函数的使用。该函数经常被恶意目的滥用。通过检查上下文，安全团队可以识别攻击者是否在调试地址寄存器（DR0-DR3）中放置了一个地址。写入这些寄存器的任何意外数据都是强烈的妥协指示符。当与新 DLL 实例或其他指示符的证据结合时，这种活动可以促使反恶意软件解决方案采取行动。

2. 跟踪可疑的调试函数和寄存器

另一种方法是监控调试函数以检测恶意活动的迹象。在这些函数运行时，EDR 解决方案应积极检查 DR0-DR3 寄存器以寻找可疑行为。如果发现此类活动，则是潜在威胁的明确指示。

3. 调整 EDR 设置以提高检测能力

尽管盲侧可能会绕过 EDR 平台的默认设置，但调整协议和配置文件可以使这些工具更有效地监控 DR0-DR3 寄存器。如果这些寄存器中的任何一个包含可疑地址，则表明某个进程可能试图钩住它们。

EDR 技术可以将这些行为与其他恶意活动（例如尝试创建未钩住的 DLL）关联起来。通过适当的设置和配置，EDR 可以阻止攻击并在其升级之前终止有问题的进程。

结论

在研究此技术的可行性时，Cymulate 进攻研究小组验证了该技术在多种商业可用的 EDR 和 XDR 平台上的有效性。这项实验的结果是，许多——但不是所有——EDR/XDR 系统都可以通过盲侧技术绕过。

参考文献

• https://www.intel.com/content/dam/support/us/en/documents/processors/pentium4/sb/253669.pdf
• https://ling.re/hardware-breakpoints/
• https://github.com/rad9800/TamperingSyscalls