LSASS is a core Windows process that handles authentication and keeps credentials cached in memory during an active session. Attackers target it to extract usernames, password hashes, and in some configurations plaintext passwords — giving them everything they need to move laterally across a network.
To simulate this technique, three methods were attempted:
- Task Manager dump — blocked by Windows Defender immediately
- ProcDump (legitimate Microsoft Sysinternals tool) — access denied at the OS level
- PowerShell handle access — no Sysmon event generated
None of the methods produced a Sysmon Event ID 10 (Process Access) event. After investigating, the reason became clear.
Running this command confirmed the protection status:
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "RunAsPPL"The result: RunAsPPL = 2 — the highest level of LSASS protection available.
This is a built-in Windows feature called LSA Protection (RunAsPPL), which runs LSASS as a Protected Process Light. It is applied by default on devices with a new installation of Windows 11 version 22H2 or later. Microsoft also enabled Windows Defender Credential Guard by default for organizations using the Enterprise edition of Windows 11.
What this means practically: LSA Protection runs LSASS as a Protected Process Light, meaning only trusted, code-signed processes with special permissions can interact with it — preventing most third-party programs, including typical malware, from opening LSASS's memory.
This is actually the correct outcome. Prevention is better than detection — the attack was stopped before it could generate any telemetry to detect. Enabling RunAsPPL is considered a true quick win — it is very easy to configure and particularly efficient. Attackers will have to use relatively advanced tricks to work around it, which ultimately increases their chance of being detected.
Full simulation using Mimikatz — which uses a kernel-level driver to bypass PPL — was not completed in this session as it requires an isolated lab VM environment to run safely. That's a separate lab exercise.
Wazuh's default rule 92900 covers LSASS access via Sysmon Event ID 10 for environments where PPL is not enabled or where an attacker successfully bypasses it. No custom rule was needed here — the prevention layer is already in place and the default detection coverage exists for environments where it isn't.