PPL Abuse: How Attackers Turn Windows’ Own Trust Anchors Into EDR Killers

Executive Summary

Protected Process Light (PPL) is the boundary Microsoft built so that no user-mode caller — even one running as SYSTEM — can poke at LSASS, Defender, or other guarded processes without a properly signed peer. Ghost Wolf Lab’s post argues that boundary has degraded into a trust label rather than a working enforcement mechanism: Microsoft equates “binary is signed at WinTcb level” with “binary can be trusted to do what it was designed to do,” and attackers have figured out how to keep the signature while changing the “design.” The result is a small but growing collection of techniques — the August 2025 EDR-Freeze race condition in WerFaultSecure.exe, the ClipUp.exe PPL proxy seen in RONINGLOADER and Dragon Breath operations, and the WaaSRemediation trapped-COM-object technique — that let attackers operate inside the PPL trust ring against Defender, LSASS and the major Chinese AV suites (360, Kingsoft, Tencent).

The original Ghost Wolf Lab post ties these techniques into a coherent four-phase attack chain: a BYOVD kernel driver kills the easy targets via ZwTerminateProcess; EDR-Freeze hangs whatever Defender pieces survive; ClipUp runs in PPL context to tamper with Defender binaries and registry keys; and an unsigned WDAC policy is then deployed to keep security software from starting again. A working PPL-protection inspector in C, a Sigma rule for ClipUp ImagePath tampering, and the full WinTcb-Light / Antimalware / Lsa / Windows-Light hierarchy table accompany the analysis. The defensive thesis: signature-equals-trust is the root cause, behavioural monitoring of the small set of WinTcb binaries is the only realistic mitigation short of an architectural redesign.

The PPL Trust Boundary

PPL was introduced in Windows 8.1 (extending the Vista Protected Process model) to keep certain processes — LSASS, Defender, the session manager — out of reach of even SYSTEM-level user-mode callers. The kernel encodes each process’s protection state in EPROCESS.Protection as a small DWORD: the low nibble is the type (Protected, Protected Light, none) and the next nibble is the signer (WinTcb, Antimalware, Lsa, Windows, WinSystem). A process can only open another with full access if its own signer level is ≥ the target’s. The article’s C inspector reads this directly through the undocumented ProcessProtectionLevelInfo (0x3F) class of NtQueryInformationProcess:

// 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;
}

The four bands that actually matter on a 2026 Windows install (translated and reproduced from the source’s table):

The hierarchy looks like a moat. The article’s thesis is that it has become a drawbridge: anyone who can drive a binary at one of these levels to do something other than what it was designed for has effectively crossed it.

Three production paths to PPL abuse

1. Race condition in Windows Error Reporting (EDR-Freeze)

WerFaultSecure.exe is a WinTcb-Light binary whose legitimate job is to capture crash dumps from any process — including PPL ones — so that Microsoft’s telemetry pipeline gets useful data. Internally, when it collects a dump via MiniDumpWriteDump, the dump engine suspends every thread in the target so it can produce a consistent snapshot, then resumes them when it’s done. Zero Salarium (August 2025) and the public EDR-Freeze tool (September 2025) found that if you suspend WerFaultSecure itself at exactly the moment after it has paused the target’s threads but before it resumes them, the target stays suspended indefinitely. The original article quotes the technique succinctly:

If we enable WerFaultSecure executing dump operations, then simultaneously invoke MiniDumpWriteDump on antivirus processes while immediately suspending WerFaultSecure the moment target processes enter suspension, target programs will hang indefinitely.

Ghost Wolf Lab, paraphrasing the Zero Salarium / EDR-Freeze technique

Tested on Windows 11 24H2, this freezes Defender and several major endpoint products for ~5 seconds — long enough to run the rest of the attack chain. The article notes the technique works on Defender, 360 Total Security, Kingsoft (金山毒霸) and Tencent PC Manager (腾讯电脑管家).

2. ClipUp.exe as a PPL proxy

ClipUp.exe is another WinTcb-signed binary that ships with Windows. Designed for clipboard/upgrade plumbing, it accepts a handful of command-line arguments (-p, -o, etc.) and can be coaxed into loading attacker DLLs — while running inside the WinTcb-Light protection bucket. Elastic Security Labs documented this pattern in the RONINGLOADER family, and Ghost Wolf Lab confirms the same technique has shown up in Dragon Breath APT operations. The classic kill move is to overwrite the Defender service’s ImagePath registry key from inside ClipUp’s PPL context, so that when WinDefend next starts it runs ClipUp.exe (now used as a generic PPL executor) instead of MsMpEng.exe.

The accompanying Sigma rule (Swachchhanda Shrawan Poudel / Nextron Systems, 2026-01-29) catches exactly this registry-modification pattern, with a tight filter to suppress Defender’s own update path:

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

3. Trapped COM objects (WaaSRemediation / ForsHops)

The third path runs through COM: James Forshaw’s research on the WaaSMedicSvc remediation service (and Mohamed Fakroud / Jimmy Bayne’s related IBM X-Force work) showed that an IDispatch late-binding call from inside a privileged PPL host can be coerced into resolving an attacker-supplied ITypeLib, and from there into loading an arbitrary .NET assembly. The public tooling for this is xforcered/ForsHops and T3nb3w/ComDotNetExploit; the net effect is arbitrary code execution inside a WinTcb-signed process without ever modifying that process’s on-disk image.

The four-phase attack chain

The Ghost Wolf Lab post stitches these primitives into the chain it has seen in production loaders against Defender and the Chinese AV stack:

1. BYOVD kernel termination. A legitimately-signed but vulnerable kernel driver exposes a single IOCTL that takes a PID and calls ZwTerminateProcess on it. Because the kill happens in Ring 0, every user-mode protection — PPL included — is irrelevant. This kills the easy targets up front.
2. EDR-Freeze. Whatever Defender / EDR pieces survived (or auto-restarted) are then frozen via the WerFaultSecure race condition. The 5-second hang on Windows 11 24H2 is plenty of time for phases 3–4.
3. ClipUp.exe PPL proxy. With monitoring blind, ClipUp.exe — running at WinTcb-Light — is used to overwrite Defender’s binary on disk and rewrite its service ImagePath. Because everything happens inside a properly-signed PPL host, kernel-side logging records nothing more suspicious than “WinTcb process did its job.”
4. Unsigned WDAC policy deployment. Finally, an unsigned Windows Defender Application Control policy is dropped that blocks the executables of every common security product. Even if Defender comes back up after reboot, the policy keeps it from launching. The attack chain has now created a self-sustaining “security vacuum.”

Why PPL is hard to fix

Trust anchors get weaponised

PPL’s flaw is in the circular logic at the foundation: a process is trusted because it’s signed at the right level; the signature alone is supposed to imply “is going to do what its publisher intended.” That implication is false. WerFaultSecure’s WinTcb signature says “this binary is allowed to read the memory of every protected process for diagnostic purposes” — not “this binary will only do that.” The signature stays valid when the binary is used as a security-process freezer. Same for ClipUp.exe: the signature attests origin, not the boundary of which DLLs it should load.

Detection’s structural dilemma

An Antimalware-Light process can monitor user-mode code — but it cannot inspect code running at WinTcb-Light, which sits above it in the hierarchy. PPL’s own protections are therefore structurally bypassed whenever an attacker can find an action inside a WinTcb-signed binary whose side effects happen to disable security software. The attacker never needs to break into the security product; they just need to make a higher-band PPL process do something inconvenient.

Ecosystem gaps

The article points out two related problems for defenders. First, there is essentially no off-the-shelf detection content for PPL abuse — the Sigma rule above is one of a handful. Second, Windows itself emits no kernel-side audit record when one PPL process accesses another’s memory or its ImagePath, because from the OS’s point of view everything was within policy. PPL abuse is invisible to the OS’s own observability surface.

Key Takeaways

• PPL is a signature label, not an enforcement primitive. Anyone driving a WinTcb-signed binary to do something other than its design purpose has effectively crossed the boundary.
• EDR-Freeze (WerFaultSecure.exe race condition, Zero Salarium / TwoSevenOneT, Aug–Sep 2025) reliably hangs Defender for ~5 s on Windows 11 24H2.
• ClipUp.exe is a WinTcb-Light PPL proxy that can rewrite Defender’s ImagePath registry entry and replace its on-disk binary from inside the trust boundary. Observed in RONINGLOADER and Dragon Breath APT activity.
• WaaSRemediation trapped-COM-objects (Forshaw / IBM X-Force; ForsHops / ComDotNetExploit) load arbitrary .NET assemblies inside a WinTcb-signed host via IDispatch/ITypeLib coercion.
• The four-phase chain — BYOVD kernel kill → EDR-Freeze → ClipUp PPL proxy → unsigned WDAC block — is observed against Defender, 360, Kingsoft and Tencent.
• The article’s C inspector uses undocumented ProcessProtectionLevelInfo (0x3F) to read the protection DWORD; the low nibble encodes the type, the next nibble encodes the signer.
• Microsoft’s 2026 cross-signing revocation mostly addresses the BYOVD step (phase 1). It does not touch the PPL model itself, so phases 2–4 remain viable.

Defensive Recommendations

• Alert on WerFaultSecure.exe launches that target security-product or LSASS PIDs. Legitimate WER captures rarely point at MsMpEng.exe; an explicit PID argument to a known PPL host is high signal.
• Detect ClipUp.exe running with -p and -o outside the genuine Defender update path. Deploy the Sigma rule reproduced above (or an equivalent) on registry-modification telemetry covering HKLM\SYSTEM\CurrentControlSet\Services\*\ImagePath.
• Watch for DLL loads from non-standard paths in WinTcb-signed processes. A WerFaultSecure or ClipUp process loading a DLL from a user-writable directory is anomalous.
• Watch for PPL-context modifications to Defender’s on-disk binaries, registry keys, or service configuration. Anything that touches \WinDefend\ / \WdFilter\ outside the genuine update process should alert.
• Block known vulnerable drivers via WDAC. Microsoft’s recommended vulnerable-driver block list closes the phase 1 BYOVD step and forces the attacker to find a fresh driver.
• Restrict who can register new kernel services. Phase 1 needs a service registration; tightening which user accounts can write under HKLM\SYSTEM\CurrentControlSet\Services raises the bar substantially.
• Inventory and monitor WDAC policy changes. An unsigned policy that blocks MsMpEng.exe or third-party AV executables from launching is itself the phase-4 attack artefact.
• Treat PPL-process telemetry as a first-class signal. Until Microsoft splits authentication from authorization in the PPL model, defenders need behaviour-based detections on the small set of WinTcb-signed binaries an attacker can realistically weaponise.

Conclusion

Microsoft’s 2026 driver-trust revocation tightens BYOVD, but every observed PPL-abuse chain has a second, third and fourth move that no signature policy can close. Until Windows separates “this binary was signed by Microsoft” from “this binary, given these arguments, is doing what it was designed to do,” the PPL trust hierarchy will keep being walked through rather than over. For defenders, the only realistic ground game is behavioural: monitor the small list of WinTcb-signed binaries an attacker can realistically weaponise, alert on the specific argument and target patterns documented above, and pair that with WDAC block-listing and tight service-creation ACLs to make phase 1 expensive. The Ghost Wolf Lab post is worth reading in the original for the full Chinese context and the additional product-specific notes on Chinese AV products that did not fit a short rewrite.

This article is an independent English-language rewrite of «PPL滥用» (“PPL Abuse”), originally published on Ghost Wolf Lab’s research blog on May 25, 2026. The PPL-inspection C program, the Sigma detection rule, the trust-hierarchy table, and all underlying analysis are the work of the original author(s). Please cite Ghost Wolf Lab when referencing this material.