dumping-lsass.md

Introduction to LSASS

The Local Security Authority Subsystem Service (LSASS) is a process in Microsoft Windows operating systems that is responsible for enforcing the security policy on the system. It verifies users logging on to a Windows computer or server, handles password changes, and creates access tokens.

Because it handles authentication, LSASS stores credentials (both plaintext and hashes depending on the OS version and configuration) in memory. This makes the lsass.exe process a prime target for attackers and Red Teamers post-exploitation.

Why Dump LSASS?

Once an attacker has elevated privileges (usually SYSTEM or local Administrator), they can interact with the LSASS process to extract credentials. These credentials can then be used for lateral movement across the network.

Modern Protections

Before diving into techniques, it's important to understand what modern Windows systems put in place to protect LSASS. Bypassing these protections is where most of the real work lies in 2026.

PPL, Protected Process Light

What is PPL?

Starting with Windows 8.1, Microsoft introduced Protected Process Light (PPL), a mechanism that restricts which processes can interact with a protected process, even as SYSTEM or local Administrator.

A PPL process can only be accessed by another process with an equal or higher protection level, signed by a trusted certificate. For LSASS specifically, this means standard admin-level tools like Task Manager, Procdump, or comsvcs.dll are simply refused, they receive Access Denied regardless of their privilege level.

PPL Levels for LSASS

PPL uses a hierarchy of signers. The higher the signer level, the stronger the protection:

Level	Signer	Description
0	None	No protection
1	Authenticode	Basic signing
2	CodeGen	Code generation
3	Antimalware	AV/EDR processes
4	Lsa	LSASS default PPL
5	Windows	Windows components
6	WinTcb	Trusted Computing Base

When RunAsPPL is enabled, LSASS runs at level 4 (PsProtectedSignerLsa-Light). Any process trying to open a handle with PROCESS_VM_READ or PROCESS_ALL_ACCESS must be signed at level 4 or higher, which rules out virtually every attacker tool.

Checking the PPL level

# Check if RunAsPPL is enabled and at which level
reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v RunAsPPL

# Values:
# 0 = PPL disabled
# 1 = PPL enabled + UEFI lock (cannot be modified from OS)
# 2 = PPL enabled (can be modified via registry)

UEFI Lock, The Hardest Configuration

When RunAsPPL = 1 (with UEFI lock), the setting is additionally protected by a UEFI variable, stored in firmware. This means:

Even SYSTEM cannot modify the registry key
Disabling PPL requires physical access to the machine's firmware
Kernel-level drivers cannot simply toggle the protection off
This is the configuration you will encounter on hardened enterprise workstations

Credential Guard

What is Credential Guard?

Introduced in Windows 10 Enterprise, Credential Guard uses Virtualization-Based Security (VBS) to isolate secrets from the rest of the OS. Even if an attacker dumps LSASS memory completely, they won't find usable NTLM hashes or Kerberos tickets, those secrets now live in a separate, hardware-isolated virtual machine called the Secure World.

How it works

Normal World (Windows OS)          Secure World (VSM/VBS)
─────────────────────────          ─────────────────────
lsass.exe                    ←──── LSAIso.exe (isolated)
  ↓ requests credentials           ↓ stores actual secrets
  ← receives opaque blobs          NTLM hashes, TGTs, etc.

LSASS in the normal world only holds opaque references , the actual credentials never leave the Secure World. A memory dump of lsass.exe will only yield encrypted blobs that are useless without the Secure World's keys.

What Credential Guard protects against

Attack	Protected?
LSASS memory dump	✅ Yes, only opaque blobs
Pass-the-Hash (NTLM)	✅ Yes, hash never exposed
Pass-the-Ticket (Kerberos)	✅ Yes, TGT isolated
Cached credentials (MSCache2)	❌ No, still in SAM/SECURITY hive
Cleartext passwords via WDigest	✅ Yes, blocked by default

Checking Credential Guard status

# Check VBS / Credential Guard status
Get-ComputerInfo | Select-Object -Property DeviceGuard*

# Or via msinfo32
msinfo32 → System Summary → Virtualization-based security

Common Techniques

Here are some of the most common methods to dump LSASS memory, and when they work.

1. Task Manager (The GUI Way)

The simplest, but least stealthy way to dump LSASS is via the Windows Task Manager.

Open Task Manager (Ctrl + Shift + Esc).
Navigate to the Details tab.
Locate lsass.exe.
Right-click and select Create dump file.

This will create a .dmp file (typically in %temp%), which you can download and parse offline using tools like Mimikatz or Pypykatz.

⚠️ Blocked by: PPL (any level), most EDRs, Credential Guard (dump succeeds but yields no usable credentials)

2. Procdump (Sysinternals)

Procdump is a legitimate Microsoft Sysinternals tool, which means it often bypasses basic AV detections (though modern EDRs are very aware of it).

# Dump LSASS memory to a file named lsass.dmp
procdump.exe -accepteula -ma lsass.exe lsass.dmp

⚠️ Blocked by: PPL (any level), EDR hooks on MiniDumpWriteDump

3. Comsvcs.dll (Living off the Land)

A stealthier "Living off the Land" (LotL) technique uses the built-in comsvcs.dll. By calling the MiniDump exported function via rundll32.exe, we can dump the process memory without dropping any external binaries.

First, you need the Process ID (PID) of LSASS:

tasklist /FI "IMAGENAME eq lsass.exe"

Then, use rundll32 to dump it:

# Assuming the PID of lsass is 680
rundll32.exe C:\Windows\System32\comsvcs.dll, MiniDump 680 C:\temp\lsass.dmp full

⚠️ Blocked by: PPL (any level), EDR hooks

Bypassing PPL, BYOVD and Beyond

When LSASS runs under PPL, all userland techniques fail regardless of privilege level. The attack surface shifts to the kernel.

The BYOVD Approach (Bring Your Own Vulnerable Driver)

The idea is simple: load a legitimate, signed kernel driver that contains a vulnerability allowing arbitrary memory reads. Because the driver is signed, Windows loads it into Ring 0 (Kernel Mode). PPL is strictly a user-mode (Ring 3) enforcement mechanism, once execution transitions to kernel space, PPL restrictions simply do not apply, and the driver can read the physical memory of any process.

The classic example was PROCEXP152.sys (Process Explorer driver), used by tools like PPLBlade. However, Microsoft has since revoked the certificate of the vulnerable version, making it unusable on up-to-date systems.

PPLBlade.exe --mode collect --name lsass.exe --handle extended
→ [FAIL] A certificate was explicitly revoked by its issuer

This is an ongoing cat-and-mouse game. Each time a vulnerable driver gets abused, Microsoft adds it to the vulnerable driver blocklist, and researchers find the next one.

KslDump, Abusing Windows Defender's Own Driver

The Discovery

In an elegant twist, a vulnerable driver was found not in a third-party tool, but in Windows Defender itself: KslD.sys, the Kernel Shim Library Driver.

Microsoft patched the actively running instance (\drivers\wd\KslD.sys) by nulling out MmCopyMemory, but left an older, unpatched version sitting on disk at C:\Windows\System32\drivers\KslD.sys.

# Patched version (active, used by Defender)
(Get-Item "C:\Windows\System32\drivers\wd\KslD.sys").Length
# → ~83008 bytes (82KB), MmCopyMemory nulled out

# Vulnerable version (sitting on disk, unused)
(Get-Item "C:\Windows\System32\drivers\KslD.sys").Length
# → ~333216 bytes (333KB), MmCopyMemory fully functional

The patch was released in October 2025, but the vulnerable version remains on disk on many systems and has been observed on multiple engagements.

How KslD.sys Works

KslD.sys exposes a device handle that allows trusted processes to call MmCopyMemory, a kernel function that reads physical memory, bypassing all userland protections including PPL.

The only access control is a process name stored in a registry key:

HKLM\SYSTEM\CurrentControlSet\Services\KslD\AllowedProcessName
→ \Device\HarddiskVolume3\ProgramData\Microsoft\Windows Defender\...\MsMpEng.exe

This key is modifiable by any local administrator, no signature verification, no integrity check.

The Attack Chain

1. Confirm vulnerable KslD.sys is present (~333KB)
2. Save the original AllowedProcessName value
3. Replace it with our process path (Python interpreter)
4. Restart KslD service → driver reloads the registry value
5. Run KslDump → Python now has access to the device handle
6. KslDump uses MmCopyMemory to read LSASS physical memory
7. PPL is entirely bypassed, memory read at kernel level
8. NT hashes extracted and displayed
9. Restore original AllowedProcessName
10. Restart KslD → Defender resumes normal operation

The Tool, KslDump

The tool that automates this entire chain is KslDump by andreisss

KslDump is a Python-based tool that wraps the entire attack chain into a single command. Under the hood, it:

Checks for the vulnerable KslD.sys on disk and validates its size
Backs up the original AllowedProcessName registry value
Overwrites it with the path to the Python interpreter running the script
Restarts the KslD service so the driver reloads the registry
Opens a handle to the KslD device and calls MmCopyMemory to walk LSASS physical memory pages
Parses the dumped memory to locate and decrypt NT hashes using the LSA encryption keys
Restores the original registry value and restarts the service, leaving the system clean

Expected Output

[*] Windows Build 26100
[*] Setting up KslD...
[*] KASLR bypass (SubCmd 2)...
[*] Finding lsass.exe... PID=1392
[*] Finding lsasrv.dll...
[*] Extracting LSA keys...
[*] Extracting credentials...

[+] 4 credential(s) extracted:

DOMAIN\username
  NT: <hash>

[*] Restoring registry...

Limitations

Requires local administrator privileges
Requires the vulnerable KslD.sys (~333KB) to be present on disk
Does not bypass Credential Guard, if VBS is active, credentials in LSASS are opaque blobs
Patched by Microsoft in October 2025, but the vulnerable file remains on disk on many systems

The other older drivers in C:\Windows\WinSxS\ may also retain exploitable versions of similar functionality, worth investigating on hardened systems where the main KslD.sys has been cleaned up.

What Happens When LSASS is Protected by Both PPL and Credential Guard?

Protection	Bypassed by KslDump?	Result
No protection	✅	Full NT hashes
PPL only	✅	Full NT hashes
Credential Guard only	✅ (dump succeeds)	Opaque blobs, unusable
PPL + Credential Guard	✅ (dump succeeds)	Opaque blobs, unusable
PPL + Credential Guard + patched KslD.sys	❌	No viable path via LSASS

💡 Worth Noting: If PPL and Credential Guard are enabled without a UEFI lock (at the BIOS/firmware level), an attacker with local administrator or SYSTEM privileges can simply modify the registry keys to disable them, force a reboot, and then dump LSASS normally on the next boot. However, this is rarely an ideal solution for an attacker: rebooting the system clears volatile memory. All credentials and Kerberos tickets currently stored in LSASS will be wiped, meaning the attacker will have to wait for an administrator to log back in before they can harvest anything useful.

When both protections are active, pivot away from LSASS entirely:

MSCache2 hashes from the SECURITY hive (crackable offline, not PTH-able)
Kerberos tickets via Rubeus if a session exists
DPAPI blobs if the user has an interactive session
DCSync if you have replication rights on the domain

Bypassing EDRs

Modern Endpoint Detection and Response (EDR) solutions hook APIs like ReadProcessMemory and MiniDumpWriteDump to detect these activities.

To bypass them, attackers often use:

Direct System Calls: Bypassing user-land API hooks by calling the kernel directly.
Custom Dumpers: Writing custom code to read memory stealthily.
Kernel Drivers (BYOVD): Using a vulnerable signed driver to read memory from kernel-space, bypassing all userland hooks entirely, as demonstrated with KslDump above.

Conclusion

Dumping LSASS remains a critical technique in Red Teaming, but the landscape has shifted dramatically. Whereas a few years ago procdump lsass.exe would reliably yield credentials, modern hardened environments combine PPL, Credential Guard, UEFI locks, and EDR hooks into a layered defense that makes direct LSASS access increasingly difficult.

KslDump represents the current frontier: abusing Microsoft's own signed drivers to read physical memory from kernel space, neatly sidestepping PPL. But it too has a shelf life, Microsoft patched the active driver in October 2025, and the vulnerable on-disk copy will eventually be cleaned up.

The takeaway for Red Teamers: LSASS is one source of credentials, not the only one. When direct dumping is blocked, the pivot to MSCache2, DPAPI, Kerberos tickets, or DCSync is often just as productive, and frequently less detected.

Happy hunting! (Ethically, of course.)