LSASS Protection (RunAsPPL): How to Block Credential Dumping Without Deploying Credential Guard
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Credential dumping from LSASS is the single most common post-exploitation technique in Active Directory environments. After gaining local administrator access (or via a privilege escalation exploit), an attacker runs Mimikatz or calls MiniDumpWriteDump and extracts all credentials cached on the local system -- including service account passwords, domain admin Kerberos tickets, and in older configurations, plaintext passwords. Enabling LSASS as a Protected Process Light (RunAsPPL) blocks all of this: it prevents any non-Microsoft-signed process from opening a handle to LSASS. This guide covers the exact steps, the compatibility considerations, and what RunAsPPL does not protect against.
Enable RunAsPPL via Registry
Set the following registry value: HKLM\SYSTEM\CurrentControlSet\Control\Lsa, value name RunAsPPL, type REG_DWORD, data 1. Via PowerShell: Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name RunAsPPL -Value 1 -Type DWord. Via GPO Preference: Computer Configuration > Preferences > Windows Settings > Registry > New Registry Item, set the above path and value. A reboot is required for the change to take effect. After the reboot, verify with: Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' | Select-Object RunAsPPL. On Windows 11 22H2 and later, LSASS PPL protection is enabled by default on fresh installs if Secure Boot is enabled. On Windows 10 and Windows Server 2019/2022, it must be set manually. For Windows Server 2025, Microsoft changed the default to RunAsPPL=2 (PPL with UEFI lock) on new installations.
RunAsPPL=1 vs. RunAsPPL=2 (UEFI Lock)
RunAsPPL=1 enables PPL but can be disabled by a local administrator with physical access who changes the registry before the next boot. RunAsPPL=2 (Windows 10 1709 and later, Server 2019 and later) writes the protection state to UEFI and cannot be disabled by registry modification alone -- an attacker would need physical access to the UEFI firmware. Use RunAsPPL=2 on all systems where UEFI Secure Boot is enabled and you want the strongest protection. Caveat: once you set RunAsPPL=2 and reboot, disabling it requires a UEFI configuration change. Test on a non-production machine first and confirm that your driver stack is fully compatible before deploying RunAsPPL=2 to servers.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Check Driver Compatibility First
The most common RunAsPPL deployment failure is incompatible third-party drivers -- specifically older antivirus drivers, backup agents, and security tools that inject into LSASS or open LSASS handles. When LSASS starts as a PPL and a driver cannot load because it lacks the required Microsoft signature, the driver fails silently and the associated software stops functioning. Before broad deployment, enable audit mode: set HKLM\SYSTEM\CurrentControlSet\Control\Lsa\PPLConfig to 1 (PPL audit mode, available in Windows 10 1607 and later). This logs events to the Event Log when a process would be blocked from accessing LSASS without actually blocking. Event ID 3033 and 3063 in the Microsoft-Windows-CodeIntegrity/Operational log indicate blocked actions. Review those events for legitimate security tools before enabling enforcement. Most modern AV and EDR products (CrowdStrike Falcon, Microsoft Defender, Carbon Black) are compatible with RunAsPPL. Older products from 2018 and earlier may not be.
What RunAsPPL Does Not Protect Against
RunAsPPL blocks userland credential dumping from LSASS. It does not block: kernel-level credential dumping (a driver with kernel access can bypass PPL -- Mimikatz includes a driver component called mimidrv.sys for this purpose); Credential Guard attack paths (if Credential Guard is not enabled, NTLM hashes and service account credentials are still accessible via other means after PPL bypass); memory dump of the entire machine (a complete memory dump via crash dump or hypervisor includes LSASS memory). Against these more sophisticated attacks, Credential Guard provides a stronger defense by moving credential secrets into an isolated VM. RunAsPPL and Credential Guard are complementary: RunAsPPL handles the common case of local admin credential dumping; Credential Guard handles more sophisticated attacks and has higher hardware requirements. If you cannot deploy Credential Guard, RunAsPPL is meaningful protection.
Deploy via Intune MDM for Modern Management
For Intune-managed Windows 10/11 devices, use an Endpoint Security > Account Protection policy (under Attack Surface Reduction). Enabling 'Credential Guard' in Intune activates both Virtualization Based Security and Credential Guard, which is stronger than RunAsPPL alone. If you want only RunAsPPL without VBS requirements, use a Device Configuration Profile > Settings Catalog > search for 'RunAsPPL' and set 'LSA run as PPL' to Enabled. Alternatively, deploy via the Windows Security Baseline built-in template in Intune -- the security baseline enables RunAsPPL by default. For server deployments without Intune, use the GPO Preference registry method described in section 1 and confirm application via: Invoke-Command -ComputerName servername { Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\Lsa RunAsPPL }.
The bottom line
Enable RunAsPPL to block the credential dumping attack that follows most initial compromise events in Windows environments. The deployment is a single registry value and a reboot. Test driver compatibility in your environment first using audit mode, then deploy to workstations before servers. RunAsPPL is not a complete credential protection solution -- complement it with Credential Guard on capable hardware and enforce Tiered Access to limit the impact of any credential that does get dumped.
Frequently asked questions
Does RunAsPPL break Mimikatz completely?
Standard Mimikatz (sekurlsa::logonpasswords) fails when RunAsPPL is enabled because it cannot open an LSASS handle. Mimikatz includes a driver (mimidrv.sys) that can bypass PPL by loading a kernel driver with the appropriate signature -- but loading unsigned or improperly signed kernel drivers is blocked by Secure Boot and Windows Driver Signature Enforcement. In practice, most commodity malware cannot bypass RunAsPPL. Sophisticated threat actors with the ability to load kernel drivers can bypass it -- which is why defense in depth with Credential Guard, privileged access restrictions, and network segmentation matters beyond any single hardening setting.
What is the difference between RunAsPPL and Credential Guard?
RunAsPPL restricts which userland processes can access LSASS memory -- the credentials are still stored in LSASS, they just cannot be read by standard tools. Credential Guard moves domain credentials (NTLM hashes and Kerberos tickets) into an isolated Virtual Secure Mode VM that even LSASS cannot directly access -- the credential material never exists in addressable memory accessible from the OS. Credential Guard provides stronger protection but requires UEFI Secure Boot, a 64-bit processor with virtualization support, and IOMMU. RunAsPPL works on any Windows 8.1 and later machine. Use Credential Guard where hardware supports it; use RunAsPPL as a fallback everywhere else.
Will RunAsPPL break my antivirus or backup software?
Modern AV and EDR products are compatible. The products most likely to have issues are older backup agents (particularly those that inject agents into LSASS for password-protected backup encryption) and older host-based security products. Test on a representative sample of machines in audit mode (PPLConfig=1) before deploying. Event ID 3033 will tell you exactly which processes would be blocked.
How do I verify that RunAsPPL is active and working?
After reboot, verify the registry key is set and check the LSASS process protection level: Get-Process lsass | Select-Object -ExpandProperty Protection should return PsProtectedSignerLsa-Light or similar. Alternatively, use Process Explorer (Sysinternals) -- open LSASS properties and the Security tab shows the protection level. On an audit: run Mimikatz sekurlsa::logonpasswords in a controlled test and confirm it returns an error about handle access.
What is the difference between LSASS RunAsPPL and Credential Guard for protecting credentials?
Both protect domain credentials from LSASS memory dumps but through different mechanisms. RunAsPPL (Protected Process Light) prevents unauthorized processes from obtaining a handle to the LSASS process with sufficient rights to read its memory. It operates at the Windows kernel level and can be bypassed by kernel-level exploits (driver vulnerabilities). Credential Guard isolates domain credentials (specifically NTLM hashes and Kerberos TGTs) in a hardware-isolated virtualization-based security (VBS) environment. Even a kernel-level exploit on the Windows kernel cannot reach the VBS environment. Credential Guard provides stronger protection but has broader compatibility requirements (UEFI, TPM, Hyper-V). Deploy Credential Guard where hardware requirements are met and RunAsPPL as a fallback on older hardware.
What are Bring Your Own Vulnerable Driver (BYOVD) attacks and how do they bypass PPL and EDR?
BYOVD attacks exploit a Windows design decision: any legitimately signed driver can be loaded onto a system, even if the driver contains known vulnerabilities. Attackers load a signed but vulnerable kernel driver (examples include gdrv.sys from Gigabyte, RTCore64.sys from MSI, and many others cataloged at LOLDrivers.io), then exploit the driver's vulnerability to execute code at kernel level. Kernel-level code can terminate EDR processes and their kernel callbacks, kill PPL-protected LSASS protection, and disable Windows Defender. Microsoft maintains a blocklist of known vulnerable drivers (WDAC driver block rules) that is distributed via Windows Update and enforced by HVCI (Hypervisor-Protected Code Integrity) when enabled. The primary defense is enabling HVCI (Memory Integrity) in Windows Security Center, which enforces the driver blocklist at the hypervisor level where even kernel-level attackers cannot disable it. Check HVCI status: Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.