LSA Protection

LSA Protection is Protected Process Light applied to one process that matters more than any other: the Local Security Authority, where the credential material lives. Running LSA as a protected process closes the classic user-mode path, Mimikatz style in-memory dumping from an adjacent process, and it is the first thing an attacker notices when that path returns nothing.

But the framing follows the PPL page exactly, and so does the verdict: the enforcement is a byte in kernel memory consulted at handle-open time. Against a user-mode adversary it is a wall. Against a kernel read/write primitive it is a speed bump, because the primitive does not need to open a handle at all.

Layer	User. The protected asset is credential material held in LSASS.
Enforced by	Kernel. LSA runs as PPL; the object manager checks handle opens.
Mechanism	RunAsPPL protection level on the LSA process.
Introduced	Windows 8.1 Update (KB2973201), by registry opt-in; hardened since.

Bypass inventory

Why the inventory looks like this

Everything here is the PPL inventory with one substitution: the protected process now holds secrets, so the payoff for the same techniques is larger while the difficulty is unchanged. That is worth saying plainly to defenders: LSA Protection raises the floor against commodity malware, which is most of the threat, and buys nothing against the kernel-primitive adversary this site is about. The answer to that adversary is one layer up: Credential Guard moves the secrets themselves out of VTL0, which is a different kind of answer entirely.

What a defender sees

Failed handle opens against the LSA process from medium-integrity processes, which is commodity malware hitting the wall and a useful low-severity signal. Kernel-context access to LSASS memory is the higher-fidelity event, and the driver-load signals from the second technique arrive earlier still. A fleet relying on LSA Protection alone should treat any VBS-capable machine without Credential Guard as the gap it is.