LSASS and Credential Storage

What LSASS stores and why attackers want it

When a user logs into a Windows machine — interactively at the console, via RDP, or through a network logon — the authentication credentials are processed by LSASS. Depending on the authentication protocol, LSASS stores different credential material in its process memory.

NTLM authentication stores the NT hash — the MD4 hash of the Unicode password — in LSASS memory. This hash is used for subsequent challenge-response authentication. The critical point: the NT hash is sufficient for authentication without knowing the plaintext password. An attacker who extracts the NT hash can pass-the-hash to authenticate as that user to any system that accepts NTLM — which includes most Windows file shares, many web applications using Windows Integrated Authentication, and RDP with specific configurations.

Kerberos authentication stores Ticket-Granting Tickets (TGTs) and service tickets in LSASS memory. A TGT can request service tickets for any service the user has access to. An attacker who extracts a TGT can pass-the-ticket to access resources as that user — including services on remote systems — without ever knowing the password. TGTs have a default lifetime of 10 hours, so a dump captured within that window provides immediate access.

Cached domain credentials in DCC2 format are stored so domain-joined laptops can authenticate when disconnected from the domain controller. By default, Windows caches the last 10 domain logons. These cached credentials cannot be used for pass-the-hash but can be cracked offline using hashcat or John the Ripper — the DCC2 algorithm is slower to crack than NTLM but still feasible for weak passwords.

The compound risk is what makes LSASS the highest-value target on any endpoint. On a shared workstation where multiple users have logged in, LSASS contains credentials for all of them. A domain admin who logged into a workstation to troubleshoot an issue leaves their domain admin NTLM hash in LSASS memory until the machine reboots. The attacker who compromises that workstation and dumps LSASS obtains domain admin credentials — not because the admin was targeted, but because they happened to log into the wrong machine at some point in the past. The credentials persist regardless of how long ago the admin logged in. A domain admin who authenticated three weeks ago and has not touched the machine since still has their hash cached in LSASS if the machine has not rebooted — and modern Windows devices with fast startup enabled may go months without a full reboot.

Logon types and credential exposure

Not every remote access method exposes credentials equally. Understanding this determines which administration methods are safe and which leave credentials on every device the admin touches.

Remote Desktop (RDP) caches both the NT hash and the Kerberos TGT on the remote host. If the admin disconnects without logging off — closing the RDP window instead of clicking Sign out — the TGT remains in memory on the remote host indefinitely until the machine reboots. This makes standard RDP the most dangerous remote administration method from a credential exposure perspective. The mitigation: RDP with RestrictedAdmin mode prevents the admin's credentials from being cached on the remote host. Network logons (Type 3) — used by file share access, PsExec's initial SMB connection, WMI remote commands, PowerShell remoting — do not cache NT hashes or TGTs on the remote host. The credentials are used for the authentication handshake but not stored in the remote system's LSASS memory. This is the safest administration method.

RunAs with interactive logon (right-click → Run as administrator, or runas /user:domain\admin cmd.exe) caches both the NT hash and TGT on the local host. When the elevated application is closed, the cached credentials may persist in memory — they are not reliably cleaned up until the host reboots. An admin who opens one elevated prompt for five minutes may leave domain admin credentials cached for days.

The operational takeaway: domain admin accounts should never log into workstations interactively or via standard RDP. All privileged administration should use Network logon (PowerShell remoting, WMI) or RDP with RestrictedAdmin mode from a dedicated admin jump server. This single policy change eliminates the most common credential exposure scenario — the domain admin who RDPs to a user's workstation to troubleshoot an issue and leaves their credentials cached on a device that may already be compromised.

At NE, this is exactly what happened. The IT support technician m.chen RDP'd to DESKTOP-NGE042 two days before the CHAIN-ENDPOINT compromise. The standard RDP session cached m.chen's NTLM hash and Kerberos TGT in LSASS on that endpoint. When the attacker dumped LSASS, they obtained m.chen's credentials — which provided access to the IT administration jump server because m.chen was a member of the IT Admins group. The local administrator hash from the same dump was identical on all 865 endpoints because LAPS was not deployed. The svc-sccm service account hash provided access to the SCCM infrastructure. One LSASS dump on one machine yielded credentials for lateral movement to hundreds of systems.

This is the scenario that LAPS prevents for the local admin hash and that credential tiering prevents for domain admin exposure. If LAPS had been deployed, the local admin hash from DESKTOP-NGE042 would be unique to that machine — valid on zero other endpoints. If m.chen had used PowerShell remoting (Network logon) instead of RDP, their credentials would not have been cached on the target. If a tiered admin model restricted domain admin logon to domain controllers only, no domain admin hash would ever appear in a workstation's LSASS. Each policy change independently reduces the blast radius of a single LSASS dump from "entire environment" to a scoped, containable compromise.

What LSASS credential access looks like in the evidence

Before examining the extraction tools, you need to recognize what LSASS access looks like in the raw telemetry — the evidence that the ASR rule, PPL, and detection rules all key on.

Log Name:      Microsoft-Windows-Sysmon/Operational
Source:        Microsoft-Windows-Sysmon
Event ID:      10
Task Category: Process accessed (rule: ProcessAccess)
Level:         Information
Computer:      DESKTOP-NGE042.northgate.local
Description:
  RuleName:      technique_id=T1003.001,technique_name=LSASS Memory
  UtcTime:       2026-02-14 09:22:17.503
  SourceProcessGuid: {a23f8c41-8a31-67ae-1000-000000004600}
  SourceProcessId:   9104
  SourceImage:   C:\Windows\System32\rundll32.exe
  TargetProcessGuid: {a23f8c41-0001-67ae-0300-000000004600}
  TargetProcessId:   712
  TargetImage:   C:\Windows\System32\lsass.exe
  GrantedAccess: 0x1010
  CallTrace:     C:\Windows\SYSTEM32\ntdll.dll+a2f14|...|
                 C:\Windows\System32\comsvcs.dll+48c0e

This Sysmon Event ID 10 captures the exact moment of LSASS credential access. The SourceImage is rundll32.exe — the LOLBin used by the comsvcs.dll MiniDump technique. The TargetImage is lsass.exe. The GrantedAccess 0x1010 is PROCESS_VM_READ | PROCESS_QUERY_LIMITED_INFORMATION — the minimum access rights needed to read LSASS memory. The CallTrace shows comsvcs.dll in the call stack, confirming the MiniDump technique. Every field in this record maps to an OS concept from this section: the SourceImage is the attacking process, the TargetImage is LSASS, the GrantedAccess is the handle permission the ASR rule blocks, and the CallTrace reveals which code performed the access. This is the evidence that the ASR rule prevents from ever being generated — with the rule in block mode, the handle is denied and no Event ID 10 is recorded because the access never occurs.

The three extraction methods

Credential extraction from LSASS follows a consistent pattern at the OS level: open a handle to the LSASS process with memory read permissions, read the process memory, parse the memory structures to extract credential material. The tools differ in implementation but the OS-level operations are the same — which is why the defensive controls target the handle acquisition step rather than individual tools. A defense that blocks Mimikatz by name is an AV signature. A defense that blocks any non-Microsoft process from opening LSASS with PROCESS_VM_READ access is an architectural control that works against any tool, including ones that do not exist yet.

Mimikatz opens a handle to LSASS with PROCESS_VM_READ and PROCESS_QUERY_INFORMATION access, reads the memory regions containing credential structures, and parses them using knowledge of undocumented LSASS internal data structures. MDE has built-in detections for Mimikatz based on behavioral patterns and known binary signatures. Custom detections catch Mimikatz by monitoring for processes that open LSASS with the specific access rights combination that credential dumping requires.

comsvcs.dll MiniDump is a LOLBin technique that avoids dropping Mimikatz to disk. The command: rundll32.exe C:\Windows\System32\comsvcs.dll, MiniDump [LSASS PID] C:\temp\dump.bin full. Comsvcs.dll is a legitimate Windows DLL that exports a MiniDump function. The attacker creates a full memory dump of LSASS, then transfers the dump file offline for analysis. The command line is distinctive and a KQL detection rule matching this pattern is straightforward and high-fidelity.

Procdump from Sysinternals creates process memory dumps. Because Procdump is a signed Microsoft binary, it may bypass AV detections that trigger on unsigned executables accessing LSASS. Some attackers rename procdump.exe to evade command-line detections, but the binary's hash remains the same and MDE's file hash analysis identifies renamed Sysinternals tools.

# Check your LSASS protection status — all 3 controls
# 1. RunAsPPL
$ppl = Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" `
    -Name "RunAsPPL" -ErrorAction SilentlyContinue
if ($ppl.RunAsPPL -eq 1) { "RunAsPPL: ENABLED" } else { "RunAsPPL: NOT ENABLED" }
# 2. Credential Guard
$dg = Get-CimInstance -ClassName Win32_DeviceGuard `
    -Namespace root\Microsoft\Windows\DeviceGuard -ErrorAction SilentlyContinue
if ($dg.SecurityServicesRunning -contains 1) { "Credential Guard: RUNNING" }
else { "Credential Guard: NOT RUNNING" }
# 3. LSASS ASR rule (GUID: 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2)
$asr = Get-MpPreference
$idx = [array]::IndexOf($asr.AttackSurfaceReductionRules_Ids,
    "9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2")
if ($idx -ge 0) {
    switch ($asr.AttackSurfaceReductionRules_Actions[$idx]) {
        0 {"LSASS ASR: DISABLED"} 1 {"LSASS ASR: BLOCK"}
        2 {"LSASS ASR: AUDIT"} 6 {"LSASS ASR: WARN"}
    }
} else { "LSASS ASR: NOT CONFIGURED" }

Run this on any endpoint. For each "NOT ENABLED" or "NOT CONFIGURED" result, you have identified a gap in LSASS protection. At NE, all three return the unprotected result — which is why the comsvcs.dll dump in CHAIN-ENDPOINT succeeded in under three seconds.

The four defensive controls — layered and independent

The four LSASS controls each defend at a different level and each fails independently of the others. This is genuine defense in depth.

ASR rule "Block credential stealing from LSASS" (GUID: 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2) blocks non-Microsoft processes from opening a handle to LSASS with memory read access rights. When enabled in block mode, the handle acquisition step fails before the attacker reads any memory. The rule allows Microsoft-signed processes to access LSASS because Windows itself needs LSASS interaction for normal authentication. Blast radius is low — very few legitimate non-Microsoft applications need LSASS handles. This is the fastest control to deploy and has the highest prevention-to-disruption ratio of any single endpoint security control.

RunAsPPL (Protected Process Light) configures LSASS to run as a PPL process via the registry key HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL = 1. Only processes signed with a Windows TCB (Trusted Computing Base) code signing certificate can open handles to PPL-protected processes. Since attacker tools are not signed with Microsoft certificates, they cannot open handles to LSASS even with administrative privileges. Bypass requires a BYOVD attack using a vulnerable signed driver to patch the PPL protection in kernel memory — significantly raising the bar from "run Mimikatz" to "find and exploit a kernel vulnerability."

Credential Guard uses virtualization-based security to isolate LSASS secrets in a separate virtual trust level called the Isolated LSA (LSAIso). The main LSASS process runs normally but the actual credential material — NTLM hashes, Kerberos keys — is stored in LSAIso, inaccessible from the main OS even to processes running as SYSTEM with kernel-mode access. Starting with Windows 11 22H2, Credential Guard is enabled by default on devices that meet the hardware requirements (VBS, UEFI Secure Boot, TPM) without UEFI Lock so administrators can disable it remotely if compatibility issues arise. On NE's Windows 11 23H2 fleet, Credential Guard is likely already active — the engineering task is verification and compatibility management, not deployment from scratch.

MDE behavioral detection monitors LSASS access patterns: processes opening handles with suspicious access rights, memory reads, and dump file creation. This is a detection control, not prevention — it fires after the access attempt. Its value: catching extraction attempts that bypass the prevention controls or alerting in environments where prevention controls are still in audit mode.

The four controls are layered. Each addresses a different attacker sophistication level. If the attacker uses a standard tool like Mimikatz or comsvcs.dll — ASR blocks the handle acquisition before any memory is read. If the attacker uses a custom tool that bypasses ASR through a valid code signing certificate — RunAsPPL blocks the handle because the certificate is not a Windows TCB certificate. If the attacker bypasses both ASR and PPL using a kernel exploit or BYOVD attack — Credential Guard ensures the dump contains no useful credential material because the secrets are isolated in LSAIso. If all three prevention and isolation controls fail — MDE behavioral detection alerts the SOC with a high-severity credential theft alert. The failure mode of each control is different, which is why layering them provides genuine defense in depth rather than redundancy. Deploying only one leaves a single-point-of-failure that a moderately skilled attacker can bypass.

// Detect LSASS credential dumping — comsvcs.dll MiniDump pattern
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName =~ "rundll32.exe"
| where ProcessCommandLine has_all ("comsvcs", "MiniDump")
| project Timestamp, DeviceName, AccountName,
    InitiatingProcessFileName, ProcessCommandLine
| sort by Timestamp desc

If this query returns results, someone has used comsvcs.dll to dump process memory — almost always either a penetration test or an active compromise. The ASR LSASS rule in block mode prevents this technique. The KQL detection catches it when the ASR rule is in audit mode or not configured. Both defend the same OS mechanism — the handle acquisition to LSASS — from different layers of the stack.