Overview

LSASS Memory dumping (T1003.001) is a credential theft technique where attackers extract authentication material — including NTLM hashes, Kerberos tickets, and in some configurations cleartext passwords — directly from the memory of the Windows Local Security Authority Subsystem Service (lsass.exe). Because LSASS holds credentials for every interactively logged-on user, a successful dump hands the attacker the keys to move laterally across the environment using pass-the-hash, pass-the-ticket, or direct credential replay.

This technique sits at the heart of nearly every significant Windows intrusion chain, from ransomware operations to nation-state espionage campaigns. Because it can be executed with tools that are either built into Windows or trivially downloaded, and because the credentials it yields are immediately usable, detection of LSASS access is a non-negotiable baseline for any SOC defending a Windows environment.

Attacker Perspective

After gaining local administrator or SYSTEM privileges on a Windows host, attackers target LSASS to harvest credentials that enable movement to higher-value systems without needing to crack a single password.

• Mimikatz (interactive or via Cobalt Strike): The attacker runs sekurlsa::logonPasswords directly against live LSASS memory, extracting NTLM hashes and, on misconfigured systems, cleartext Wdigest passwords in seconds.
• ProcDump abuse: Using the Microsoft-signed Sysinternals tool with procdump.exe -ma lsass.exe lsass.dmp, attackers create a full minidump that can be exfiltrated and parsed offline, reducing on-host tool exposure time.
• Built-in comsvcs.dll: A fully living-off-the-land approach using rundll32.exe C:\Windows\System32\comsvcs.dll MiniDump <PID> lsass.dmp full — no third-party binaries required, making it harder to block by application allowlisting alone.
• Silent Process Exit / WerFault abuse: By manipulating the Windows Error Reporting silent process exit mechanism, attackers force Windows itself to generate an LSASS dump via WerFault.exe, further obscuring the activity behind a legitimate system process.

LSASS dumping is attractive precisely because it is fast, yields immediately usable credentials, and can be accomplished with signed Microsoft binaries that are difficult to block without breaking legitimate functionality.

Detection Strategy

Required Telemetry

• Windows Security Event Log — Process Creation (Event ID 4688): Enable via GPO: Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → Detailed Tracking → Audit Process Creation → Success. Also enable command-line logging: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit → ProcessCreationIncludeCmdLine_Enabled = 1. Without command-line logging, you see the process but not the arguments used.
• Sysmon Event ID 1 (Process Create): Deploy Sysmon with a tuned configuration (SwiftOnSecurity or Olaf Hartong baseline recommended). Sysmon captures fuller command lines, hashes, and parent-child relationships more reliably than native 4688 logging. Sysmon Event ID 10 (Process Access) is specifically critical — it fires when any process opens a handle to another process, and is the most direct signal for in-memory LSASS access.
• Sysmon Event ID 10 (Process Access): This event fires when one process opens a handle to another. Confirm it is enabled in your Sysmon config under the ProcessAccess rule group. Without this, direct memory-read attacks (e.g., Mimikatz against live LSASS) are invisible at the host level.
• Sysmon Event ID 11 (File Create): Captures creation of dump files (e.g., .dmp, .bin) to disk. Ensure the FileCreate rule group is enabled and targets common dump file extensions and paths.
• Windows Security Event ID 4656 / 4663 (Object Access — Process): Enable via GPO: Advanced Audit Policy → Object Access → Audit Kernel Object → Success/Failure. These events log handle requests to protected objects including processes. Note: these are very high volume and typically require filtering at the SIEM layer.
• Windows Defender / Microsoft Defender for Endpoint (MDE) Alerts: MDE has built-in detections for LSASS access attempts and will generate alerts under the CredentialAccess category. If MDE is deployed, these alerts should feed your SIEM and be treated as high-fidelity starting points.
• Windows Security Event ID 4624 / 4625 (Logon Events): Enable via Advanced Audit Policy → Logon/Logoff → Audit Logon → Success and Failure. Used in the post-dump phase to detect pass-the-hash (look for Type 3 network logons with NTLM from unusual sources).
• EDR Telemetry (CrowdStrike, SentinelOne, Carbon Black, etc.): If an EDR is deployed, its process injection and credential access telemetry should be your primary detection layer. Ensure alerts are forwarded to your SIEM. EDR process access events are more reliable than Sysmon for detecting sophisticated evasion attempts.
• Windows Registry Auditing (for SSP persistence): Enable object access auditing on HKLM\SYSTEM\CurrentControlSet\Control\Lsa via Group Policy or registry-based auditing. Sysmon Event ID 13 (Registry Value Set) with target path matching Lsa\Security Packages or Lsa\OSConfig\Security Packages will detect SSP DLL additions.

Key Indicators

• Direct LSASS handle open (Sysmon Event ID 10): TargetImage = C:\Windows\System32\lsass.exe AND GrantedAccess contains 0x1010, 0x1410, 0x147a, or 0x1fffff. These access rights include PROCESS_VM_READ and PROCESS_QUERY_INFORMATION, which are required to read LSASS memory. Legitimate callers are few (AV, EDR, WER); anything else warrants scrutiny.
• ProcDump invocation against LSASS (Event ID 4688 / Sysmon Event ID 1): CommandLine matches pattern procdump* lsass* or procdump* -ma*. Look for Image = procdump.exe or procdump64.exe. Note: ProcDump is a signed Microsoft binary — the command-line argument is what makes it malicious here.
• comsvcs.dll MiniDump invocation (Event ID 4688 / Sysmon Event ID 1): CommandLine matches rundll32*comsvcs*MiniDump* or rundll32*comsvcs*full*. The ParentImage in malicious use is often cmd.exe, powershell.exe, or a remote shell process rather than a legitimate Windows service.
• Dump file written to disk (Sysmon Event ID 11): TargetFilename ends with .dmp AND the creating Image is one of: rundll32.exe, powershell.exe, cmd.exe, WerFault.exe, or an unexpected user-space process. Legitimate crash dumps are typically written to C:\Windows\Minidump\ or %LOCALAPPDATA%\CrashDumps; dumps written to user-writable directories or temp paths are suspicious.
• WerFault silent-exit LSASS dump: Image = C:\Windows\System32\WerFault.exe AND CommandLine contains -p with the PID of lsass.exe, OR WerFault.exe spawned by an unusual parent such as cmd.exe or a user-mode script. Check Sysmon Event ID 1 for the parent-child chain.
• Mimikatz keyword in command line or script block (Event ID 4688 / PowerShell Event ID 4104): CommandLine or ScriptBlockText contains sekurlsa, logonPasswords, lsadump, Minidump, or mimikatz. Enable PowerShell Script Block Logging via HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging → EnableScriptBlockLogging = 1 to capture Event ID 4104.
• Suspicious SSP registry modification (Sysmon Event ID 13): TargetObject contains HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Security Packages or HKLM\SYSTEM\CurrentControlSet\Control\Lsa\OSConfig\Security Packages AND the modifying process is not a known Windows Update or domain join process.
• Task Manager or unusual process opening LSASS (Sysmon Event ID 10): SourceImage is any executable not in an expected allowlist (e.g., not your EDR agent, not MsMpEng.exe, not csrss.exe) AND TargetImage = lsass.exe.

Detection Logic

Rule 1 — Broad: Any Process Accessing LSASS Memory
IF EventID = 10 (Sysmon Process Access)
AND TargetImage ENDSWITH "lsass.exe"
AND GrantedAccess IN ("0x1010", "0x1410", "0x147a", "0x1fffff", "0x143a", "0x1438")
AND NOT SourceImage IN [known_edr_processes, "C:\Windows\System32\csrss.exe", "C:\Windows\System32\wininit.exe", "C:\Program Files\Windows Defender\MsMpEng.exe"]
THEN alert HIGH

This catches any process attempting to read LSASS memory, including in-memory tools like Mimikatz and novel dumpers. Because many legitimate security tools also open LSASS handles, expect moderate alert volume until your allowlist is tuned. Start here to build your baseline before tightening.

Rule 2 — Medium: Dump File Creation by Suspicious Processes
IF EventID = 11 (Sysmon File Create)
AND TargetFilename MATCHES "*.dmp" OR TargetFilename MATCHES "*.bin"
AND Image IN ("rundll32.exe", "powershell.exe", "cmd.exe", "WerFault.exe", "procdump.exe", "procdump64.exe")
AND NOT TargetFilename STARTSWITH "C:\Windows\Minidump\"
AND NOT TargetFilename STARTSWITH "C:\ProgramData\Microsoft\Windows\WER\"
THEN alert HIGH

This catches the on-disk artifact left by ProcDump, comsvcs.dll MiniDump, and WerFault abuse. Lower false positive rate than Rule 1 because it requires a file write. A dump file written by rundll32.exe or WerFault.exe outside of standard WER paths is almost always malicious.

Rule 3 — Precise: comsvcs.dll MiniDump Command Pattern
IF EventID IN (4688, Sysmon EventID 1)
AND Image ENDSWITH "rundll32.exe"
AND CommandLine MATCHES "*comsvcs*MiniDump*"
AND CommandLine MATCHES "*lsass*" OR CommandLine MATCHES "*full*"
THEN alert CRITICAL

This is a high-precision rule targeting the specific living-off-the-land technique. There is almost no legitimate use of rundll32.exe invoking the MiniDump export of comsvcs.dll. Expect near-zero false positives. Alert volume will be very low, but any hit should be treated as a confirmed incident until proven otherwise.

Rule 4 — Precise: Mimikatz Credential Command Keywords
IF (EventID = 4688 AND CommandLine MATCHES "*sekurlsa*" OR CommandLine MATCHES "*logonPasswords*" OR CommandLine MATCHES "*lsadump*")
OR (EventID = 4104 AND ScriptBlockText MATCHES "*sekurlsa*" OR ScriptBlockText MATCHES "*mimikatz*" OR ScriptBlockText MATCHES "*Invoke-Mimikatz*")
THEN alert CRITICAL

This catches direct Mimikatz invocations and PowerShell-wrapped variants (e.g., Invoke-Mimikatz from PowerSploit). Requires command-line logging (4688) and Script Block Logging (4104) to be enabled. False positive rate is effectively zero for the Mimikatz-specific keywords; expect no legitimate business use of sekurlsa::logonPasswords.

Tuning Guidance

• EDR and Antivirus agents: Security tools such as CrowdStrike Falcon, Carbon Black, SentinelOne, and Windows Defender (MsMpEng.exe) legitimately open LSASS handles to perform memory scanning. Build and maintain an allowlist of known EDR process paths and their expected GrantedAccess values. Exclude these from Rule 1 using SourceImage IN [edr_allowlist] — but never exclude them from logging, only from alerting.
• Windows Error Reporting (WER): The system generates legitimate crash dumps via WerFault.exe in C:\ProgramData\Microsoft\Windows\WER\ and C:\Windows\Minidump\. Exclude Rule 2 hits where TargetFilename STARTSWITH these known-good paths, but flag any WerFault.exe dump written elsewhere.
• Task Manager (taskmgr.exe): Administrators sometimes use Task Manager to create process dumps for legitimate troubleshooting. If this is a known practice in your environment, you may see taskmgr.exe triggering Rule 1 or Rule 2. Consider adding an exception scoped to SourceImage = taskmgr.exe with an accompanying requirement that the initiating user is in a named admin group, and log the activity for audit purposes.
• Sysinternals ProcDump used by IT/Ops: Some operations and dev teams use ProcDump legitimately to capture crash dumps of misbehaving applications. If ProcDump is approved in your environment, exclude procdump.exe invocations where the target is not lsass.exe — but never suppress alerts when the argument references lsass directly. Coordinate with IT to establish a formal approved-use process.
• LSAISO.exe and Credential Guard: In environments with Windows Credential Guard enabled, the Isolated LSA process (lsaiso.exe) will open handles to lsass.exe as part of normal operation. Add SourceImage ENDSWITH "lsaiso.exe" to your Rule 1 exclusion list if Credential Guard is deployed.

When the Alert Fires: Investigation Steps

1. Verify the alert is real by confirming the raw event in the source log. Navigate directly to the originating log source (Sysmon, Windows Security Event Log, or EDR console) and confirm the event exists with the expected fields — do not rely solely on the SIEM-parsed version, as field extraction errors can create false alerts. Confirm the TargetImage, SourceImage, GrantedAccess, and timestamp match what triggered the alert.
2. Identify the affected host and user account, and flag if privileged. Extract the Computer (hostname), SubjectUserName, and SubjectLogonId from the event. Cross-reference the account against your identity provider (Active Directory, Azure AD) to determine whether it is a domain admin, service account, or tier-0 asset — privilege level directly determines your escalation urgency.
3. Pull the full command-line and parent process chain for the suspicious process. Using Sysmon Event ID 1 or your EDR, retrieve the CommandLine, ParentImage, ParentCommandLine, ParentProcessGuid, and the grandparent process. A rundll32.exe spawned by cmd.exe spawned by an Office macro or a remote management tool is a very different risk profile than one spawned by a known IT automation platform.
4. Search for dump files written to disk on the affected host. Query Sysmon Event ID 11 (File Create) or your EDR’s file telemetry for .dmp, .bin, or other unusual extensions written within 10 minutes of the alert, especially in %TEMP%, C:\Users\, or network shares. Also check whether any archive or compression tool (e.g., 7z.exe, rar.exe) ran shortly after, which may indicate staging for exfiltration.
5. Check for outbound network connections from the affected host around the time of the alert. Query firewall logs, Sysmon Event ID 3 (Network Connection), or your NDR/SIEM for connections from the host within a ±30-minute window. Look for connections to unusual external IPs, large data transfers, or connections over non-standard ports — LSASS dumping is often followed quickly by credential use or exfiltration over C2.
6. Search for lateral movement originating from this host using the likely harvested credentials. Query Windows Security Event ID 4624 (Logon Type 3 — Network) across your environment for logons sourced from the compromised host’s IP, focusing on NTLM authentication (which indicates pass-the-hash). Also look for new Kerberos ticket requests (Event ID 4768/4769) from the compromised account accessing systems it does not normally reach, using your SIEM’s authentication logs.
7. Determine whether persistence was established and make the escalation decision. Check Sysmon Event ID 13 (Registry Value Set) for modifications to HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Security Packages (SSP persistence), and Event ID 12/13 for any new scheduled tasks, services, or run keys created around the same timeframe. If you confirm: (a) LSASS was accessed by an unexpected process, (b) a dump file was created or credential keywords appeared in command lines, or (c) subsequent lateral movement is detected — escalate to a confirmed incident; if the access is solely from a known tool and no other indicators exist, document and close as a tuning opportunity.

Response Playbook

Containment

• Isolate the host from the network immediately, but do not power it off. Use your EDR’s network containment feature (CrowdStrike “Network Contain”, SentinelOne “Network Quarantine”, etc.) or isolate the VLAN at the switch level. Keeping the host powered on preserves volatile memory for forensic imaging — powering it off may destroy evidence of the in-memory attack and active sessions.
• Disable the affected user account in Active Directory immediately. Use Disable-ADAccount -Identity <username> in PowerShell or the AD Users and Computers console. If the account is a service account, coordinate with the application owner before disabling, but treat the risk as urgent.
• Invalidate all active Kerberos tickets and NTLM sessions for the compromised account. Run klist purge on systems where the account is known to be logged in, and use Invoke-TGTKillSwitch or reset the account password twice (to invalidate existing Kerberos tickets) and set Revoke all sessions in Azure AD if the account is hybrid or cloud-joined.
• Block identified C2 IPs, domains, and file hashes at perimeter controls. Push any outbound IPs or domains identified in Step 5 of your investigation to your firewall, web proxy, and DNS sinkhole. Submit file hashes of identified dump tools or payloads to your EDR’s custom block list for immediate containment across all endpoints.
• Kill the malicious process if it is still running on the isolated host. Use your EDR console to terminate the offending process (by PID or image name). Document the PID, parent PID, and full path before termination for your forensic record.

Eradication

• Remove any identified persistence mechanisms. Delete rogue scheduled tasks (schtasks /delete /tn <taskname> /f), remove malicious registry run keys or SSP DLL entries from HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Security Packages, and disable or delete any unauthorized services. Re-baseline the LSA Security Packages registry value against a known-good system of the same OS version.
• Locate and delete all dropped tools and dump files. Search for .dmp files, known tool names (procdump.exe, mimikatz.exe, and renamed variants identified by hash), and staging directories on the compromised host and any network shares it had write access to. Use your EDR’s threat hunting console to search by file hash across the entire fleet.
• Perform a mandatory password reset for all accounts whose credentials may have been exposed. This includes the account that ran the dump, all accounts that had active sessions on the compromised host at the time of the attack, and any service accounts whose credentials are stored on that host. If a domain admin account was logged on to the host, treat this as a full domain credential compromise and reset all privileged accounts.
• Audit all systems that received lateral movement from this host. For every system where you detected a Type 3 logon from the compromised host (per Step 6), conduct the same investigation process — check for additional LSASS access, dropped tools, new local admin accounts, or persistence. Assume the attacker may have chained to additional hosts before you detected the initial compromise.
• Rotate any secrets, API keys, or certificates stored on or accessible from the compromised host. Check for credential stores, browser-saved passwords, application config files, and certificate stores. Rotate all identified secrets and revoke old versions immediately.

Recovery

• Re-image the compromised host before returning it to production if any uncertainty remains. If forensic analysis cannot conclusively confirm the full scope of attacker activity — or if a rootkit, kernel driver, or SSP DLL was involved — re-imaging is the only safe path. Restore from a known-good image, not a backup taken after the incident window.
• Re-enable the affected user account only after confirming no persistence remains and credentials have been reset. Have the user log in from a clean device on a clean network segment and verify multi-factor authentication is enforced on the account before restoring full access.
• Monitor the previously affected host, user account, and any lateral movement targets for a minimum of 72 hours post-remediation. Configure enhanced logging (increase verbosity, reduce SIEM aggregation thresholds) for these entities specifically and create temporary watchlist-based alerts that fire on any LSASS-related activity, new process executions, or authentication anomalies from these sources.
• Document the full attack timeline and conduct a formal lessons-learned review. Record the initial access vector (if known), the path to LSASS access, accounts compromised, systems touched, and detection gap (i.e., how long the attacker operated before detection). Share the timeline with the detection engineering team to identify rule improvements.
• Update detection rules and threat model based on new IOCs and TTPs discovered during the investigation. Add newly observed tool hashes, renamed binary paths, or novel GrantedAccess values to your detection logic. If the attacker used a technique not covered by your existing rules, build the detection before closing the incident.