expert

Protected Processes & PPL

A process-launch-time trust label that restricts even SYSTEM-level handle access — not an access check.

What you should already know

This topic is marked expert. Skim these first if any of them feel unfamiliar.

Processes & threads Access checks & Security Reference Monitor

Related labs

Hands-on exercises for this area — in the browser or on a Windows machine.

ACL & SDDL Lab

Paste SDDL or pick samples, then see owner, DACL, SACL, and ACE meaning in plain language.

Open lab

View all labs

Guided paths in this branch

Follow a short sequence step by step. Each path links to the first topic; use Read next on each page to continue.

Security deep dive

From identity (tokens) to object policy (DACL/SACL), through kernel access checks (SRM), ending with UAC and integrity boundaries.

1. Security 2. Access tokens 3. Security descriptors & ACLs 4. Access checks & Security Reference Monitor 5. UAC, integrity levels, and secure desktop

Follow this path

Why it matters

LSASS, many anti-malware engines, and DRM-sensitive media components all run as protected processes specifically to close off a class of attack that ordinary DACLs can't: an admin-level attacker simply opening a handle to the process and reading its memory.

Mental model

A normal access check asks 'does this caller's token satisfy this object's descriptor?' Process protection asks a completely different question first: 'is the caller itself running at a protection level at or above the target?' If not, the open is refused before any token or ACL is even consulted.

How it works

1At CreateProcess time, a process can be launched as protected (PP) or the lighter-weight Protected Process Light (PPL), each carrying a signer type (e.g. WinTcb, Windows, Antimalware, Lsa, CodeGeneration) baked into the image's signature.
2The kernel compares the caller's protection level and signer against the target process's: a caller with no protection, or a lower/incompatible signer, has its requested access rights for sensitive operations (e.g. PROCESS_VM_READ, PROCESS_VM_WRITE) silently stripped from the handle it receives.
3Because the restriction is enforced at the process-object level, before SRM's normal descriptor-based access check even runs, it's orthogonal to being an administrator: SYSTEM and admin tokens get exactly the same treatment as anyone else.
4PPL is a strictly weaker variant of full PP, allowing more signer types to participate (which is why antimalware vendors can ship PPL services) while still blocking unprotected callers.

Key terms

Protection level: PsProtectedTypeNone/ProtectedLight/Protected — the launch-time trust tier assigned to a process.
Signer type: Which category of Microsoft or vendor signature authorizes a given protection level (WinTcb, Windows, Lsa, Antimalware, CodeGeneration).
EPROCESS::Protection: The kernel field the process manager and object-access code actually check on every cross-process handle request.

Why `OpenProcess` on lsass.exe returns a crippled handle

Even a successful `OpenProcess(PROCESS_ALL_ACCESS, ...)` call against a PPL-protected lsass.exe, made from an ordinary elevated-admin process, silently returns a handle with the memory-read/write rights stripped out — not an error, just fewer rights than requested. Tools that dump LSASS memory for credentials have to work around this (e.g. by loading a signed, co-operating driver) specifically because this mechanism exists.

Common misconception

Assuming 'I'm an admin, so I can open a handle to anything' — process protection is specifically designed to be orthogonal to administrative privilege, not an extension of it. Being SYSTEM doesn't make you a WinTcb-signed caller.

You should read next

Ranked from your current topic, related links, branch depth, and any active guided path.