摘要
Windows 受保护进程轻量级是微软自 Windows 8.1 以来构建的核心安全边界，通过基于数字签名的层级信任模型阻止恶意代码篡改反恶意软件和端点安全产品。本文从 PPL 信任层级架构出发，逐层拆解 ClipUp 提权与 EDR-Freeze 竞态条件的技术原理，将 BYOVD 与 PPL 滥用合二为一的融合攻击链，并讨论跨 PPL 等级的内存转储攻击面及检测盲区。
PPL信任边界
Windows Vista 首次引入了受保护进程模型：进程要么受保护，要么不受保护。该模型过于二元化，无法适应实际安全需求。从 Windows 8.1 开始，微软引入 PPL 扩展了这一概念，引入了保护级别层级，使得某些受保护进程比另一些更受保护，且定义了一个根本性原则：不受保护的进程只能使用受限的访问标志集（如 PROCESS_QUERY_LIMITED_INFORMATION）打开受保护的进程，若请求更高访问权限则返回拒绝访问错误。
对于 PP/PPL 进程而言，其可请求的访问权限取决于自身的保护级别，该级别部分由文件数字证书中的特殊增强密钥使用字段决定。进程创建时，保护信息存入 EPROCESS 内核结构中的特定字段，存储着保护级别（PP 或 PPL）以及签名者类型（如反恶意软件、LSA、WinTcb 等）。
签名者类型在 PP/PPL 之间构建了严格层级：
若 PP 的签名者类型高于或等于目标 PP/PPL，则可以完整访问目标进程 若 PPL 的签名者类型高于或等于目标 PPL，则可以完整访问目标进程 PPL 无法以完整访问权限打开 PP，无论前者使用何种签名者类型
PPL 的签名者类型构成了四条明确的信任等级，每一层都有其典型代表进程和关键特权：
| WinTcb-Light | ||||
| Antimalware-Light | ||||
| Lsa-Light | ||||
| Windows-Light |
我们可以编写以下代码查询进程的 PPL 保护级别：
// ppl_check.c
// 编译: cl ppl_check.c /link psapi.lib
#include <windows.h>
#include <winternl.h>
#include <stdio.h>
#include <psapi.h>
// 未公开的 PROCESSINFOCLASS 枚举值
#define ProcessProtectionLevelInfo 0x3F
typedef struct _PROCESS_PROTECTION_LEVEL_INFORMATION {
DWORD ProtectionLevel;
} PROCESS_PROTECTION_LEVEL_INFORMATION;
// 解析签名者类型
const char* GetSignerType(DWORD level) {
DWORD signer = (level >> 4) & 0xF;
switch (signer) {
case 0: return"None";
case 1: return"Windows";
case 2: return"Lsa";
case 3: return"Antimalware";
case 4: return"WinTcb";
case 5: return"WinSystem";
default: return"Unknown";
}
}
// 解析保护类型
const char* GetProtectionType(DWORD level) {
DWORD type = level & 0xF;
switch (type) {
case 0: return"None";
case 1: return"Protected Light (PPL)";
case 2: return"Protected (PP)";
default: return"Unknown";
}
}
void CheckProcessProtection(DWORD pid) {
HANDLE hProcess = OpenProcess(
PROCESS_QUERY_LIMITED_INFORMATION, FALSE, pid);
if (!hProcess) {
printf("[-] 无法打开进程 PID %d (错误: %d)\n", pid, GetLastError());
return;
}
PROCESS_PROTECTION_LEVEL_INFORMATION protInfo = {0};
ULONG returnLength = 0;
NTSTATUS status = NtQueryInformationProcess(
hProcess,
ProcessProtectionLevelInfo,
&protInfo,
sizeof(protInfo),
&returnLength
);
CloseHandle(hProcess);
if (NT_SUCCESS(status)) {
printf("[*] PID %d | 保护类型: %s | 签名者: %s (Level: 0x%X)\n",
pid,
GetProtectionType(protInfo.ProtectionLevel),
GetSignerType(protInfo.ProtectionLevel),
protInfo.ProtectionLevel);
} else {
printf("[-] NtQueryInformationProcess 失败 (NTSTATUS: 0x%X)\n", status);
}
}
int main(int argc, char* argv[]) {
if (argc < 2) {
printf("用法: ppl_check.exe <PID>\n");
printf("示例: ppl_check.exe 1234\n");
return 1;
}
CheckProcessProtection(atoi(argv[1]));
return 0;
}理解PP/L模型的原始设计逻辑是理解后续所有绕过技术的关键。PP/L模型的初衷是防止不受保护的进程使用 OpenProcess 等标准 API 以扩展访问权限访问受保护进程，建立了基于签名者类型的“信任等级”机制。较高信任等级的进程可以自由访问较低等级的进程，反之则不行。
设计之初，PPL被赋予了超出其实际实现能力的安全期望。签名的密码学意义在于验证文件的来源和完整性——它回答的问题是“这个二进制确实由声称的发行者发布且在签名后未被篡改”。但 Windows 内核加载机制将这一密码学保证等同于“该进程可以在受保护上下文中执行”，在信任传递过程中制造了一个巨大的语义鸿沟。当攻击者找到一个签名为 WinTcb 级别的合法二进制，并将其武器化，整个信任层级就会从内部崩塌。
PPL 滥用的三条技术路径
Windows 错误报告系统中的竞态条件
Zero Salarium 安全研究员在 2025 年 8 月首次公布了一项颠覆性的发现：可以通过滥用 WerFaultSecure.exe（Windows 错误报告系统的关键组件）来绕过 PPL 保护。2025 年 9 月，研究员进一步发布了名为 EDR-Freeze 的工具，将这一发现产品化，证明了即使不需要 BYOVD 驱动，纯用户态代码也足以冻结 EDR 进程。
下载地址：
https://github.com/TwoSevenOneT/EDR-Freeze
MiniDumpWriteDump 的原始用途是崩溃转储调试——它会对目标进程进行快照，但为确保内存状态的一致性，它会在转储前挂起目标进程的所有线程。如研究员所述：“来自 Windows DbgHelp 库的 MiniDumpWriteDump 函数用于创建进程的 minidump……但关键之处在于：在转储过程中，它会挂起目标进程中的所有线程。”
而 WerFaultSecure.exe 是 WER 框架的核心组件，以最高 WinTcb PPL 标签运行，专门收集来自受保护进程（如 LSASS）的崩溃转储。攻击者若能将两者组合，便可在受保护的安全进程上触发 MiniDumpWriteDump，使其线程被挂起。
EDR-Freeze 的攻击流程需要极为精确的时序控制：
使用 CreateProcessAsPPL工具以 WinTCB PPL 级别启动WerFaultSecure.exe目标指向杀毒软件或 EDR 进程（例如 MsMpEng.exe）WerFaultSecure在转储过程中会调用MiniDumpWriteDump，将目标进程的所有线程挂起攻击者在目标进程完全挂起后，立即挂起 WerFaultSecure.exe自身由于 WerFaultSecure被暂停，目标安全进程的线程无法恢复，永久冻结攻击者获得一段无安全监控的窗口期，可执行后续恶意操作
如果我们能让 WerFaultSecure 执行转储过程，然后在对杀毒软件进程调用 MiniDumpWriteDump 的同时，在它让目标进程进入挂起状态的那一刻立即挂起 WerFaultSecure，那么目标程序将无限期地挂起。
在测试中，EDR-Freeze 在完全更新的 Windows 11 24H2 系统上成功挂起了 MsMpEng.exe 长达 5 秒，足以让攻击者完成关键操作。由于 WerFaultSecure 是 Windows 自带的可信二进制文件，且 PPL 上下文使其行为被视为合法，传统安全产品难以检测到异常——这是一条完全在安全产品信任范围之内的攻击路径。
ClipUp.exe 执行
ClipUp.exe——位于 System32 目录下的合法微软签名二进制。它被设定为以 PPL 权限运行，原本功能是处理剪贴板相关操作。但当在特定条件下以特定参数启动 ClipUp.exe 时，该程序会加载并执行来自非标准路径的 DLL，在 PPL 保护上下文内执行攻击者代码。
ClipUp 执行的关键在于：通过在 PPL 上下文中运行，攻击者可以执行以下在普通用户态下不可能的操作：
修改受保护进程（如 MsMpEng.exe）的内存内容覆盖或删除 Defender 关键文件——因为 PPL 上下文授予了标准管理员权限无法获得的文件系统操作权限 修改与 Defender 相关的注册表项
我们可以根据以下检测ClipUp.exe 注册表是否纂改：
title: 通过 ClipUp.exe 服务 ImagePath 修改实现 Defender 规避
id: ae8f85a3-c3e8-4d1f-9a51-2b3fba56d1c1
status: stable
description: |
检测将服务 ImagePath 修改为执行 ClipUp.exe 的注册表修改行为。
攻击者利用 ClipUp.exe 的 PPL 保护权限替换 Windows Defender
服务可执行文件，在服务初始化前绕过安全保护。
此技术由 Elastic Security Labs 在对 RONINGLOADER 的分析中发现，
并已被应用于 Dragon Breath APT 的实际攻击活动中。
author: Swachchhanda Shrawan Poudel (Nextron Systems)
date: 2026-01-29
modified: 2026-01-29
tags:
- attack.defense-impairment
- attack.privilege-escalation
- attack.t1685 # Service ImagePath Tampering
- attack.t1068 # Exploitation for Privilege Escalation
logsource:
product: windows
category: registry_event
detection:
selection:
EventID: 13
TargetObject|contains: '\SYSTEM\CurrentControlSet\Services\'
TargetObject|endswith: '\ImagePath'
Details|contains|all:
- 'ClipUp.exe'
- '-p'# ClipUp PPL 参数
- '-o'# 输出/操作路径参数
# 排除 Windows Defender 的正常更新操作
filter_defender_update:
TargetObject|contains:
- '\WinDefend\'
- '\WdFilter\'
Details|contains: '\Program Files\Windows Defender\'
condition: selection and not filter_defender_update
falsepositives:
- 合法的系统维护脚本
- 安全研究员的授权测试
level: high受困 COM 对象
这是一种通过操控 DCOM 远程技术中按引用封送的对象指针，在服务端 DCOM 进程上下文中执行任意 .NET 托管代码的方法。
IBM X-Force 安全研究员 Mohamed Fakroud 和 Jimmy Bayne 基于此开发了概念验证实现，并扩展为文件无痕横向移动攻击方法。
下载地址：
https://github.com/T3nb3w/ComDotNetExploit
Forshaw 的博客描述了一种具体的 PPL 绕过用例：通过操控 WaaSRemediation COM 类暴露的 IDispatch 接口，实现受困 COM 对象滥用与 .NET 代码执行。WaaSRemediation 在 WaaSMedicSvc 服务中实现，以 NT AUTHORITY\SYSTEM 和 PPL 保护身份运行。
下载地址：
https://github.com/xforcered/ForsHops
攻击的核心原理在于 COM 对象的后期绑定机制。IDispatch 接口允许客户端在运行时动态发现并调用对象方法，通过 ITypeInfo 和 ITypeLib 接口解析类型信息。攻击者通过构造恶意的 ITypeLib 引用，可以诱导 WaaSMedicSvc 服务加载攻击者控制的 .NET 程序集。
四阶段攻击体系
在真实环境中的攻击复杂度远超理论攻击，我们可以将一条攻击链集成四种独立的 PPL 绕过方法：
第一阶段：BYOVD 驱动级进程终止。利用合法签名内核驱动，注册一个单一函数，通过 IOCTL 接口接收目标进程 ID，使用内核级 API（ZwTerminateProcess）终止该进程——绕过所有用户态保护机制，包括 PPL。
第二阶段：EDR-Freeze 竞态条件攻击。在 BYOVD 驱动终止主要安全进程后，使用 WerFaultSecure.exe 竞态条件技术冻结残留的 Defender 组件。
第三阶段：ClipUp.exe PPL 代理。利用 PPL 保护的 ClipUp.exe 二进制作为代理，篡改 Defender 二进制文件。由于 ClipUp.exe 本身运行在 PPL 上下文中，其行为对安全产品是不透明的——这是 PPL 信任层级的结构性缺陷。
第四阶段：自定义 WDAC 策略部署。在 Defender 被禁用后，加载器进一步部署未签名的 Windows Defender 应用程序控制策略，专门阻止杀软可执行文件启动，形成“安全真空”。
初步清理完成后，攻击者就可以通过创建恶意服务、监控受信系统进程以及在进程被终止时重新注入组件来建立持久化。
进程终止机制值得注意的是，针对不同的安全产品，我们可以采用定制化的策略。对于微软 Defender、金山毒霸、腾讯电脑管家等大多数安全产品，直接将驱动写入磁盘，创建临时服务加载驱动，完成进程终止后立即停止并删除服务。而针对 360 Total Security，可以额外通过防火墙规则阻止其所有网络通信，将 shellcode 注入到 VSS 服务进程（vssvc.exe），使用 PoolParty 技术（线程池注入）进一步注入恶意代码。
为何 PPL 难以修复
“信任锚点”被武器化
PPL 的根本结构性缺陷在于其信任模型的循环论证逻辑：进程因签名而被信任；合法进程因受信任而被授予对安全进程的特殊访问权限；但这种访问权限本不应被恶意调用。问题不在于签名的密码学强度，而在于签名验证没有区分“设计用途”与“被滥用用途”。
WerFaultSecure.exe 的设计意图是收集崩溃转储以帮助微软诊断系统稳定性问题。它需要 WinTcb 级别权限来访问受保护进程的内存，这是完全合理的。但当攻击者在竞态条件中将其用作安全进程的冻结器，二进制文件的功能就从“诊断辅助”变成了“安全拆除工具”——而其签名和权限没有丝毫变化。
同样的逻辑适用于 ClipUp.exe。它的设计意图是处理剪贴板操作，需要 PPL 权限来访问系统敏感资源。但当攻击者以特定参数启动它，它加载的 DLL 和执行的代码就完全脱离了原始设计范围。ClipUp 的签名并未定义它可以加载什么、执行什么，它只是被标注为“可信”——而这正是信任被武器化的入口。
检测的根源性困境
安全产品面临一个结构性难题：如何检测一个在系统信任层级中比自己更高或同等的进程在“滥用”其特权？PPL 反恶意软件进程有能力检测和阻止用户态恶意代码，但当恶意代码运行在同等甚至更高 PPL 级别的上下文中，一切监测逻辑都失效了。
EDR 的自我防护机制——包括 PPL 保护、防篡改、和进程自我保护——在这个攻击模型下被结构性绕过。攻击者不需要直接攻击安全产品，他们只需要找到一种方法，以合法的 PPL 上下文执行操作，而这些操作恰好具有破坏安全产品的能力。
防御体系的缺口
当前防御体系中，针对 PPL 滥用的检测手段严重匮乏。
更根本的挑战在于：Windows 操作系统本身缺乏对“PPL 特权滥用”的内置审计机制。当 WerFaultSecure.exe 被用于调试一个安全进程，Windows 不会记录这一行为为“可疑”，因为从操作系统的视角看，这是一个 WinTcb 级别的可信进程在执行其设计功能。这种信任惯性使得滥用行为在操作系统中完全隐形。
总结
2026年，微软已开始推出针对交叉签名根程序签发驱动程序的信任移除政策，但这一措施主要针对 BYOVD 层面，并未涉及 PPL 信任模型的根本缺陷。只要 Windows 继续将数字签名等用于信任等价物，只要 WinTcb 级别的二进制文件可以被用户态调用，PPL 滥用技术的生命周期就远未结束。
对防御方而言，检测 PPL 滥用需要从行为监控而非静态信任入手：监控 WerFaultSecure.exe 的异常启动参数（指向安全进程或 LSASS 的 PID）、检测从非标准路径加载 DLL 的 PPL 保护进程、识别对 Defender 二进制文件或注册表项的 PPL 上下文修改。同时，WDAC 策略应配置为阻止已知的易受攻击驱动程序加载，并限制哪些用户账户可以创建内核服务——这些基础防御措施虽不能从根本上解决 PPL 滥用问题，但能显著提高攻击成本。