Disclaimer: This article is provided strictly for educational purposes and authorized security testing. Only run these techniques against systems you own or have explicit written permission to assess. Unauthorized access to computer systems is illegal in virtually every jurisdiction and can carry severe penalties.
Introduction
The Local Security Authority Subsystem Service (lsass.exe) is the single process on Windows that authenticates logons and holds the material behind them — NTLM hashes, Kerberos tickets and keys, and cached domain credentials. For over a decade mimikatz sekurlsa::logonpasswords and its many derivatives made reading that memory almost trivial for anyone holding local administrator: open a handle to LSASS, read its memory, and parse out credentials. LSA Protection (commonly called RunAsPPL, for Protected Process Light) and Credential Guard are Microsoft’s two answers to that problem, and they attack it from different layers — one hardens the process itself, the other removes the secrets from the process altogether.
LSA Protection turns lsass.exe into a Protected Process Light with a signer level that only equally-or-more-trusted signed code can touch, so a normal admin-token OpenProcess with PROCESS_VM_READ simply fails. Credential Guard goes further: using Virtualization-Based Security (VBS), it moves the derived secrets (NTLM hashes and Kerberos TGT keys) into an isolated, hypervisor-protected user-mode process that even a fully compromised, kernel-mode-capable attacker on the host cannot read, because it does not share an address space with the rest of Windows. Understanding exactly what each mechanism protects — and, just as importantly, what it does not — is essential for defenders deciding what “LSASS is protected” actually buys them.
Attack Prerequisites
Credential theft from LSASS, and the conditions under which these protections fail to stop it, generally require:
- Local administrator or SYSTEM on the target host — no unprivileged path to LSASS memory exists on a patched, default-configured system.
- LSA Protection not enabled, or enabled but the process opening the handle is itself signed at an equal-or-higher protection level (rare, and restricted to a small set of Microsoft-signed security tools).
- Credential Guard not enabled, or the target credential type/protocol is one Credential Guard does not isolate (it does not protect NTLM plaintext capture at logon time, nor does it stop Kerberos ticket reuse once issued).
- Kernel-level code execution as the path around either protection — most commonly by loading a signed-but-vulnerable third-party driver (the “Bring Your Own Vulnerable Driver”, BYOVD, pattern) to run arbitrary code in the kernel, which can manipulate the
EPROCESSprotection fields directly rather than going through the documented API.
How It Works
LSA Protection (RunAsPPL) relies on the Protected Process Light infrastructure introduced in Windows 8.1 / Server 2012 R2. Every PPL process carries a signer level in its EPROCESS structure — visible in Process Explorer’s Protection column as values like PsProtectedSignerLsa-Light — and the kernel enforces a strict rule at OpenProcess time: a caller can only obtain rights like PROCESS_VM_READ or PROCESS_VM_WRITE against a protected process if the *caller* is itself a protected process running at an equal-or-higher signer level. An ordinary administrator process, however privileged its token, is not itself a PPL, so its request for LSASS’s memory is denied by the kernel before any DACL is even consulted. This is a capability check baked into the object manager, not a discretionary permission an admin can grant themselves.
Credential Guard solves a different problem: even a kernel-mode attacker (who can, in principle, defeat PPL) should not be able to read the derived credentials LSASS relies on. It uses the hypervisor (Hyper-V’s VBS) to carve out a second, isolated Virtual Secure Mode (VSM) — a parallel, hardware-enforced execution environment the normal (“VTL0”) kernel cannot inspect or write to, even with kernel privileges. A dedicated isolated LSA process, LsaIso.exe, runs inside VSM and performs the actual NTLM hash and Kerberos long-term key operations; the regular lsass.exe in VTL0 only ever talks to LsaIso.exe through a narrow RPC interface and never holds the raw secret material itself. A compromise of the normal kernel — the strongest position an attacker can reach on the host — still cannot cross the VTL boundary to read what is inside VSM.
The two mechanisms are complementary and independently configurable. LSA Protection stops the common case (an admin-privileged user-mode credential dumper) cheaply, with no special hardware requirements. Credential Guard stops the harder case (kernel-level compromise) but requires VBS, which in turn requires UEFI Secure Boot, virtualization extensions, and — for the strongest guarantee — a TPM and Secure Boot with DMA protection; it is also incompatible with some legacy authentication packages (custom SSPs/APs that need raw access to secrets) and with unconstrained Kerberos delegation on the protected host in certain configurations.
Vulnerable Code / Configuration
Both protections are opt-in on many Windows builds and are configured through documented registry values, which makes their absence the single most common vulnerable configuration. LSA Protection is enabled by adding RunAsPPL under the LSA control key:
; Enable LSA Protection (PPL) for lsass.exe
HKLM\SYSTEM\CurrentControlSet\Control\Lsa
RunAsPPL REG_DWORD 1 ; enabled, backed by a UEFI variable lock
RunAsPPL REG_DWORD 2 ; enabled without the UEFI lock (auditable off)
; VULNERABLE STATE: value absent or 0 -> lsass.exe runs as a normal
; process; any admin-token OpenProcess(PROCESS_VM_READ) succeeds.
Credential Guard is configured either via Group Policy (“Turn On Virtualization Based Security”) or, for manual/scripted deployment, directly under the Device Guard and LSA keys:
HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard
EnableVirtualizationBasedSecurity REG_DWORD 1
RequirePlatformSecurityFeatures REG_DWORD 1 ; 1=SecureBoot, 3=+DMA
HKLM\SYSTEM\CurrentControlSet\Control\LSA
LsaCfgFlags REG_DWORD 1 ; Credential Guard with UEFI lock
LsaCfgFlags REG_DWORD 2 ; Credential Guard without UEFI lock
; VULNERABLE STATE: LsaCfgFlags absent/0, or VBS unsupported by hardware
; (no Secure Boot / no compatible CPU virtualization extensions) -> the
; host has no isolated LSA regardless of registry intent.
The UEFI-lock variants (1) are deliberately hard to disable: Group Policy also writes a UEFI firmware variable that Windows re-checks at boot, so simply deleting the registry value does not turn the protection off — an attacker (or an administrator troubleshooting a legitimate incompatibility) must first disable it from within a running, elevated Windows session using the documented Device Guard/Credential Guard removal tooling before the UEFI variable itself is cleared. This lock is exactly what stops a simple registry edit from being an effective bypass.
Walkthrough / Exploitation
Verifying protection status is the first step for both attacker reconnaissance and defensive validation. Live status is visible without elevation:
# LSA Protection: confirm lsass.exe is a Protected Process Light
Get-Process lsass | Select-Object ProcessName, Id
# In Process Explorer, the "Protection" column shows:
# PsProtectedSignerLsa-Light <- RunAsPPL is active
# Credential Guard: query the security services actually running
Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard `
-ClassName Win32_DeviceGuard | `
Select-Object SecurityServicesConfigured, SecurityServicesRunning
# SecurityServicesRunning contains 1 => Credential Guard is live
Against an unprotected LSASS, a standard credential dumper succeeds immediately. Against a PPL-protected LSASS, the identical attempt fails at the OpenProcess call, not at the parsing stage — the access denial is the signal that the protection is doing its job:
mimikatz # privilege::debug
Privilege '20' OK
mimikatz # sekurlsa::logonpasswords
ERROR kuhl_m_sekurlsa_acquireLSA ; Handle on memory (0x00000005)
; STATUS_ACCESS_DENIED -- lsass.exe is a Protected Process Light
Historically, attackers routed around PPL by loading a signed kernel driver with a known vulnerability — the driver’s legitimate signature satisfies Driver Signature Enforcement, but a flaw in the driver lets attacker-supplied code run in the kernel, from which the EPROCESS protection fields can be manipulated directly, bypassing the user-mode OpenProcess check entirely. This BYOVD pattern is why Microsoft ships and actively updates a vulnerable driver blocklist, enforced through WDAC/HVCI, that prevents known-bad drivers from loading in the first place — it is the primary practical defense against this class of bypass, since patching every vulnerable third-party driver is not realistic at fleet scale.
Note: Credential Guard changes *what NTLM/Kerberos operations are possible*, not just who can read memory: NTLM plaintext password caching for the logged-on user is no longer available in VTL0, and NTLMv1, DES, and unconstrained Kerberos delegation become unsupported or restricted on a protected host, which is a common source of application-compatibility breakage during rollout and worth testing before enforcing broadly.
Opsec: PPL and Credential Guard status is easy to check but expensive to defeat quietly. A BYOVD load is loud by construction — installing and starting a kernel driver produces a new-service event and, on a system with HVCI/WDAC and the Microsoft vulnerable-driver blocklist enforced, is simply refused. Attackers who cannot clear either obstacle typically pivot to credentials available elsewhere — cached tickets on other hosts, DPAPI blobs, or browser-stored secrets — rather than attacking a protected LSASS head-on.
Detection and Defense
Because both mechanisms are configuration-driven, verification and tamper-detection matter as much as enabling them in the first place:
- Enable and verify RunAsPPL fleet-wide — set
HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL= 1 via GPO/MDM and audit for hosts where the value is missing or 0. - Enable Credential Guard where hardware supports it — verify with
Get-CimInstance ... Win32_DeviceGuard(or the Device Guard/Credential Guard hardware readiness tool) rather than trusting policy intent alone; policy configured butSecurityServicesRunningempty means it is not actually active. - Watch for anomalous LSASS access — Sysmon Event ID 10 (ProcessAccess) with
TargetImage=lsass.exeand aGrantedAccessmask associated with credential dumpers (e.g.0x1010,0x1438) from a process that is not a known security tool. - Monitor tampering with the protection registry keys — Security Event ID 4657 (a registry value was modified) on the
LsaandDeviceGuardkeys above; a change toRunAsPPLorLsaCfgFlagsoutside change-managed deployment is a high-priority alert. - Enforce the Microsoft vulnerable driver blocklist via HVCI/WDAC and alert on Sysmon Event ID 6 (driver loaded) for unsigned or newly-seen drivers, plus Event ID 7045 (new service installed) for kernel-mode services — the combination is the standard BYOVD detection pattern.
- Enable the Microsoft Defender ASR rule “Block credential stealing from the Windows local security authority subsystem” (
9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2) as a behavioral backstop independent of PPL/Credential Guard status.
Real-World Impact
LSA Protection and Credential Guard exist directly because of the maturity of the LSASS-dumping tradecraft that mimikatz popularized; Microsoft documents both as core mitigations against credential theft in its security baselines, and Credential Guard in particular is a standard requirement in modern enterprise hardening guidance for domain controllers and privileged-access workstations. The BYOVD counter-technique is well documented across the industry and tracked in public catalogs such as the LOLDrivers project, which is precisely why the vulnerable-driver blocklist has become a load-bearing, actively maintained control rather than a one-time hardening checkbox.
Conclusion
LSA Protection and Credential Guard address two different attacker positions — user-mode admin access and kernel-mode compromise, respectively — and together they close off the easy, decade-old path of reading LSASS memory directly. Neither is magic: both are configuration that can be absent, disabled, or (in the kernel case) circumvented via a vulnerable driver, so defenders should treat “is LSASS actually protected right now” as a continuously verified fact, not an assumption, and pair the protections with registry-tamper alerting and driver-load monitoring so any attempt to weaken them is itself the detection.
You Might Also Like
If you found this useful, these related deep-dives cover adjacent techniques and their defenses:
Comments