How to Configure Local Security Authority RunAsPPL Hardening in Windows 11 Using PowerShell

The Local Security Authority Subsystem Service (LSASS, running as lsass.exe) is one of the most critical security processes in Windows, responsible for authenticating users, managing access tokens, and handling Kerberos and NTLM credentials. Consequently, LSASS is a primary target for post-exploitation credential dumping utilities such as Mimikatz, which attempt to inject code or read process memory. Configuring LSASS to run as a Protected Process Light (RunAsPPL) prevents unauthorized processes from reading LSASS memory or injecting malicious code.

How LSA RunAsPPL Hardening Protects Credentials

When RunAsPPL is enabled, the Windows kernel enforces cryptographic code signing verification on all code loaded into the LSASS process space:

• Signed Binary Verification: Any DLL or security support provider (SSP) attempting to load into lsass.exe must be cryptographically signed with a trusted Microsoft certificate.
• Access Restriction: Non-protected processes—even those executing with local Administrator or NT AUTHORITY\SYSTEM privileges—are blocked from acquiring PROCESS_VM_READ or PROCESS_VM_WRITE handles to LSASS memory.
• Mimikatz Mitigation: Attempts to dump plaintext passwords, password hashes, or Kerberos ticket-granting tickets via API calls return ACCESS_DENIED.

Checking Current LSA Protection Status in Windows 11

To inspect your current LSA configuration via PowerShell:

1. Right-click the Start button on Windows 11 and select Terminal (Admin) or PowerShell (Admin).
2. Query the active LSA registry parameters:

   Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "RunAsPPL", "RunAsPPLBoot" -ErrorAction SilentlyContinue

3. Evaluate the values:
   • RunAsPPL = 1: LSA is configured with standard RunAsPPL protection.
   • RunAsPPL = 2: LSA is configured with RunAsPPL with UEFI variable lock (cannot be disabled via registry alone).
   • Property not found or 0: LSA is running without PPL protection.

Enabling LSA Protection via PowerShell

To enforce LSA protection immediately via registry manipulation:

# Enable standard RunAsPPL protection:
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "RunAsPPL" -Value 1 -Type DWord

# Optional: Configure UEFI lock protection (requires UEFI reboot to disable):
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "RunAsPPLBoot" -Value 2 -Type DWord

Enforcing via Group Policy and Intune

For domain-wide or cloud-managed fleet deployments:

• Group Policy: Open gpedit.msc, navigate to Computer Configuration > Administrative Templates > System > Local Security Authority, and enable Configures LSASS to run as a protected process, setting the option to Enabled with UEFI lock.
• Microsoft Intune: Navigate to Endpoint Security > Account protection > Local security authority rules and set Enable LSA protection to Enabled.

Verifying Protection in Event Viewer After Reboot

Restart the workstation to activate kernel protection, then verify in Event Viewer:

1. Press Win + X and open Event Viewer.
2. Navigate to: Applications and Services Logs > Microsoft > Windows > LSA > Operational (or System log filtered by Source LSASS).
3. Look for Event ID 3033: The code integrity tool determined that a process (\Device\HarddiskVolume…\lsass.exe) attempted to load \Device\HarddiskVolume… which met the requirements of Protected Process Light (PPL).
4. Look for Event ID 3065 or 3066 confirming that LSASS has started as a protected process.

Deploying LSA RunAsPPL hardening on Windows 11 neutralizes one of the most widespread credential harvesting vectors, safeguarding enterprise identities against lateral movement attacks.