The Local Security Authority Subsystem Service (LSASS) is the beating heart of Windows authentication. Whenever a user logs into a Windows machine, LSASS verifies their password, generates a Kerberos ticket (or NTLM hash), and caches those credentials in memory. This caching is necessary for Single Sign-On (so the user doesn’t have to type their password every time they open a network share).
However, this creates a massive vulnerability. If an attacker gains local administrator rights on a server, they can use open-source tools like Mimikatz or Procdump to read the memory space of the lsass.exe process. By dumping this memory, the attacker can extract the plaintext passwords or NTLM hashes of every single user who has recently logged into that machine. They then use those stolen credentials to leapfrog across the network (Pass-the-Hash), eventually compromising the Domain Controller.
To neutralize this attack vector, Microsoft engineered LSA Protection (also known as RunAsPPL). When enabled, Windows boots the LSASS process inside a Protected Process Light (PPL) boundary. The Windows kernel mathematically prohibits any non-protected process (even if it is running as NT AUTHORITY\SYSTEM) from reading the memory of a PPL process, rendering Mimikatz completely useless.
This guide explains how to audit and enforce LSA Protection across your Windows Server fleet.
Understanding the Architecture of PPL
Protected Process Light (PPL) is a DRM (Digital Rights Management) technology repurposed for security.
When LSA Protection is enabled, Windows requires that any process attempting to attach a debugger to lsass.exe or request PROCESS_VM_READ access must be digitally signed with a specific, highly restricted Microsoft certificate. Because Mimikatz is not signed by Microsoft, the Windows kernel intercepts the memory read request and instantly denies it, returning an “Access Denied” error to the attacker, regardless of their privilege level.
Step 1: Auditing for Compatibility (The Crucial Step)
Warning: Do not blindly enforce LSA Protection via Group Policy without testing.
Many legacy third-party authentication plugins (like older Smart Card drivers, custom password filters, or legacy endpoint agents) inject their own DLLs directly into the LSASS process to function. If you enforce LSA Protection, the kernel will block these unsigned DLLs from loading. LSASS will crash, and the server will Blue Screen (BSOD) or fail to boot.
You must deploy LSA Protection in Audit Mode first.
Open the Registry Editor (regedit.exe) and navigate to:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
Create a new DWORD (32-bit) Value named RunAsPPL and set its value to 2 (Audit Mode).
Restart the server. Let it run for several days.
Step 2: Analyzing the Audit Logs
During Audit Mode, Windows allows all DLLs to load into LSASS, but it logs any DLL that would have been blocked if enforcement was active.
Open the Event Viewer and navigate to:
Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational
Look for Event ID 3065 or 3066. The event description will state: “Code Integrity determined that a process attempted to load \Device\HarddiskVolume3\Windows\System32\incompatible_plugin.dll that does not meet the Microsoft signing level requirements.”
If you see these events, you must contact the vendor of that specific DLL (e.g., your smart card vendor) and request a PPL-compliant version. Do not proceed to enforcement until the audit logs are completely clean.
Step 3: Enforcing LSA Protection via Group Policy
Once you verify that no critical authentication plugins will be blocked, you can enforce the protection across your enterprise.
- Open the Group Policy Management Console (GPMC).
- Create a new GPO (e.g.,
SEC-LSA-Protection-Enforce) and link it to your target Server OUs. - Navigate to Computer Configuration > Preferences > Windows Settings > Registry.
- Create a new Registry Item:
- Action: Update
- Hive: HKEY_LOCAL_MACHINE
- Key Path:
SYSTEM\CurrentControlSet\Control\Lsa - Value Name:
RunAsPPL - Value Type: REG_DWORD
- Value Data:
1(Enforce Mode)
- Apply the GPO.
(Note: LSA Protection only takes effect upon a reboot, as the LSASS process must be instantiated as a PPL process during the boot sequence).
Step 4: UEFI Lock (Preventing Admin Reversal)
If an attacker gains local admin, they could simply change the RunAsPPL registry key back to 0 and reboot the server to extract the credentials.
To prevent this, you can lock the LSA Protection state into the physical UEFI firmware variable. Once locked in UEFI, the registry key is ignored, and LSA Protection cannot be disabled remotely, even by a Domain Admin.
To set the UEFI lock, you must use the Microsoft Local Security Authority (LSA) Protected Process Opt-in tool (a PowerShell script provided by Microsoft that writes to the UEFI variables).
Conclusion
Credential dumping is the primary mechanism attackers use to escalate a single compromised server into a total domain takeover. By systematically auditing your authentication plugins and enforcing Microsoft Local Security Authority (LSA) Protection, security architects leverage the Windows kernel to build an impenetrable wall around the LSASS process, neutralizing tools like Mimikatz and definitively breaking the attacker’s lateral movement kill chain.