Windows 受保护进程轻量级滥用技术分析与攻击链建模

摘要

Windows 受保护进程轻量级（PPL）是微软自 Windows 8.1 起构建的核心安全边界，通过基于数字签名的层级信任模型防止恶意代码篡改反恶意软件与端点安全产品。然而，PPL 的设计将密码学签名验证等同于运行时行为可信，形成结构性信任锚点缺陷。本文以三类独立 PPL 滥用技术——WerFaultSecure 竞态条件、ClipUp 二进制代理执行及 WaaSRemediation COM 对象操控——为分析对象，拆解其技术原理，构建集 BYOVD、竞态冻结、PPL 代理与 WDAC 策略部署于一体的四阶段融合攻击链，并讨论当前防御体系中的检测盲区与结构性修复瓶颈。

关键词：Windows PPL；受保护进程；EDR 绕过；信任模型；BVOVD

1. 引言

Windows Vista 首次引入受保护进程（PP）模型，进程状态被二分为受保护与不受保护两类。该过于简化的设计无法适应实际安全需求。Windows 8.1 起引入的 PPL 扩展了该概念，通过签名者类型（Signer Type）建立多级信任层级，使不同受保护进程之间具备差异化的访问权限。

设计之初，PPL 被赋予了超出其实际实现能力的安全期望。数字签名的密码学意义在于验证二进制文件的来源与完整性，它回答的是"该文件确实由声称的发行者发布且未被篡改"。然而，Windows 内核加载机制将这一密码学保证直接等同于"该进程可在受保护上下文中执行"，在信任传递过程中制造了语义鸿沟。当攻击者寻找到签名为 WinTcb 层级的合法二进制并将其武器化，整个信任层级便从内部崩塌。

2. PPL 信任层级架构

2.1 保护级别与签名者类型

PP/PPL 进程可请求的访问权限取决于自身的保护级别，该级别部分由文件数字证书中的增强密钥使用（EKU）字段决定。进程创建时，保护信息存入 EPROCESS 内核结构，存储内容包含保护类型（PP 或 PPL）及签名者类型。

签名者类型在 PP/PPL 之间构建了严格层级：

• 若 PP 的签名者类型高于或等于目标 PP/PPL，则可完整访问目标进程
• 若 PPL 的签名者类型高于或等于目标 PPL，则可完整访问目标进程
• PPL 无法以完整访问权限打开 PP，无论前者使用何种签名者类型

PPL 的签名者类型构成四条明确的信任等级：

保护层级	签名者类型	典型进程	关键特权	可访问对象
WinTcb-Light	WinTcb (4)	smss.exe, csrss.exe, WerFaultSecure.exe	最高 PPL 权限	所有 PP/PPL
Antimalware-Light	Antimalware (3)	MsMpEng.exe, Windefend	可终止大多数安全进程	WinTcb 以下
Lsa-Light	Lsa (2)	lsass.exe	可访问 Lsa 及以下	Lsa-Light 及以下
Windows-Light	Windows (1)	winlogon.exe, svchost.exe	基础 PPL 保护	仅自身等级

2.2 保护级别查询

以下代码通过未公开的 ProcessProtectionLevelInfo 枚举值（0x3F）查询进程的 PPL 保护级别：

// ppl_check.c
// 编译: cl ppl_check.c /link psapi.lib

#include <windows.h>
#include <winternl.h>
#include <stdio.h>
#include <psapi.h>

#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\n", pid);
        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 (0x%X)\n",
            pid, GetProtectionType(protInfo.ProtectionLevel),
            GetSignerType(protInfo.ProtectionLevel),
            protInfo.ProtectionLevel);
    }
}

3. PPL 滥用技术分类分析

3.1 基于竞态条件的进程冻结：EDR-Freeze

2025 年 8 月，Zero Salarium 安全研究员首次披露了通过滥用 WerFaultSecure.exe 绕过 PPL 的技术。2025 年 9 月，该技术被封装为 EDR-Freeze 工具发布，证明纯用户态代码即可冻结 EDR 进程，无需 BYOVD 驱动。

攻击原理利用了 Windows 错误报告（WER）框架中 MiniDumpWriteDump 函数的副作用。该函数来自 DbgHelp 库，用于创建进程崩溃转储。为确保内存状态一致性，它在转储前会挂起目标进程的所有线程。WerFaultSecure.exe 以最高 WinTcb PPL 标签运行，专门收集受保护进程的崩溃转储。攻击者将两者组合，可在安全进程上触发 MiniDumpWriteDump，使其线程被挂起。

攻击流程要求精确的时序控制：

1. 使用 CreateProcessAsPPL 以 WinTcb PPL 级别启动 WerFaultSecure.exe
2. 将目标指向杀毒软件或 EDR 进程（如 MsMpEng.exe）
3. WerFaultSecure 调用 MiniDumpWriteDump 挂起目标所有线程
4. 攻击者在目标进程挂起后立即挂起 WerFaultSecure.exe 自身
5. WerFaultSecure 被暂停后目标安全进程线程无法恢复，永久冻结
6. 攻击者获得无安全监控的窗口期

在测试中，EDR-Freeze 在完全更新的 Windows 11 24H2 系统上成功挂起 MsMpEng.exe 长达 5 秒。由于 WerFaultSecure 是 Windows 自带的可信二进制且运行在 PPL 上下文中，其行为对安全产品而言完全透明。

3.2 基于二进制代理的权限劫持：ClipUp.exe

ClipUp.exe 位于 System32 目录，是微软签名的合法二进制，以 PPL 权限运行，原本功能为处理剪贴板相关操作。当在特定条件下以特定参数启动时，该程序会加载并执行来自非标准路径的 DLL，在 PPL 保护上下文内执行攻击者代码。

通过 PPL 上下文的代理执行，攻击者可实现普通用户态下不可能的操作，包括修改受保护进程内存、覆盖或删除 Defender 关键文件，以及修改相关注册表项。Elastic Security Labs 在对 RONINGLOADER 的分析中发现了该技术，并确认其已被 Dragon Breath APT 用于实际攻击活动。

以下 Sigma 规则可用于检测针对 ClipUp.exe 的注册表篡改行为：

title: ClipUp.exe 服务 ImagePath 篡改检测
id: ae8f85a3-c3e8-4d1f-9a51-2b3fba56d1c1
status: stable
description: 检测将服务 ImagePath 修改为执行 ClipUp.exe 的注册表行为
author: Swachchhanda Shrawan Poudel (Nextron Systems)
date: 2026-01-29
tags:
  - attack.defense-impairment
  - attack.privilege-escalation
  - attack.t1685
  - attack.t1068
logsource:
  product: windows
  category: registry_event
detection:
  selection:
    EventID: 13
    TargetObject|contains: '\SYSTEM\CurrentControlSet\Services\'
    TargetObject|endswith: '\ImagePath'
    Details|contains|all:
      - 'ClipUp.exe'
      - '-p'
      - '-o'
  filter_defender_update:
    TargetObject|contains:
      - '\WinDefend\'
      - '\WdFilter\'
    Details|contains: '\Program Files\Windows Defender\'
  condition: selection and not filter_defender_update
level: high

3.3 基于 COM 接口操控的代码执行：WaaSRemediation

IBM X-Force 安全研究员 Mohamed Fakroud 与 Jimmy Bayne 发现了一种通过操控 DCOM 远程技术中按引用封送的对象指针，在服务端 DCOM 进程上下文中执行任意 .NET 托管代码的方法。

该技术的关键利用对象是 WaaSRemediation COM 类及其暴露的 IDispatch 接口。WaaSRemediation 在 WaaSMedicSvc 服务中实现，该服务以 NT AUTHORITY\SYSTEM 身份且附带 PPL 保护运行。攻击的核心在于 COM 对象的后期绑定机制：IDispatch 接口允许客户端在运行时动态发现并调用对象方法，通过 ITypeInfo 和 ITypeLib 接口解析类型信息。攻击者通过构造恶意的 ITypeLib 引用，可诱导 WaaSMedicSvc 服务加载攻击者控制的 .NET 程序集。

Forshaw 的研究进一步描述了具体 PPL 绕过用例：通过操控 WaaSRemediation COM 类暴露的 IDispatch 接口，实现受困 COM 对象滥用与 .NET 代码执行。

4. 融合攻击链模型

在实际攻击环境中，单独使用上述任意一种技术都难以实现完整攻击目标。本节构建一条集成四阶段攻击链：

第一阶段：BYOVD 驱动级进程终止。 利用合法签名内核驱动注册单一函数，通过 IOCTL 接口接收目标进程 ID，使用 ZwTerminateProcess 在核心态终止目标进程，绕过包括 PPL 在内的所有用户态保护机制。针对不同安全产品可采用定制化策略：对 Defender、金山毒霸等直接加载驱动终止进程；对 360 Total Security 额外通过防火墙规则阻断其网络通信，并将 shellcode 注入 VSS 服务进程。

第二阶段：EDR-Freeze 竞态条件冻结。 BYOVD 驱动终止主要安全进程后，利用 WerFaultSecure.exe 竞态条件冻结残留的 Defender 组件，防止其恢复或上报异常状态。

第三阶段：ClipUp.exe PPL 代理篡改。 利用 PPL 保护的 ClipUp.exe 作为代理，篡改 Defender 二进制文件及注册表项。由于 ClipUp.exe 运行在 PPL 上下文中，其文件系统操作对安全产品不透明。

第四阶段：自定义 WDAC 策略部署。 Defender 被禁用后部署未签名的 Windows Defender 应用程序控制策略，专门阻止杀软可执行文件启动，形成持续性的安全真空。

完成清理后，攻击者通过创建恶意服务、监控受信系统进程、在进程被终止时重新注入组件等手段建立持久化。

5. PPL 模型的结构性缺陷

5.1 信任锚点武器化

PPL 的根本缺陷在于其信任模型的循环论证：进程因签名而被信任；合法进程因受信任而被授予对安全进程的特殊访问权限。问题不在于签名的密码学强度，而在于签名验证未区分设计用途与被滥用用途。

WerFaultSecure.exe 设计意图是收集崩溃转储以诊断系统稳定性问题，需要 WinTcb 权限访问受保护进程内存——这是合理需求。但当攻击者在竞态条件中将其用作安全进程冻结器，该二进制文件的功能从诊断辅助变为安全拆除工具，而其签名和权限没有发生变化。同样的逻辑适用于 ClipUp.exe，其设计意图是处理剪贴板操作，但当攻击者以特定参数启动时，其加载的 DLL 和执行代码完全脱离了原始设计范围。

5.2 防御体系的检测盲区

安全产品面临结构性难题：如何检测一个在系统信任层级中比自己更高或同等的进程在滥用其特权？PPL 反恶意软件进程有能力检测和阻止用户态恶意代码，但当恶意代码运行在同等甚至更高 PPL 级别的上下文中，监测逻辑即告失效。

EDR 的自我防护机制——包括 PPL 保护、防篡改和进程自我保护——在此攻击模型下被结构性绕过。攻击者不需要直接攻击安全产品，只需找到以合法 PPL 上下文执行操作的方法，而这些操作恰好具备破坏安全产品的能力。

更深层的挑战在于：Windows 操作系统本身缺乏对 PPL 特权滥用的内置审计机制。当 WerFaultSecure.exe 被用于调试安全进程时，Windows 不会记录该行为为可疑，因为从操作系统视角看，这是 WinTcb 可信进程在执行设计功能。

6. 检测与缓解策略

针对 PPL 滥用的检测需要从静态信任转向行为监控：

• 监控 WerFaultSecure.exe 的异常启动参数，特别是指向安全进程或 LSASS 的 PID
• 检测从非标准路径加载 DLL 的 PPL 保护进程
• 识别对 Defender 二进制文件或注册表项的 PPL 上下文修改
• 部署 WDAC 策略阻止已知易受攻击驱动加载
• 限制可创建内核服务的用户账户

2026 年，微软已开始推行针对交叉签名根程序签发驱动程序的信任移除政策，但这一措施主要作用于 BYOVD 层面，未触及 PPL 信任模型的根本缺陷。只要 Windows 将继续数字签名等同于运行期信任，只要 WinTcb 层级二进制可被用户态调用，PPL 滥用技术的生命周期便远未结束。

结论

PPL 的设计缺陷不在于密码学或访问控制机制的强度，而在于其将编译时签名验证等同于运行时行为可信的语义鸿沟。EDR-Freeze、ClipUp 代理与 COM 接口操控三类技术从不同角度利用了这一缺陷，而四阶段融合攻击链模型进一步展示了其组合利用的现实威胁。对防御方而言，行为基线监控与 WDAC 策略虽无法根除问题，但能显著提高攻击成本。

参考文献

[1] Zero Salarium. "EDR-Freeze: Bypassing PPL with WerFaultSecure Race Condition." https://github.com/TwoSevenOneT/EDR-Freeze

[2] Elastic Security Labs. "RONINGLOADER Analysis: ClipUp.exe PPL Abuse by Dragon Breath APT."

[3] Mohamed Fakroud, Jimmy Bayne. "COM .NET Code Execution via DCOM Object Pointer Manipulation." IBM X-Force Research. https://github.com/T3nb3w/ComDotNetExploit

[4] Forshaw. "PPL Bypass via WaaSRemediation COM IDispatch Interface." https://github.com/xforcered/ForsHops

[5] Microsoft. "Protected Processes in Windows." MSDN Documentation.