Protected Processes & PPL: keeping Windows’ heart safe

Note: This blog post is designed to complement the accompanying video embedded at the top of the page. The video provides an in-depth, visual demonstration of the concepts and code discussed here, making it an invaluable resource for learners.

What is a “protected process”?

Starting with Windows Vista, Microsoft introduced protected processes—special processes the kernel shields from injection, memory reads/writes and handle duplication. Windows 8.1 broadened the idea into Protected Process Light (PPL) so security vendors (antivirus, EDR, etc.) could run hardened services under strict signing rules

Why “protected” at all?

(00:00 – 02:25)

Any handle you open to a protected process is limited to Query Limited Information—no module lists, no memory reads, no code injection—no matter if you run as Administrator or even SYSTEM. Only executables signed by Microsoft (with a specific EKU) may run in this mode.

Windows 8.1: Protected Process Light (PPL)

(02:25 – 05:35)

Two big changes arrived:

1. Multiple protection levels (7 → 0, where 0 means “not protected”).
   A higher-level process can open invasively a lower-level one, but never the other way around.
2. Third-party eligibility. Security vendors can request Microsoft signatures so their AV or EDR services run as PPL and resist user-mode tampering.

LSASS and compatibility considerations

(05:35 – 08:45)

• LSASS did not run protected by default in Windows 10 and early Windows 11 because custom login mechanisms (fingerprint, retina, etc.) need DLLs that aren’t Microsoft-signed, and protected processes refuse to load such DLLs.
• Today’s Windows 11 ships with LSA-protection on by default; older systems can enable it via a single registry value.
• Credential Guard (VBS) still adds another layer by isolating secrets from the kernel itself.

What third-party vendors gain

(08:45 – 10:10)

By running their scanning service at level 3, AV/EDR vendors prevent even an elevated attacker from terminating or injecting into the service. Microsoft treats its own Defender as “third party” for this purpose—the same signing requirements apply.

Seeing protection in action with Process Explorer

(10:10 – 15:30)

1. Enable colour coding
   Options → Configure Colors → Protected Process (Fuchsia by default).
2. Add the “Protection” column
   View → Select Columns → Process Image → Protection.
3. Sort by Protection to spot:
   • WinTCB-light (CSRSS, SMSS),
   • Windows-sign (svchost hosts),
   • Antimalware-light (MsMpEng.exe, NisSrv.exe).

Earlier versions of Process Explorer (pre-v17) could not list DLLs in protected processes; v17+ tunnels through a kernel driver to obtain the information. Threads remain off-limits—you’ll see “Unable to access thread.”

Code can’t cheat: a quick experiment

(15:30 – 17:35)

Try calling OpenProcess() with anything stronger than PROCESS_QUERY_LIMITED_INFORMATION; even as SYSTEM you’ll get ERROR_ACCESS_DENIED against a protected target.

Under the hood: the EPROCESS.Protection field

(17:35 – 22:30)

With a local kernel debugger you can read the flag directly:

> dt nt!_EPROCESS <addr> Protection
   +0x6ca Protection : 0x41 (Signer=4, Type=1)

> dt nt!_EPROCESS <addr> Protection
   +0x6ca Protection : 0x41 (Signer=4, Type=1)

• Low nibble 1 = PPL, 2 = classic PP.
• High nibble = signing level (0–7).

Examples:

• LSASS on older builds → 0x41 (PPL-LSA).
• CSRSS → 0x61 (PPL-WinTCB).

Flipping protection from the kernel

(22:30 – 25:00)

Because kernel code has unrestricted power, you can:

eb <EPROCESS>+0x6ca 00   ; set Protection = 0

eb <EPROCESS>+0x6ca 00   ; set Protection = 0

Immediately the DLL list in Process Explorer appears—proof that protection is user-mode only. Restore the original byte and the process becomes invisible again. A kernel-level rootkit could do the same, so protected processes are not a defence once the kernel is compromised.

Key takeaways

(25:00 – end)

• Protected processes block invasive user-mode access, even from admins.
• The PPL model tiers those protections so trusted system services can still cooperate.
• AV/EDR vendors rely on level 3 to survive privilege-escalation attacks.
• The mechanism hinges on a single flag in EPROCESS—powerful yet bypassable from the kernel.
• For defenders, enabling LSA-protection (or Credential Guard) is important; for attackers, kernel-mode primitives are required to bypass PPL.

Why this matters for TrainSec students

• Pen-testing a modern Windows box? You must know which targets (LSASS, CSRSS, smss) are off-limits without kernel exploits.
• Writing an EDR or driver? You’ll need an ELAM certificate and a PPL-capable service.
• Malware analysts should recognize why credential-dump tools fail on protected hosts.

These topics appear throughout our learning paths:

• Windows Internals Master – architecture, tokens, integrity levels.
• Windows Security Researcher – exploitation & bypass labs, PPL case studies.
• Mastering WinDbg – live debugging of PPL-aware code and dumps.

All courses are self-paced and come with Discord support.

Before you go…

The TrainSec Knowledge Library hosts this article, dozens of free write-ups, and curated links to help you grow from curious developer to seasoned cybersecurity professional. New pieces constantly drop, subscribe to our mailing list and I’ll make sure fresh kernel tips (and occasional war stories) land directly in your inbox.

See you at the next breakpoint!