Tools · Active Directory defense · 10 / 23
LSA protection and Credential Guard: stopping credential theft from LSASS
Understand why LSASS memory is targeted, enable RunAsPPL and Credential Guard, check that they are running, and read the related events.
Why LSASS is targeted
The Local Security Authority Subsystem Service (lsass.exe) handles logons and holds credential material for signed-in users so they can reach network resources without retyping passwords. An attacker with administrator rights on a machine can try to read that memory and extract NTLM hashes and Kerberos tickets for anyone logged on, including administrators who connected interactively.
Two protections raise the bar: LSA protection, which runs LSASS as a protected process, and Credential Guard, which moves secrets into an isolated virtualization-based environment.
The two controls
LSA protection (RunAsPPL) prevents non-protected processes, even administrators, from opening LSASS memory or injecting code, unless they load a signed driver. Credential Guard uses virtualization-based security so NTLM hashes and Kerberos TGTs are stored in an isolated process LSAIso that the normal OS cannot read.
Recent Windows 11 releases enable both by default on many new installs with compatible hardware. Verify rather than assume, especially on upgraded machines and servers.
Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\Lsa -Name RunAsPPL -ErrorAction SilentlyContinue (Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard).SecurityServicesRunning # 1 = Credential Guard running, 2 = HVCI running
Lab: enable and confirm
On a lab Windows 11 or Server VM with virtualization-based security support, set RunAsPPL to 1 (or 2 for UEFI-locked on Windows 11 22H2 and later), and enable Credential Guard through Group Policy under Device Guard, Turn On Virtualization Based Security. Reboot and confirm with the commands above and with msinfo32, which lists Virtualization-based security services running.
Check the System log for Wininit Event 12, which says LSASS started as a protected process. Test compatibility: some older smart card or third-party authentication plugins fail to load into protected LSASS, logged as CodeIntegrity events 3033 and 3063.
reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v RunAsPPL /t REG_DWORD /d 1 /f
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Wininit'; Id=12} -MaxEvents 1 | Format-List TimeCreated, Message
Get-WinEvent -LogName 'Microsoft-Windows-CodeIntegrity/Operational' -MaxEvents 20 | Where Id -in 3033,3063What they do not stop
Neither control stops an attacker from using credentials while the user is logged in, capturing a password as it is typed, or stealing secrets stored elsewhere. Credential Guard does not protect local account hashes in the SAM database or domain controller secrets.
They are strongest combined with tiering: if privileged credentials never touch a workstation, there is nothing in its LSASS to steal.
Diagram
LSASS with and without protection
What an administrator-level attacker can read.
Memory access. Any admin process can open lsass.exe.
Exposed. NTLM hashes, Kerberos tickets.
Detection only. Rely on EDR to notice the read.
Memory access. Blocked for non-protected processes.
Exposed. Secrets isolated in LSAIso.
Remaining risk. Live session abuse, keylogging.
Check yourself
1. What does RunAsPPL do?
2. Where does Credential Guard keep NTLM hashes and TGTs?
3. Which risk remains even with both enabled?