Almost every credential-theft tool you have heard of, Mimikatz included, ends up doing the same thing: reading secrets out of the LSASS process. Credential Guard and LSA protection are the two built-in Windows features that make that read fail. This post covers what each one actually does, how they differ, how to turn them on through Intune or policy, and — the part people skip — how to verify they are genuinely enforced rather than just configured.
Key Takeaways
- Credential Guard and LSA protection are complementary defenses against LSASS credential dumping, the technique behind pass-the-hash and pass-the-ticket attacks.
- LSA protection (RunAsPPL) runs LSASS as a protected process so non-protected code cannot read its memory or inject into it.
- Credential Guard uses virtualization-based security to move NTLM hashes and Kerberos tickets into an isolated process, out of reach of the operating system entirely.
- Both are enabled by default on qualifying Windows 11 22H2 and later devices, but only under specific conditions — so you must verify, not assume.
- Neither protects the local SAM or the Active Directory database, and Credential Guard breaks a few legacy protocols, so audit and test before enforcing.
Environment
- Windows 11 22H2 or later, Enterprise or Education edition, on 64-bit hardware with UEFI and Secure Boot.
- Virtualization-based security (VBS) capable hardware for Credential Guard.
- Microsoft Intune or Group Policy for centralized configuration.
- Domain-joined, Entra-joined, or hybrid-joined devices.
The Problem
LSASS — the Local Security Authority Subsystem Service — holds the secrets that let a Windows session work without retyping a password at every step: NTLM hashes, Kerberos tickets, cached domain credentials. That is convenient for users and irresistible for attackers. An adversary who lands on a machine with local administrator rights dumps LSASS memory, harvests those secrets, and reuses them to move laterally. It is MITRE ATT&CK T1003.001, OS Credential Dumping: LSASS Memory, and it is one of the most common steps in a real intrusion.
Detection helps — capturing the suspicious access to LSASS is exactly the kind of thing a good Sysmon configuration surfaces, which I covered in Sysmon configuration for Windows security monitoring. But prevention is better, and Windows ships two prevention features for this specific problem. They are easy to confuse because they both protect LSASS, so it is worth being precise about what each one does.
The Solution
Step 1 — Understand the difference between the two
LSA protection, also called RunAsPPL, marks LSASS as a Protected Process Light. A protected process can only be accessed by other protected processes of equal or higher level, and any plug-in loaded into LSA must be Microsoft-signed. The practical effect is that ordinary administrative tooling — including memory-dumping utilities — can no longer open LSASS to read it.
Credential Guard goes further. It uses VBS to run an isolated version of the LSA process, LSAIso.exe, in a hardware-enforced container the main operating system cannot read. NTLM hashes and Kerberos ticket-granting tickets live in that container. Even malware running as SYSTEM cannot extract them, because they are not in normal memory at all. LSA protection hardens the process; Credential Guard removes the secrets from the process. Run both.
Step 2 — Enable LSA protection (RunAsPPL)
On Windows 11 22H2 and later, LSA protection is enabled by default on devices that meet three conditions: the OS is a new installation rather than an upgrade, the device is enterprise joined (Active Directory, Entra, or hybrid), and the hardware is capable of hypervisor-protected code integrity. If any of those is false — and "upgraded rather than clean-installed" catches a lot of real fleets — you need to enable it explicitly.
The setting is a single registry value under HKLM\SYSTEM\CurrentControlSet\Control\Lsa:
# 1 = enabled with a UEFI lock (cannot be turned off by registry alone)
# 2 = enabled without a UEFI lock (enforced on Windows 11 22H2+)
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' `
-Name 'RunAsPPL' -PropertyType DWord -Value 1 -Force
# A reboot is required for the change to take effect.
For a fleet, push the same value through Group Policy (Computer Configuration → Administrative Templates → System → Local Security Authority → Configures LSASS to run as a protected process) or through Intune with a custom OMA-URI of ./Device/Vendor/MSFT/Policy/Config/LocalSecurityAuthority/ConfigureLsaProtectedProcess set to 1 or 2. The UEFI-lock option is stronger because it cannot be undone with a remote registry edit, but it also cannot be cleanly undone without physical or firmware access, so choose deliberately.
A single GPO carrying both RunAsPPL and the VBS/Credential Guard settings, linked to the OU that holds the lab computers.
Step 3 — Audit for blocked plug-ins first
LSA protection refuses to load any LSA plug-in or driver that is not Microsoft-signed — smart card drivers, custom security support providers, password filters. If you have one of those, turning RunAsPPL on hard will break it. Windows gives you an audit mode that logs what would be blocked without actually blocking it, and on Windows 11 22H2 and later that audit mode is on by default.
Check the Applications and Services Logs → Microsoft → Windows → CodeIntegrity → Operational log for events 3065 and 3066 before you enforce. Each one names a plug-in or driver that does not meet the signing or shared-section requirements:
Get-WinEvent -LogName "Microsoft-Windows-CodeIntegrity/Operational" |
Where-Object { $_.Id -in 3065, 3066 } |
Select-Object TimeCreated, Id, MessageIf those events are empty across a representative sample of devices, enforcement is safe. If they are not, resolve the offending component — usually by updating to a properly signed version — before you flip the switch. Slicing event logs like this is the same pattern from the PowerShell Quick Guide on working with event logs.
The CodeIntegrity Operational log — here recording the code integrity policy activating on boot. This is the same log where the 3065 and 3066 plug-in-block events show up, so it is the first place to look before you enforce.
Step 4 — Enable and confirm Credential Guard
Credential Guard is enabled by default starting in Windows 11 22H2 on domain-joined, non-domain-controller devices that meet the hardware and Enterprise/Education licensing requirements, and that default is applied without a UEFI lock so it can be managed remotely. To deploy it explicitly, use the Intune Endpoint security → Account protection or device configuration settings, or the Group Policy Turn On Virtualization Based Security with Credential Guard configured. Microsoft's Credential Guard configuration guide has the per-mechanism detail.
Verification is the step that matters. Run msinfo32 and look at the System Summary: Virtualization-based security Services Running should list Credential Guard. From PowerShell, the same check is scriptable:
(Get-CimInstance -ClassName Win32_DeviceGuard `
-Namespace 'root\Microsoft\Windows\DeviceGuard').SecurityServicesRunning
# A value of 1 in the array indicates Credential Guard is running.
Credential Guard listed under Virtualization-based security Services Running — the difference between configured and actually enforced.
Step 5 — Confirm LSA protection is actually enforced
Configuring RunAsPPL and having it take effect are not the same thing, so confirm it on the boot you care about. Windows writes a definitive event at startup. Open Event Viewer → Windows Logs → System and look for the WinInit event 12: "LSASS.exe was started as a protected process with level: 4". That event is the proof LSASS came up protected:
Get-WinEvent -FilterHashtable @{ LogName = 'System'; ProviderName = 'Microsoft-Windows-Wininit'; Id = 12 } -MaxEvents 1 |
Select-Object TimeCreated, Message
WinInit event 12 on the boot that matters: LSASS came up as a protected process at level 4.
Together, the Device Guard query and the WinInit 12 event give you a clear, scriptable answer to "is this device actually hardened?" — which is exactly what you want to feed into the device compliance signals discussed in my Intune compliance write-ups.
The real payoff is negative space — the technique this whole post defends against should now fail. With Credential Guard and LSA protection both enforced, a routine LSASS memory dump — here the most benign version of it, Task Manager's Create dump file option running as an administrator — is refused outright:
Access denied. With LSASS running as a protected process, even an elevated administrator cannot read its memory — the exact read that credential-dumping tools depend on.
There is a second detail worth pausing on. The dump was refused, but the attempt still reached Sysmon, and the telemetry shows the protection biting at the kernel level. In the Sysmon ProcessAccess record (Event ID 10) for that attempt, GrantedAccess reads 0x1000 — PROCESS_QUERY_LIMITED_INFORMATION only. The PROCESS_VM_READ right (0x10) that a memory dump needs was stripped out of the handle before Task Manager ever received it. On an unprotected host the same action logs a mask like 0x1fffff or 0x1410; here the read right is simply gone.
The same blocked attempt in Sysmon Event ID 10: GrantedAccess is 0x1000, with the memory-read right stripped by LSA protection. Prevention and detection visible in a single record.
Frequently Asked Questions
Do Credential Guard and LSA protection protect local account passwords?
No. Both protect the secrets LSASS holds for sessions — NTLM hashes and Kerberos tickets — but neither protects the local SAM database or, on a domain controller, the Active Directory database. Local account hashes in the SAM are a separate concern; rotating unique local admin passwords with Windows LAPS is the control for that.
Will Credential Guard break anything?
It blocks a few legacy capabilities: Kerberos DES encryption, Kerberos unconstrained delegation, Kerberos ticket-granting-ticket extraction, and NTLMv1. Modern environments rarely need these, but applications that do will break, which is why testing before broad deployment is part of the process, not optional.
Why is LSA protection not enabled even though my devices are Windows 11 22H2?
Default enablement requires a clean installation, enterprise join, and HVCI-capable hardware. Devices that were upgraded from an earlier release rather than clean-installed do not get it automatically. That single condition leaves a lot of real fleets unprotected until you enable it explicitly through policy.
Should I use the UEFI lock option?
The UEFI lock makes the protection resistant to a remote registry change, which is stronger. The trade-off is that disabling it later requires removing a UEFI variable rather than just editing the registry. For high-value devices the lock is worth it; for fleets where you need flexible management, enabling without the lock is a reasonable middle ground.
Does enabling these features replace the need to detect LSASS access?
No. They make the common dumping techniques fail, but a determined attacker may find edge cases, and not every device in a fleet will be fully protected at all times. Keep detecting suspicious LSASS access alongside prevention — defense in depth, not either-or.
Conclusion
Credential Guard and LSA protection are among the highest-value hardening features Windows ships, precisely because they break the single most common credential-theft technique rather than just logging it. On modern, clean-installed, enterprise-joined Windows 11 they are often already on — but "often" is the operative word, and upgraded devices, Pro editions, and older hardware are exactly the gaps an attacker will find.
The honest version of the rollout is: enable both through policy, audit for blocked LSA plug-ins before enforcing, and then verify with the Device Guard query and the WinInit 12 event rather than trusting that the policy applied. Pair the prevention with detection, remember that neither feature covers the SAM or AD database, and you have closed off the path that most intrusions rely on to spread.
Related Posts
- Sysmon Configuration for Windows Security Monitoring — the detection side of LSASS access, to run alongside prevention.
- Detecting Kerberoasting with Windows Event ID 4769 — another credential-theft technique against the same Kerberos secrets.
- Essential Windows Event IDs for Security Monitoring — the broader catalog of events worth watching, including the ones referenced here.
Editorial note: posts on this blog are drafted with AI assistance and then reviewed, edited, and tested against a real environment before publishing. Commands, output, and screenshots come from systems I actually ran the work on.
0 comments:
Post a Comment