How to Configure Local Security Authority (LSA) Audit Mode Using PowerShell

Enabling Local Security Authority (LSA) protection as a Protected Process Light (RunAsPPL) prevents credential harvesting tools such as Mimikatz from dumping plaintext passwords and Kerberos tickets directly from lsass.exe memory. However, enforcing RunAsPPL without prior validation can break legacy smart cards, biometric authenticators, or third-party security software if their authentication packages are unsigned. Configuring LSA Audit Mode enables administrators to monitor driver compatibility before locking down memory boundaries.

Understanding LSA Protection and Audit Mode Mechanics

Windows 11 manages LSA memory protection through registry flags in the kernel security subsystem:

• RunAsPPL (Enforced): Restricts non-PPL processes from opening LSASS memory handles with read/write permissions and prevents loading DLLs lacking Microsoft cryptographic signatures.
• RunAsPPL (Audit Mode): Simulates enforcement. If an unsigned DLL or unauthorized handle request targets LSASS, the kernel allows execution but generates audit entries in the Windows Event Log.
• Event Log Telemetry: Incompatible drivers trigger Event ID 3065 and Event ID 3066 under the CodeIntegrity operational channel.

Configuring LSA Audit Mode via PowerShell

Launch PowerShell as Administrator and execute the following commands to configure audit mode registry values:

# Navigate to the LSA registry path
$LsaPath = "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa"

# Configure RunAsPPL in Audit Mode (Value = 2)
New-ItemProperty -Path $LsaPath -Name "RunAsPPL" -Value 2 -PropertyType DWord -Force

# Verify the configured value
Get-ItemProperty -Path $LsaPath -Name "RunAsPPL"

The registry values for RunAsPPL represent:

• 0 = Disabled (No protection).
• 1 = Enforced (RunAsPPL active; unsigned drivers blocked).
• 2 = Audit Mode (RunAsPPL enabled in audit mode; telemetry recorded).

Auditing Code Integrity Events in the Event Log

After restarting the system to load the audit mode configuration, query the event log using PowerShell to verify compatibility:

# Query CodeIntegrity operational log for LSA audit events
Get-WinEvent -FilterHashtable @{
    LogName = "Microsoft-Windows-CodeIntegrity/Operational"
    Id = 3065, 3066
} -ErrorAction SilentlyContinue | Format-List TimeCreated, Id, Message

Review the captured events:

• Event ID 3065: Indicates that a driver or authentication package failed signature requirements and would have been blocked under full enforcement.
• Event ID 3066: Indicates that a process requested an unauthorized handle to LSASS that would have been denied.

Upgrading from Audit Mode to Full Enforcement

Once event logs confirm that all drivers, authentication plugins, and security agents are fully compliant with Microsoft signature policies:

# Transition LSA to Full Enforcement (Value = 1)
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "RunAsPPL" -Value 1

# Restart the workstation to apply enforced protection
Restart-Computer -Force

Following reboot, verify that LSASS runs as a protected process by checking the System log for Event ID 12 (LSASS started as protected process).