ES1.2 LSASS and Credential Storage

What LSASS actually stores and why attackers want it

When a user logs into a Windows machine — whether 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 (MD4 hash of the Unicode password) in LSASS memory. This hash is used for subsequent NTLM 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 authentication — which includes most Windows file shares, RDP (with specific configurations), and many web applications that use Windows Integrated Authentication.

Kerberos authentication stores Ticket-Granting Tickets (TGTs) and service tickets in LSASS memory. A TGT can be used to request service tickets for any service the user has access to. An attacker who extracts a TGT can pass-the-ticket to obtain service tickets and access resources as that user — including services on remote systems — without ever knowing the password.

Cached domain credentials (DCC2 format) are stored so that domain-joined laptops can authenticate when disconnected from the domain controller. By default, Windows caches the last 10 domain logons. These cached credentials are hashed with a stronger algorithm than NTLM (MS-Cache v2 / DCC2) and cannot be used for pass-the-hash, but they can be cracked offline using hashcat or John the Ripper.

The compound risk: on a shared workstation where multiple users have logged in, LSASS contains credentials for ALL of those users. A domain admin who logged into a workstation to troubleshoot an issue leaves their domain admin NTLM hash in LSASS memory. 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.

Which logon types cache which credentials — and the defensive implications. Not every remote access method exposes credentials equally. Understanding this determines which administration methods are safe and which leave credentials exposed 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 (a common pattern — closing the RDP window instead of clicking Start > Sign out), the TGT remains in memory on the remote host indefinitely. 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. Enable it via reg add HKLM\System\CurrentControlSet\Control\Lsa /v DisableRestrictedAdmin /t REG_DWORD /d 0 on admin workstations.

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 are not stored in the remote system’s LSASS memory. This is the safest remote administration method — ironically, it is also the transport mechanism that PsExec and WMI use for lateral movement. The attacker uses stolen credentials over a network logon, which does not leave additional credentials on the target (preventing a credential chain reaction), but does provide access to the target system.

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. Critically, when the application launched with RunAs is closed, the cached NT hash and TGT may persist in memory — they are not reliably cleaned up until the host reboots. An admin who opens a single elevated command prompt and closes it five minutes later may leave their domain admin credentials cached for days until the next reboot.

Remote Assistance does NOT cache credentials on the remote host — making it safe for help desk scenarios where a privileged user assists on a potentially compromised workstation.

The operational takeaway for NE: domain admin accounts should never log into workstations interactively or via standard RDP. All domain admin activity should use either 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 domain admin credentials cached on a device that may already be compromised.

The three extraction methods

Credential extraction from LSASS follows a consistent pattern: 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 how they implement each step, but the OS-level operations are the same.

Mimikatz (sekurlsa::logonpasswords). The most well-known credential extraction tool. 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 the undocumented LSASS internal data structures. Mimikatz can extract NTLM hashes, Kerberos tickets, plaintext passwords (when WDigest authentication stores them — disabled by default since Windows 8.1), and cached credentials. Detection: MDE has built-in detections for Mimikatz based on its behavioral patterns and known binary signatures. Custom detections can also catch Mimikatz by monitoring for processes that open LSASS with the specific access rights combination.

comsvcs.dll MiniDump (via rundll32). 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 (COM+ Services) that exports a MiniDump function. The attacker calls this function to create a full memory dump of LSASS, then transfers the dump file offline for analysis with Mimikatz. Detection: the command line is distinctive — rundll32 loading comsvcs.dll with the MiniDump export name and a PID argument. MDE and Sysmon both capture this command line. A KQL detection rule matching this pattern is straightforward and high-fidelity.

Procdump (from Sysinternals). A legitimate Microsoft debugging tool that can create process memory dumps. The command: procdump.exe -ma lsass.exe dump.dmp. Because Procdump is a signed Microsoft binary, it may bypass AV detections that trigger on unsigned executables accessing LSASS. Detection: Procdump targeting LSASS is suspicious regardless of the binary’s legitimacy. The command line (procdump + lsass target) is the detection point. Some attackers rename procdump.exe to evade command-line detections — but the binary’s hash remains the same, and MDE’s file hash analysis can identify renamed Sysinternals tools.

The four defensive controls for LSASS

Control 1: ASR rule “Block credential stealing from LSASS” (GUID: 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2). This rule blocks non-Microsoft processes from opening a handle to LSASS with the access rights needed for memory reading. When enabled in block mode, the handle acquisition step fails — the attacker’s tool (Mimikatz, custom dumper) cannot obtain a handle to LSASS and the credential extraction cannot proceed. The rule allows Microsoft-signed processes to access LSASS (because Windows itself needs to interact with LSASS for normal authentication operations). Blast radius: low — very few legitimate non-Microsoft applications need to open handles to LSASS. False positive sources: some legacy security products, custom authentication providers, and certain debugging tools. This is the fastest control to deploy and has the highest prevention-to-disruption ratio of any single endpoint security control.

Control 2: RunAsPPL (Protected Process Light). Configuring LSASS to run as a PPL process (registry key: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL = 1) restricts which processes can open handles to LSASS based on their signing level. Only processes signed with a Windows or 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: BYOVD attacks using a vulnerable signed driver to patch the PPL protection in kernel memory. This bypass requires kernel-level access, significantly raising the bar.

Control 3: Credential Guard. Starting with Windows 11 22H2 and Windows Server 2025, 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 needed. Since NE’s fleet is Windows 11 23H2, Credential Guard is likely already active on most endpoints. The engineering task is verification (confirm it is running) and compatibility management (identify applications affected by the default enablement), not deployment from scratch. Credential Guard uses virtualization-based security (VBS) to isolate LSASS secrets in a separate virtual machine called the Isolated LSA (LSAIso). The main LSASS process runs normally but the actual credential material (NTLM hashes, Kerberos keys) is stored in LSAIso, which is inaccessible from the main OS — even to processes running as SYSTEM with kernel-mode access. An attacker who dumps LSASS memory when Credential Guard is enabled obtains a dump that does not contain the credential material — it has been moved to a location that the main OS cannot read. Bypass: compromising the hypervisor itself (extremely difficult) or finding vulnerabilities in the LSAIso boundary (rare, high-severity, rapidly patched).

Control 4: MDE behavioral detection. MDE monitors for LSASS access patterns: processes that open handles to LSASS with suspicious access rights, processes that read LSASS memory, and processes that create LSASS memory dumps. This is a detection control, not a prevention control — it fires after the access attempt occurs. Its value is in catching credential extraction attempts that bypass the prevention controls (ASR, PPL, Credential Guard) or in environments where the prevention controls are in audit mode rather than block mode.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

# Check RunAsPPL status
$ppl = Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "RunAsPPL" -ErrorAction SilentlyContinue
if ($ppl.RunAsPPL -eq 1) { "RunAsPPL: ENABLED" } else { "RunAsPPL: NOT ENABLED" }

# Check Credential Guard status
$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" }

# Check LSASS ASR rule status
$asr = Get-MpPreference
$lsassRuleId = "9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2"
$idx = [array]::IndexOf($asr.AttackSurfaceReductionRules_Ids, $lsassRuleId)
if ($idx -ge 0) {
    $action = $asr.AttackSurfaceReductionRules_Actions[$idx]
    switch ($action) { 0 {"LSASS ASR: DISABLED"} 1 {"LSASS ASR: BLOCK MODE"} 2 {"LSASS ASR: AUDIT MODE"} 6 {"LSASS ASR: WARN MODE"} }
} else { "LSASS ASR: NOT CONFIGURED" }

Troubleshooting

“We enabled the LSASS ASR rule in block mode and our AV product stopped working.” Some third-party AV products access LSASS for their own security monitoring. The ASR rule blocks non-Microsoft processes from accessing LSASS. If your environment still has a third-party AV product installed alongside Defender (which should not be the case in an MDE environment — MDE replaces third-party AV), the third-party AV’s LSASS access will be blocked. The solution: remove the third-party AV and rely on MDE. If the third-party AV is required for regulatory reasons, create a process exclusion for the specific AV executable in the ASR rule configuration.

“We deployed Credential Guard but now our legacy application that uses NTLM authentication fails.” Credential Guard prevents NTLM credential delegation to servers that require it. Applications that rely on NTLMv1 or NTLM credential delegation will fail. The solution is not to disable Credential Guard — it is to migrate the legacy application to Kerberos authentication or to upgrade the application to support NTLMv2 without credential delegation. If the legacy application cannot be migrated, exclude those specific devices from the Credential Guard deployment until the application is updated.