Historically, tools like Mimikatz have been used to extract credentials directly from LSASS. This has led to Microsoft and security vendors implementing increasingly aggressive protective mechanisms around LSASS, including isolating it, preventing access via protected process modes, and introducing virtualization-based protections like Credential Guard.
Microsoft has dramatically hardened LSASS in recent years:
Protected Process Light (PPL): Prevents even SYSTEM-level processes from reading LSASS memory unless signed with Microsoft-trusted certificates.
<aside> ℹ️
PPL is a security feature designed to protect high-value processes from tampering—even by other processes running as SYSTEM. When a process like LSASS is run as a PPL, access to its memory space is heavily restricted. Only trusted, Microsoft-signed binaries with specific protection levels can read or write to it.
PPL uses different protection levels, and LSASS typically runs as PsProtectedSignerLsa-Light. This limits access to processes that either:
This means that even tools running with administrative privileges (like procdump.exe) cannot access LSASS unless they’re properly signed and allowed.
</aside>
Virtualization-Based Security (VBS): Isolates security-critical components, making traditional memory dumping methods ineffective.
<aside> ℹ️
VBS leverages hardware virtualization (e.g., Intel VT-x, AMD-V) to isolate sensitive parts of the Windows OS from the rest of the system. It creates a secure, virtualized environment called Virtual Secure Mode (VSM) that hosts highly privileged components.
Within VSM, certain memory regions become entirely inaccessible to standard processes—even those with elevated privileges. VBS enforces process integrity and makes it difficult to inject or tamper with system processes like LSASS.
With VBS enabled, even if an attacker disables PPL, portions of LSASS memory may still be off-limits.
</aside>
Credential Guard: Runs part of LSASS functionality in a Hyper-V-based isolated container, making even memory-access attempts futile in many cases.
<aside> ℹ️
Built on top of VBS, Credential Guard isolates credential material—including password hashes, Kerberos tickets, and NTLM secrets—inside VSM. LSASS still runs in the normal OS space, but the actual secrets are stored in Isolated LSA (LSAIso), a process running in the secure container.
Even if you dump LSASS memory under Credential Guard, you won’t retrieve actual credentials, just metadata or stubs pointing to secure handles.
Credential Guard also blocks:
lsass.exe memory,Tamper protection in Microsoft Defender and EDRs: Actively monitors attempts to access or tamper with LSASS, often killing offending processes or blocking the action altogether.
https://github.com/vari-sh/RedTeamGrimoire/tree/main/Doppelganger
https://labs.yarix.com/2025/06/doppelganger-an-advanced-lsass-dumper-with-process-cloning/
https://www.youtube.com/watch?v=dVPcqNF4j4c&ab_channel=YarixSicurezzaInformatica