上面提到的`OB_CALLBACK`结构体也没有文档记录，并且定义
如下：```C
typedef struct OB_CALLBACK_t {
    USHORT Version;                           // usually 0x100
    USHORT OperationRegistrationCount;        // number of registered callbacks
    PVOID RegistrationContext;                // arbitrary data passed at registration time
    UNICODE_STRING AltitudeString;            // used to determine callbacks order
    struct OB_CALLBACK_ENTRY_t EntryItems[1]; // array of OperationRegistrationCount items
    WCHAR AltitudeBuffer[1];                  // is AltitudeString.MaximumLength bytes long, and pointed by AltitudeString.Buffer
} OB_CALLBACK;

使 `CallbackList` 的 `LIST_ENTRY` 的 `Flink` 和 `Blink` 指针指向 `LIST_ENTRY` 自身实际上使列表为空。由于 `_OBJECT_TYPE` 结构在内核符号中已发布，该技术不依赖于硬编码的偏移量/结构。然而，它有一些缺点。

第一个是无法仅禁用来自 EDR 的回调；实际上，该技术影响可能由“合法”软件注册的所有对象回调。尽管如此，应注意对象回调在 Windows 10 上不被任何预装组件使用（在撰写本文时），因此禁用它们不应影响机器稳定性（如果禁用只是暂时的，更是如此）。

第二个缺点是进程或线程句柄操作在操作系统正常功能中非常频繁（几乎是连续不断的）。因此，如果使用的内核写入原语无法“原子地”执行 `QWORD` 写入，那么内核很可能会在覆盖 `_OBJECT_TYPE.CallbackList.Flink` 指针的过程中访问它。例如，MSI 有漏洞的驱动程序 `RTCore64.sys` 一次只能执行 `DWORD` 写入，因此需要 2 个不同的 IOCTL 来覆盖指针，在这两个 IOCTL 之间，内核有很高的概率使用该指针（导致崩溃）。另一方面，有漏洞的 DELL 驱动程序 `DBUtil_2_3.sys` 可以在一个 IOCTL 中执行任意大小的写入，因此使用此方法不会导致崩溃风险。

#### 完全禁用对象回调
我们发现的最后一种技术是完全禁用线程和进程的对象回调支持。在与进程和线程类型对应的 `_OBJECT_TYPE` 结构内部，有一个 `TypeInfo` 字段，遵循文档化的 `_OBJECT_TYPE_INITIALIZER` 结构。后者包含一个 `ObjectTypeFlags` 位字段，其 `SupportsObjectCallbacks` 标志确定所描述的对象类型（进程、线程、桌面、令牌、文件等）是否支持对象回调注册。如前所述，在撰写本文时，Windows 安装上只有进程、线程和桌面对象类型支持这些回调。

由于 `SupportsObjectCallbacks` 位在读取 `CallbackList` 之前（当然也在执行回调之前）由 `ObpCreateHandle` 或 `ObDuplicateObject` 检查，在内核运行时翻转该位实际上禁用了所有对象回调的执行。

该方法的主要缺点是 *KPP*（“*PatchGuard*”）监控一些（所有？）`_OBJECT_TYPE` 结构的完整性，并触发 [`0x109 错误检查`](https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0x109---critical-structure-corruption)，其参数 4 等于 `0x8`，表示对象类型结构已被更改。

然而，足够快地执行禁用/重新启用（以及中间的“恶意”操作）应该足以与 *PatchGuard* 竞速（除非你不走运，周期检查恰好在错误时刻执行）。

### 通过取消链接微过滤器回调绕过 EDR
Windows 筛选器管理器系统允许 EDR 加载“微过滤器”驱动程序并注册回调，以便接收 I/O 操作（如文件打开、读取、写入等）的通知。

以下是筛选器管理器使用的不同内部结构的快速总结：
- 筛选器管理器建立一个“框架”（`_FLTP_FRAME`）作为其根结构；
- 为筛选器管理器管理的每个“磁盘”实例化一个“卷”结构（`_FLT_VOLUME`）（可以是分区、卷影副本或对应于命名管道或远程文件系统的特殊卷）；
- 每个注册的微过滤器驱动程序对应一个“过滤器”结构（`_FLT_FILTER`），描述各种属性，例如其支持的操作；
- 这些微过滤器并非全部附加到每个卷；创建“实例”（`_FLT_INSTANCE`）结构来标记每个
        过滤器<->卷关联；
- 微过滤器注册回调函数，这些函数在特定操作（文件打开、写入、读取等）之前和/或之后执行。这些回调在 `_CALLBACK_NODE` 结构中描述，可以通过不同方式访问：
  - 每个微过滤器实例实现的所有 `_CALLBACK_NODE` 的数组可以在 `_FLT_INSTANCE` 结构中找到；该数组由 IRP “主功能”代码索引，该常量表示回调处理的操作（`IRP_MJ_CREATE`、`IRP_MJ_READ` 等）。
  - 此外，由链接到特定卷的实例实现的所有 `_CALLBACK_NODE` 被重新分组到链表中，存储在 `_FLT_VOLUME.Callbacks.OperationLists` 数组中，该数组按 IRP 主功能代码索引。

`EDRSandblast` 浏览这些不同的结构，以检测与 EDR 相关驱动程序关联的过滤器，并枚举包含监控功能的回调节点。为了禁用它们的效果，节点从它们的链表中取消链接，使它们暂时对筛选器管理器不可见。

这样，在指定时间段内，EDR 可能完全不知道任何文件操作。一个基本示例是在磁盘上创建 lsass 内存转储文件，这不会触发 EDR 的任何分析，因此不会基于文件本身进行检测。

### 通过停用 ETW Microsoft-Windows-Threat-Intelligence 提供程序绕过 EDR
`ETW Microsoft-Windows-Threat-Intelligence` 提供程序记录有关某些常用作恶意的 Windows API 的使用数据。这包括由 `nt!NtReadVirtualMemory` 调用的 `nt!MiReadWriteVirtualMemory` API（用于转储 `LSASS` 内存）并由 `nt!EtwTiLogReadWriteVm` 函数监控。

EDR 产品可以通过分别作为 `SERVICE_LAUNCH_PROTECTED_ANTIMALWARE_LIGHT` 或 `PS_PROTECTED_ANTIMALWARE_LIGHT` 运行，并与 `Early Launch Anti Malware (ELAM)` 驱动程序关联的服务或进程来消耗 `ETW TI` 提供程序生成的日志。

如 [`slaeryan` 在 `CNO Development Labs` 的一篇博客文章](https://public.cnotools.studio/bring-your-own-vulnerable-kernel-driver-byovkd/exploits/data-only-attack-neutralizing-etwti-provider) 中所发布，`ETW TI` 提供程序可以通过在内核内存中将其 `ProviderEnableInfo` 属性修补为 `0x0` 来完全禁用。有关该技术的更多信息，请参阅上述优秀博客文章。

类似于内核回调移除，必要的 `ntoskrnl.exe` 偏移量（`nt!EtwThreatIntProvRegHandleOffset`、`_ETW_REG_ENTRY` 的 `GuidEntry` 和 `_ETW_GUID_ENTRY` 的 `ProviderEnableInfo`）在 `NtoskrnlOffsets.csv` 文件中为多个 Windows 内核版本计算。

### 通过绕过用户态钩子绕过 EDR
#### 用户态钩子的工作原理
为了轻松监控进程执行的操作，EDR 产品通常部署一种称为 *用户态钩子 (userland hooking)* 的机制。首先，EDR 产品注册一个内核回调（通常是 *映像加载* 或 *进程创建* 回调，见上文），允许它们在每个进程启动时得到通知。

当 Windows 加载进程时，在进程实际启动之前，EDR 能够将一些包含其监控逻辑的自定义 DLL 注入到进程地址空间中。在加载时，此 DLL 在每个待 EDR 监控的函数的开头注入“*钩子*”。在运行时，当受监控进程调用被监控的函数时，这些钩子将控制流重定向到 EDR 的 DLL 中的某些监控代码，从而允许它检查这些调用的参数和返回值。

大多数情况下，被监控的函数是系统调用（例如 `NtReadVirtualMemory`、`NtOpenProcess` 等），其实现位于 `ntdll.dll` 中。拦截对 `Nt*` 函数的调用使产品能够尽可能接近用户态/内核态边界（同时保持在用户态），但来自一些更高级别 DLL 的函数也可能被监控。

下面是同一函数在被 EDR 产品钩住之前和之后的示例：```assembly
NtProtectVirtualMemory   proc near
	mov r10, rcx
	mov eax, 50h
	test byte ptr ds:7FFE0308h, 1
	jnz short loc_18009D1E5
	syscall
	retn
loc_18009D1E5:
	int 2Eh
	retn
NtProtectVirtualMemory   endp			

#### 钩子检测
用户态钩子的“弱点”在于它们位于用户态内存中，这意味着它们可以被受检查的进程直接观察和修改。为了自动检测进程地址空间中的钩子，主要思路是比较磁盘上原始DLL与内存中可能已被EDR修改的库之间的差异。为了执行此比较，EDRSandblast遵循以下步骤：
* 通过位于`PEB`中的`InLoadOrderModuleList`枚举所有已加载DLL的列表（以避免调用任何可能被监控且可疑的API）。
* 对于每个已加载的DLL，读取其在磁盘上的内容并解析其头部。同时解析内存中对应的库，以识别节区、导出等。
* 解析并应用DLL的重定位，并考虑对应已加载库的基址。这使得内存中的库与磁盘上的DLL在应用了重定位的节区上具有完全相同的内容，从而使比较可靠。
* 枚举导出函数，并比较“内存中”与“磁盘上”版本的前几个字节。任何差异都表明DLL加载后发生了修改，因此很可能是EDR钩子。

注意：该过程可以推广，以查找任何不可写节区中的差异，而不仅仅是导出函数的起始位置。例如如果EDR产品开始在函数中间应用钩子：）该工具未使用此方法，但已在`findDiffsInNonWritableSections`中实现。

为了绕过这些钩子执行的监控，有多种技术可行，每种技术都有其优缺点。

#### 使用……解除钩子来绕过钩子
绕过基于钩子的监控最直观的方法是移除钩子。由于钩子存在于进程自身可访问的内存中，要移除钩子，进程只需：
* 更改钩子所在页面的权限（RX -> RWX 或 RW）
* 写入已知的原始字节（通过磁盘上的DLL内容获得）
* 将权限改回RX

这种方法相当简单，可用于一次性移除所有检测到的钩子。由攻击性工具在开始时执行，这样后续代码可以完全忽略钩子机制，正常执行且不被监控。

然而，它有两个主要缺点。EDR可能正在监控`NtProtectVirtualMemory`的使用，因此使用它来更改已安装钩子页面的权限（至少在概念上）不是一个好主意。此外，如果EDR运行了一个线程并定期检查钩子的完整性，这也可能触发检测。

关于实现细节，请检查`unhook()`函数在`unhook_method`为`UNHOOK_WITH_NTPROTECTVIRTUALMEMORY`时的代码路径。

**重要说明：为简单起见，此技术在EDRSandblast中作为基础技术实现，用于*展示*其他绕过技术；每种技术都演示了如何获取不受监控的`NtProtectVirtualMemory`版本，但之后执行相同的操作（解除特定钩子）。**

#### 使用自定义跳板绕过钩子
要绕过特定钩子，可以简单地“跳过”它并正常执行函数的其余部分。首先，必须从DLL文件中恢复被EDR覆盖的受监控函数的原始字节。在我们之前的代码示例中，这些字节对应于以下指令的字节：```assembly
mov r10, rcx
mov eax, 50h

最后，我们将这些操作码连接起来，存入（新分配的）可执行内存，并保留一个指向它们的指针。这个对象被称为“*trampoline*”（蹦床），随后可作为函数指针使用，与原始的 `NtProtectVirtualMemory` 函数完全等价。

该技术的主要优势（与以下所有技术相同）在于，钩子从未被擦除，因此EDR对钩子进行的任何完整性检查都应通过。然而，它需要先分配可写内存，再转为可执行内存，这正是shellcode分配的典型特征，从而引起EDR的关注。

有关实现细节，请查看 `unhook()` 函数中 `unhook_method` 为 `UNHOOK_WITH_INHOUSE_NTPROTECTVIRTUALMEMORY_TRAMPOLINE` 时的代码路径。请记住，该技术仅在我们的实现中展示，并且最终用于**移除**内存中的钩子，与以下所有技术相同。

#### 利用EDR自身的trampoline绕过钩子
EDR产品为了使其钩子工作，必须在内存中某处保存它已移除的操作码。更糟糕的是（或者说从攻击者角度看“更好”），为了有效使用原始指令，EDR可能已在某处为自己分配了一个*trampoline*，以在拦截调用后执行原始函数。

这个trampoline可以被搜索到，并用作被钩函数的替代品，无需分配可执行内存，也无需调用除 `VirtualQuery` 之外的任何API，而 `VirtualQuery` 很可能不受监控，因为它是一个无害的函数。

为了在内存中找到trampoline，我们使用 `VirtualQuery` 浏览整个地址空间，寻找已提交且可执行的内存。对于每个这样的内存区域，我们扫描它，寻找一条跳转指令，其目标地址是覆盖指令之后的位置（在我们之前的例子中为 `NtProtectVirtualMemory+8`）。然后，该trampoline可用于调用被钩函数而不触发钩子。

该技术效果出奇地好，因为它几乎能恢复所有在测试过的EDR上的trampoline。有关实现细节，请查看 `unhook()` 函数中 `unhook_method` 为 `UNHOOK_WITH_EDR_NTPROTECTVIRTUALMEMORY_TRAMPOLINE` 时的代码路径。

#### 使用重复DLL绕过钩子
另一种获取不受监控版本的 `NtProtectVirtualMemory` 函数的简单方法是，将 `ntdll.dll` 库的一个副本加载到进程地址空间中。由于两个相同的DLL可以加载到同一个进程中，只要它们具有不同的名称，我们可以简单地将合法的 `ntdll.dll` 文件复制到另一个位置，使用 `LoadLibrary`（或重新实现加载过程）加载它，并使用 `GetProcAddress` 等访问该函数。

该技术非常易于理解和实现，并且有相当大的成功机会，因为大多数EDR产品在进程运行后不会在新加载的DLL上重新安装钩子。然而，主要缺点是，将Microsoft签名的二进制文件以不同名称复制，本身通常会被EDR产品视为可疑行为。

该技术已在 `EDRSandblast` 中实现。有关实现细节，请查看 `unhook()` 函数中 `unhook_method` 为 `UNHOOK_WITH_DUPLICATE_NTPROTECTVIRTUALMEMORY` 时的代码路径。

#### 使用直接系统调用绕过钩子
为了使用与系统调用相关的函数，程序可以重新实现系统调用（用汇编语言），以便在不实际触及 `ntdll.dll` 中的代码（可能被EDR监控）的情况下调用相应的操作系统功能。这完全绕过了对 `ntdll.dll` 中系统调用函数进行的任何用户态钩子。

然而，这也有一些缺点。首先，这意味着需要知道程序所需函数的系统调用编号列表，而该列表随每个Windows版本而变化。不过，通过实现多种启发式方法（这些方法已知在所有过去的Windows NT版本中有效，例如对 `ntdll` 的 `Zw*` 导出进行排序，在相关的 `ntdll` 函数中搜索 `mov rax, #syscall_number` 指令等），并检查它们是否返回相同的结果（详见 `Syscalls.c`），可以缓解此问题。

此外，技术上不属于系统调用的函数（例如 `LoadLibraryX`/`LdrLoadDLL`）也可能被监控，并且不能简单地通过系统调用来重新实现。

直接系统调用技术在EDRSandblast中已实现。如前所述，它仅用于安全地执行 `NtProtectVirtualMemory`，并移除所有检测到的钩子。

有关实现细节，请查看 `unhook()` 函数中 `unhook_method` 为 `UNHOOK_WITH_DIRECT_SYSCALL` 时的代码路径。

### 利用脆弱驱动程序
如前所述，每个需要内核内存读写操作的行为都依赖于一个脆弱的驱动程序来提供这一原语。在EDRSandblast中，添加对提供读写原语的新驱动程序的支持可以“轻松”完成，只需实现三个函数：
* 一个 `ReadMemoryPrimitive_DRIVERNAME(SIZE_T Size, DWORD64 Address, PVOID Buffer)` 函数，将 `Size` 字节从内核地址 `Address` 复制到用户态缓冲区 `Buffer`；
* 一个 `WriteMemoryPrimitive_DRIVERNAME(SIZE_T Size, DWORD64 Address, PVOID Buffer)` 函数，将 `Size` 字节从用户态缓冲区 `Buffer` 复制到内核地址 `Address`；
* 一个 `CloseDriverHandle_DRIVERNAME()` 函数，确保所有指向该驱动程序的句柄都被关闭（在卸载操作前需要，该操作目前与驱动程序无关）。

例如，EDRSandblast目前支持两个驱动程序：`RTCore64.sys`（SHA256: `01AA278B07B58DC46C84BD0B1B5C8E9EE4E62EA0BF7A695862444AF32E87F1FD`）和 `DBUtils_2_3.sys`（SHA256: `0296e2ce999e67c76352613a718e11516fe1b0efc3ffdb8918fc999dd76a73a5`）。如果使用的脆弱驱动程序需要更改，或者实现了新的驱动程序，则需要更新 `KernelMemoryPrimitives.h` 中的以下代码。```C
#define RTCore 0
#define DBUtil 1
// Select the driver to use with the following #define
#define VULN_DRIVER RTCore

#if VULN_DRIVER == RTCore
#define DEFAULT_DRIVER_FILE TEXT("RTCore64.sys")
#define CloseDriverHandle CloseDriverHandle_RTCore
#define ReadMemoryPrimitive ReadMemoryPrimitive_RTCore
#define WriteMemoryPrimitive WriteMemoryPrimitive_RTCore
#elif VULN_DRIVER == DBUtil
#define DEFAULT_DRIVER_FILE TEXT("DBUtil_2_3.sys")
#define CloseDriverHandle CloseDriverHandle_DBUtil
#define ReadMemoryPrimitive ReadMemoryPrimitive_DBUtil
#define WriteMemoryPrimitive WriteMemoryPrimitive_DBUtil
#endif

### 选项```
-h | --help             Show this help message and exit.
-v | --verbose          Enable a more verbose output.

Actions mode:

        audit                     Display the user-land hooks and / or Kernel callbacks without taking actions.
        dump                      Dump the process specified by --process-name (LSASS process by default), as '<process_name>' in the current directory or at the
                                  specified file using -o | --output <DUMP_FILE>.
        cmd                       Open a cmd.exe prompt.
        credguard                 Patch the LSASS process' memory to enable Wdigest cleartext passwords caching even if
                                  Credential Guard is enabled on the host. No kernel-land actions required.
        firewall                  Add Windows firewall rules to block network access for the EDR processes / services.
        load_unsigned_driver      Load the specified unsigned driver, bypassing Driver Signature Enforcement (DSE).
                                  WARNING: currently an experimental feature, only works if KDP is not present and enabled.

--usermode              Perform user-land operations (DLL unhooking).
--kernelmode            Perform kernel-land operations (Kernel callbacks removal and ETW TI disabling).


Hooking-related options:

--add-dll <dll name or path>            Loads arbitrary libraries into the process' address space, before starting
                                        anything.This can be useful to audit userland hooking for DLL that are not
                                        loaded by default by this program. Use this option multiple times to load
                                        multiple DLLs all at once.
                                        Example of interesting DLLs to look at: user32.dll, ole32.dll, crypt32.dll,
                                        samcli.dll, winhttp.dll, urlmon.dll, secur32.dll, shell32.dll...

--unhook-method <N>                     Choose the userland un-hooking technique, from the following:

        0                               Do not perform any unhooking (used for direct syscalls operations).
        1 (Default)                     Uses the (probably monitored) NtProtectVirtualMemory function in ntdll to remove all
                                        present userland hooks.
        2                               Constructs a 'unhooked' (i.e. unmonitored) version of NtProtectVirtualMemory, by                                        allocating an executable trampoline jumping over the hook, and remove all present
                                        userland hooks.
        3                               Searches for an existing trampoline allocated by the EDR itself, to get an 'unhooked'
                                        (i.e. unmonitored) version of NtProtectVirtualMemory, and remove all present userland
                                        hooks.
        4                               Loads an additional version of ntdll library into memory, and use the (hopefully                                        unmonitored) version of NtProtectVirtualMemory present in this library to remove all
                                        present userland hooks.
        5                               Allocates a shellcode that uses a direct syscall to call NtProtectVirtualMemory,                                        and uses it to remove all detected hooks

--direct-syscalls       Use direct syscalls to dump the selected process memory without unhooking unserland hooks.


BYOVD options:

--dont-unload-driver                    Keep the vulnerable driver installed on the host
                                        Default to automatically unsinstall the driver.
--no-restore                            Do not restore the EDR drivers' Kernel Callbacks that were removed.
                                        Default to restore the callbacks.
--vuln-driver <gdrv.sys>                Path to the vulnerable driver file.
                                        Default to 'gdrv.sys' in the current directory.
--vuln-service <SERVICE_NAME>           Name of the vulnerable service to intall / start.


Driver sideloading options:

--unsigned-driver <evil.sys>            Path to the unsigned driver file.
                                        Default to 'evil.sys' in the current directory.
--unsigned-service <SERVICE_NAME>       Name of the unsigned driver's service to intall / start.
--no-kdp                                Switch to g_CiOptions patching method for disabling DSE (default is callback swapping).


Offset-related options:

--nt-offsets <NtoskrnlOffsets.csv>      Path to the CSV file containing the required ntoskrnl.exe's offsets.
                                        Default to 'NtoskrnlOffsets.csv' in the current directory.
--fltmgr-offsets <FltmgrOffsets.csv>    Path to the CSV file containing the required fltmgr.sys's offsets
                                        Default to 'FltmgrOffsets.csv' in the current directory.
--wdigest-offsets <WdigestOffsets.csv>  Path to the CSV file containing the required wdigest.dll's offsets
                                        (only for the 'credguard' mode).
                                        Default to 'WdigestOffsets.csv' in the current directory.
--ci-offsets <CiOffsets.csv>            Path to the CSV file containing the required ci.dll's offsets
                                        (only for the 'load_unsigned_driver' mode).
                                        Default to 'WdigestOffsets.csv' in the current directory.
-i | --internet                         Enables automatic symbols download from Microsoft Symbol Server
                                        If a corresponding *Offsets.csv file exists, appends the downloaded offsets to the file for later use
                                        OpSec warning: downloads and drops on disk a PDB file for the corresponding image

Dump options:

-o | --dump-output <DUMP_FILE>          Output path to the dump file that will be generated by the 'dump' mode.
                                        Default to 'process_name' in the current directory.
--process-name <NAME>                   File name of the process to dump (defaults to 'lsass.exe')

## 检测

从防御方（EDR供应商、Microsoft、SOC分析师查看EDR遥测数据等）的角度来看，可以使用多种指标来检测或防止这类技术。

### 驱动程序白名单

由于该工具在内核模式内存中执行的每项操作都依赖于一个存在漏洞的驱动程序来读写任意内容，因此EDR产品（或SOC分析师）应严格审查驱动程序加载事件，并对任何不常见的驱动程序加载发出警报，甚至直接阻止已知的易受攻击驱动程序。后一种做法甚至受到[微软自身的推荐](https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-driver-block-rules)：任何启用了HVCI（*基于虚拟机监控程序的代码完整性*）的Windows设备都内嵌了驱动程序黑名单，这将成为Windows的默认行为（在Windows 11上已是如此）。

### 内核内存完整性检查

即使攻击者仍可能使用未知的易受攻击驱动程序在内存中执行相同操作，EDR驱动程序也可以定期检查其内核回调是否仍然注册——可以直接通过检查内核内存（就像本工具所做的那样），或者简单地通过触发事件（进程创建、线程创建、镜像加载等）并检查这些回调函数是否确实被执行内核调用。

顺便提一下，这类数据结构可以通过最近的[内核数据保护（KDP）](https://www.microsoft.com/security/blog/2020/07/08/introducing-kernel-data-protection-a-new-platform-security-technology-for-preventing-data-corruption/)机制来保护，该机制基于虚拟化安全，使得内核回调数组在不调用正确API的情况下不可写。

同样的逻辑也适用于敏感的ETW变量，例如本工具滥用的 `ProviderEnableInfo`，用于禁用ETW威胁智能事件生成。

### 用户态检测

进程试图主动规避用户态挂钩的第一个迹象是对应已加载模块的每个DLL的文件访问；在正常执行中，用户态进程很少需要在 `LoadLibrary` 调用之外读取DLL文件，尤其是 `ntdll.dll`。

为了保护API挂钩不被绕过，EDR产品可以定期检查每个被监控进程的内存中挂钩是否未被篡改。

最后，为了检测不涉及删除挂钩的挂钩绕过（滥用跳板、直接系统调用等），EDR产品可以依赖于与被滥用系统调用关联的内核回调（例如 `NtCreateProcess` 系统调用的 `PsCreateProcessNotifyRoutine`，`NtOpenProcess` 系统调用的 `ObRegisterCallbacks` 等），并执行用户态调用栈分析，以确定系统调用是从正常路径（`kernel32.dll` -> `ntdll.dll` -> 系统调用）触发，还是从异常路径（例如 `program.exe` -> 直接系统调用）触发。

## 致谢

- 内核回调枚举与移除：
  https://github.com/br-sn/CheekyBlinder

- 通过易受攻击的`Micro-Star MSI Afterburner`驱动程序实现内核内存读/写原语：
  https://github.com/Barakat/CVE-2019-16098/

- 禁用ETW威胁智能提供程序：
  https://public.cnotools.studio/bring-your-own-vulnerable-kernel-driver-byovkd/exploits/data-only-attack-neutralizing-etwti-provider

- 驱动程序安装/卸载：https://github.com/gentilkiwi/mimikatz

- EDR驱动程序名称的初始列表：
  https://github.com/SadProcessor/SomeStuff/blob/master/Invoke-EDRCheck.ps1

- 通过LSASS内存修补重新启用Wdigest绕过Credential Guard：
  https://teamhydra.blog/2020/08/25/bypassing-credential-guard/

## 作者

[Thomas DIOT (Qazeer)](https://github.com/Qazeer/)
[Maxime MEIGNAN (themaks)](https://github.com/themaks)

## 感谢贡献者
- [v1k1ngfr](https://github.com/v1k1ngfr)：用于驱动程序签名强制绕过（通过 `g_CiOptions` 修补）和GDRV.sys驱动程序支持
- [Windy Bug](https://github.com/0mWindyBug)：用于兼容KDP的驱动程序签名强制绕过（通过回调交换）以及对微过滤绕过功能的重大贡献

## 许可证

CC BY 4.0 许可证 - https://creativecommons.org/licenses/by/4.0/