Potential Credential Access via LSASS Memory Dump
Identifies suspicious access to LSASS handle from a call trace pointing to DBGHelp.dll or DBGCore.dll, which both export the MiniDumpWriteDump method that can be used to dump LSASS memory content in preparation for credential access.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2021/10/07"
3integration = ["windows"]
4maturity = "production"
5updated_date = "2026/04/27"
6
7[rule]
8author = ["Elastic"]
9description = """
10Identifies suspicious access to LSASS handle from a call trace pointing to DBGHelp.dll or DBGCore.dll, which both export
11the MiniDumpWriteDump method that can be used to dump LSASS memory content in preparation for credential access.
12"""
13from = "now-9m"
14index = ["winlogbeat-*", "logs-windows.sysmon_operational-*"]
15language = "eql"
16license = "Elastic License v2"
17name = "Potential Credential Access via LSASS Memory Dump"
18references = [
19 "https://www.ired.team/offensive-security/credential-access-and-credential-dumping/dump-credentials-from-lsass-process-without-mimikatz",
20 "https://www.elastic.co/security-labs/detect-credential-access",
21 "https://www.elastic.co/security-labs/elastic-protects-against-data-wiper-malware-targeting-ukraine-hermeticwiper",
22]
23risk_score = 73
24rule_id = "9960432d-9b26-409f-972b-839a959e79e2"
25severity = "high"
26tags = [
27 "Domain: Endpoint",
28 "OS: Windows",
29 "Use Case: Threat Detection",
30 "Tactic: Credential Access",
31 "Data Source: Sysmon",
32 "Resources: Investigation Guide",
33]
34timestamp_override = "event.ingested"
35type = "eql"
36
37query = '''
38process where host.os.type == "windows" and event.code == "10" and
39 winlog.event_data.TargetImage : "?:\\WINDOWS\\system32\\lsass.exe" and
40
41 /* dbgcore.dll hosts MiniDumpWriteDump on modern Windows; dbghelp-only traces are non-dump usage */
42 winlog.event_data.CallTrace : "*dbgcore*" and
43
44 /* crash handlers */
45 not process.executable : (
46 "?:\\Windows\\System32\\WerFault.exe",
47 "?:\\Windows\\SysWOW64\\WerFault.exe",
48 "?:\\Windows\\System32\\WerFaultSecure.exe"
49 )
50'''
51
52note = """## Triage and analysis
53
54### Investigating Potential Credential Access via LSASS Memory Dump
55
56#### Possible investigation steps
57
58- What did the process-access event prove?
59 - Focus: `winlog.event_data.SourceImage`, `winlog.event_data.SourceProcessGUID`, `winlog.event_data.TargetImage`, `winlog.event_data.GrantedAccess`, and `winlog.event_data.CallTrace`.
60 - Implication: escalate on a non-WerFault source touching LSASS with dbgcore in the call trace plus any corroborator; lower concern only when the tuple matches a stable EDR, crash-analysis, support, or authorized-test workflow on that `host.id`.
61
62- Does the source process match a recognized diagnostic tool?
63 - Focus: recover the process start on the same `host.id` using `winlog.event_data.SourceProcessGUID` or `process.entity_id`, then review `process.executable`, `process.command_line`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. $investigate_0
64 - Hint: if the source lacks `winlog.event_data.SourceProcessGUID`, fall back to `winlog.event_data.SourceImage`, `host.id`, and a tight window around `@timestamp`; if PE or signature metadata is absent, keep identity unresolved rather than inferring trust from path.
65 - Implication: escalate when the recovered source is unsigned, renamed, user-writable, or uses MiniDumpWriteDump-adjacent arguments such as ProcDump-style switches or rundll32 with comsvcs.dll; if process-start telemetry is unavailable, treat identity as unresolved and do not close on `winlog.event_data.SourceImage` alone.
66
67- Does the recovered launch chain explain why this process would touch LSASS?
68 - Focus: `process.command_line`, `process.parent.executable`, `process.parent.command_line`, `process.Ext.authentication_id`, and `user.id`; use `process.Ext.ancestry` when parent context is incomplete.
69 - Implication: escalate when shells, script hosts, Office, browsers, archive tools, or remote-admin launchers start the accessor, or when `user.id` does not fit recognized troubleshooting; record `process.Ext.authentication_id` only as a later session bridge, and treat missing lineage as unresolved rather than benign.
70
71- Do same-source file events show dump creation, rename, or staging?
72 - Focus: same-host file events for recovered `process.entity_id`, or `host.id` plus `process.pid` in a tight alert window; read `file.path`, `file.name`, `file.Ext.original.path`, and `file.size`. $investigate_1
73 - Implication: escalate when the accessor writes dump output to temp, public, user-writable, or share paths, or renames it into archives or deceptive extensions; missing file telemetry is unresolved, not benign.
74
75- Do surrounding process events show dump handling, archive, copy, or cleanup?
76 - Focus: child process starts from the recovered accessor on the same `host.id`, especially `process.parent.entity_id`, `process.executable`, `process.command_line`, and `@timestamp`. $investigate_2
77 - Hint: sibling process review remains a manual expansion from the recovered parent/session context.
78 - Implication: escalate when archivers, copy tools, PowerShell, rundll32, or cleanup commands appear immediately before or after the access; if process telemetry is sparse, preserve the gap and rely on the access tuple plus other corroborators.
79
80- Do authentication events suggest the account pivoted after the access?
81 - Why: MiniDumpWriteDump-style LSASS access is usually a precursor step; later credential use matters more than the access alone.
82 - Focus: after process recovery, use `process.Ext.authentication_id` and `host.id` to review authentication events via `winlog.event_data.TargetLogonId`; search `winlog.event_data.SubjectLogonId` separately for "4648" explicit-credential context.
83 - Hint: if the process does not preserve `process.Ext.authentication_id`, skip the auth bridge and record the gap.
84 - Implication: escalate when the linked session or `user.id` shows unexpected remote logons, explicit-credential use, or admin-share access soon after; missing authentication telemetry is unresolved, not benign.
85
86- If source identity, artifacts, or follow-on activity remain suspicious, do related alerts widen scope?
87 - Focus: related `user.id` alerts for credential access, lateral movement, privilege escalation, or suspicious authentication. $investigate_3
88 - Hint: compare `host.id` alerts to separate account reuse from host-local dump staging. $investigate_4
89 - Implication: broaden when the same user or host also triggers dumping, suspicious logon, lateral movement, or exfiltration findings; keep local when related alerts are absent.
90
91- Escalate when LSASS access plus one meaningful corroborator points to unauthorized dump preparation or credential use; close only when identity, access tuple, launch, artifacts, authentication, and scope align with one recognized benign workflow; preserve and escalate if mixed or incomplete.
92
93### False positive analysis
94
95- Recognized EDR, crash-analysis, vendor-support, or authorized testing tooling can legitimately touch LSASS through dbgcore. Close only when the alert tuple, recovered source identity, parent context, `user.id`, and `host.id` all point to that same workflow, with no contradictory dump artifact or post-access authentication evidence. Case records, inventories, and owner confirmation can corroborate but not replace the telemetry match.
96- Before exceptioning, validate recurrence for the same recovered tool identity, signer, parent context, `winlog.event_data.SourceImage`, `user.id`, and `host.id`. Avoid exceptions on `winlog.event_data.CallTrace`, `winlog.event_data.TargetImage`, or LSASS access alone.
97
98### Response and remediation
99
100- If confirmed benign, reverse temporary containment and document the alert tuple, recovered source identity, parent context, `user.id`, `host.id`, and absence of contradictory dump or post-access authentication evidence. Create an exception only if the same stable workflow recurs.
101- If suspicious but unconfirmed, preserve the full alert event, recovered source process event, dump artifacts, linked authentication records, `user.id`, and `host.id` before containment. Apply reversible containment first, such as heightened monitoring or temporary restrictions on the affected `host.id`; weigh host criticality before isolating domain controllers or other privileged systems, and escalate to isolation only when dump artifacts or linked authentication evidence indicates likely credential exposure.
102- If confirmed malicious, preserve the alert tuple, source process identifiers, command line, parent context, dump artifact paths, and linked authentication evidence before terminating processes or deleting files. Then isolate the endpoint; if direct response is unavailable, escalate with the preserved artifact set. Restrict affected share paths when share-staged dumps were identified.
103- On servers, jump hosts, or privileged admin systems, scope which local, cached, service, or administrative credentials may have been exposed, then reset or rotate affected credentials according to their role and exposure.
104- Before eradication, review related hosts and users for the same source image, dump path pattern, or transfer target. Then remove dump utilities, scripts, archives, copied dumps, persistence mechanisms, and remediate the privilege path or initial access route that enabled the LSASS access.
105- Post-incident hardening: retain Sysmon Event ID 10 plus supporting process, file, and authentication telemetry, and document adjacent LSASS dump paths such as ProcDump-style switches or rundll32 with comsvcs.dll for the detection engineering team.
106"""
107
108setup = """## Setup
109
110This rule requires Sysmon telemetry to be enabled and ingested.
111
112Setup instructions: https://ela.st/sysmon-event-10-setup
113"""
114
115[rule.investigation_fields]
116field_names = [
117 "@timestamp",
118 "host.name",
119 "host.id",
120 "user.name",
121 "user.id",
122 "process.entity_id",
123 "process.pid",
124 "process.executable",
125 "process.command_line",
126 "winlog.event_data.SourceProcessGUID",
127 "winlog.event_data.SourceImage",
128 "winlog.event_data.TargetImage",
129 "winlog.event_data.GrantedAccess",
130 "winlog.event_data.CallTrace",
131]
132
133[transform]
134
135[[transform.investigate]]
136label = "Source process events by GUID"
137description = ""
138providers = [
139 [
140 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
141 { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{winlog.event_data.SourceProcessGUID}}", valueType = "string" },
142 { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" }
143 ],
144 [
145 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
146 { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
147 { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" }
148 ]
149]
150relativeFrom = "now-1h"
151relativeTo = "now"
152
153[[transform.investigate]]
154label = "File activity for the source process"
155description = ""
156providers = [
157 [
158 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
159 { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{winlog.event_data.SourceProcessGUID}}", valueType = "string" },
160 { excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" }
161 ],
162 [
163 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
164 { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
165 { excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" }
166 ]
167]
168relativeFrom = "now-1h"
169relativeTo = "now"
170
171[[transform.investigate]]
172label = "Child process events for the source process"
173description = ""
174providers = [
175 [
176 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
177 { excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{winlog.event_data.SourceProcessGUID}}", valueType = "string" },
178 { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" }
179 ],
180 [
181 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
182 { excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
183 { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" }
184 ]
185]
186relativeFrom = "now-1h"
187relativeTo = "now"
188
189[[transform.investigate]]
190label = "Alerts associated with the user"
191description = ""
192providers = [
193 [
194 { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
195 { excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" }
196 ]
197]
198relativeFrom = "now-48h/h"
199relativeTo = "now"
200
201[[transform.investigate]]
202label = "Alerts associated with the host"
203description = ""
204providers = [
205 [
206 { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
207 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
208 ]
209]
210relativeFrom = "now-48h/h"
211relativeTo = "now"
212
213[[rule.threat]]
214framework = "MITRE ATT&CK"
215[[rule.threat.technique]]
216id = "T1003"
217name = "OS Credential Dumping"
218reference = "https://attack.mitre.org/techniques/T1003/"
219[[rule.threat.technique.subtechnique]]
220id = "T1003.001"
221name = "LSASS Memory"
222reference = "https://attack.mitre.org/techniques/T1003/001/"
223
224[rule.threat.tactic]
225id = "TA0006"
226name = "Credential Access"
227reference = "https://attack.mitre.org/tactics/TA0006/"
228[[rule.threat]]
229framework = "MITRE ATT&CK"
230[[rule.threat.technique]]
231id = "T1106"
232name = "Native API"
233reference = "https://attack.mitre.org/techniques/T1106/"
234
235[rule.threat.tactic]
236id = "TA0002"
237name = "Execution"
238reference = "https://attack.mitre.org/tactics/TA0002/"
Triage and analysis
Investigating Potential Credential Access via LSASS Memory Dump
Possible investigation steps
-
What did the process-access event prove?
- Focus:
winlog.event_data.SourceImage,winlog.event_data.SourceProcessGUID,winlog.event_data.TargetImage,winlog.event_data.GrantedAccess, andwinlog.event_data.CallTrace. - Implication: escalate on a non-WerFault source touching LSASS with dbgcore in the call trace plus any corroborator; lower concern only when the tuple matches a stable EDR, crash-analysis, support, or authorized-test workflow on that
host.id.
- Focus:
-
Does the source process match a recognized diagnostic tool?
- Focus: recover the process start on the same
host.idusingwinlog.event_data.SourceProcessGUIDorprocess.entity_id, then reviewprocess.executable,process.command_line,process.pe.original_file_name,process.code_signature.subject_name, andprocess.code_signature.trusted. $investigate_0 - Hint: if the source lacks
winlog.event_data.SourceProcessGUID, fall back towinlog.event_data.SourceImage,host.id, and a tight window around@timestamp; if PE or signature metadata is absent, keep identity unresolved rather than inferring trust from path. - Implication: escalate when the recovered source is unsigned, renamed, user-writable, or uses MiniDumpWriteDump-adjacent arguments such as ProcDump-style switches or rundll32 with comsvcs.dll; if process-start telemetry is unavailable, treat identity as unresolved and do not close on
winlog.event_data.SourceImagealone.
- Focus: recover the process start on the same
-
Does the recovered launch chain explain why this process would touch LSASS?
- Focus:
process.command_line,process.parent.executable,process.parent.command_line,process.Ext.authentication_id, anduser.id; useprocess.Ext.ancestrywhen parent context is incomplete. - Implication: escalate when shells, script hosts, Office, browsers, archive tools, or remote-admin launchers start the accessor, or when
user.iddoes not fit recognized troubleshooting; recordprocess.Ext.authentication_idonly as a later session bridge, and treat missing lineage as unresolved rather than benign.
- Focus:
-
Do same-source file events show dump creation, rename, or staging?
- Focus: same-host file events for recovered
process.entity_id, orhost.idplusprocess.pidin a tight alert window; readfile.path,file.name,file.Ext.original.path, andfile.size. $investigate_1 - Implication: escalate when the accessor writes dump output to temp, public, user-writable, or share paths, or renames it into archives or deceptive extensions; missing file telemetry is unresolved, not benign.
- Focus: same-host file events for recovered
-
Do surrounding process events show dump handling, archive, copy, or cleanup?
- Focus: child process starts from the recovered accessor on the same
host.id, especiallyprocess.parent.entity_id,process.executable,process.command_line, and@timestamp. $investigate_2 - Hint: sibling process review remains a manual expansion from the recovered parent/session context.
- Implication: escalate when archivers, copy tools, PowerShell, rundll32, or cleanup commands appear immediately before or after the access; if process telemetry is sparse, preserve the gap and rely on the access tuple plus other corroborators.
- Focus: child process starts from the recovered accessor on the same
-
Do authentication events suggest the account pivoted after the access?
- Why: MiniDumpWriteDump-style LSASS access is usually a precursor step; later credential use matters more than the access alone.
- Focus: after process recovery, use
process.Ext.authentication_idandhost.idto review authentication events viawinlog.event_data.TargetLogonId; searchwinlog.event_data.SubjectLogonIdseparately for "4648" explicit-credential context. - Hint: if the process does not preserve
process.Ext.authentication_id, skip the auth bridge and record the gap. - Implication: escalate when the linked session or
user.idshows unexpected remote logons, explicit-credential use, or admin-share access soon after; missing authentication telemetry is unresolved, not benign.
-
If source identity, artifacts, or follow-on activity remain suspicious, do related alerts widen scope?
- Focus: related
user.idalerts for credential access, lateral movement, privilege escalation, or suspicious authentication. $investigate_3 - Hint: compare
host.idalerts to separate account reuse from host-local dump staging. $investigate_4 - Implication: broaden when the same user or host also triggers dumping, suspicious logon, lateral movement, or exfiltration findings; keep local when related alerts are absent.
- Focus: related
-
Escalate when LSASS access plus one meaningful corroborator points to unauthorized dump preparation or credential use; close only when identity, access tuple, launch, artifacts, authentication, and scope align with one recognized benign workflow; preserve and escalate if mixed or incomplete.
False positive analysis
- Recognized EDR, crash-analysis, vendor-support, or authorized testing tooling can legitimately touch LSASS through dbgcore. Close only when the alert tuple, recovered source identity, parent context,
user.id, andhost.idall point to that same workflow, with no contradictory dump artifact or post-access authentication evidence. Case records, inventories, and owner confirmation can corroborate but not replace the telemetry match. - Before exceptioning, validate recurrence for the same recovered tool identity, signer, parent context,
winlog.event_data.SourceImage,user.id, andhost.id. Avoid exceptions onwinlog.event_data.CallTrace,winlog.event_data.TargetImage, or LSASS access alone.
Response and remediation
- If confirmed benign, reverse temporary containment and document the alert tuple, recovered source identity, parent context,
user.id,host.id, and absence of contradictory dump or post-access authentication evidence. Create an exception only if the same stable workflow recurs. - If suspicious but unconfirmed, preserve the full alert event, recovered source process event, dump artifacts, linked authentication records,
user.id, andhost.idbefore containment. Apply reversible containment first, such as heightened monitoring or temporary restrictions on the affectedhost.id; weigh host criticality before isolating domain controllers or other privileged systems, and escalate to isolation only when dump artifacts or linked authentication evidence indicates likely credential exposure. - If confirmed malicious, preserve the alert tuple, source process identifiers, command line, parent context, dump artifact paths, and linked authentication evidence before terminating processes or deleting files. Then isolate the endpoint; if direct response is unavailable, escalate with the preserved artifact set. Restrict affected share paths when share-staged dumps were identified.
- On servers, jump hosts, or privileged admin systems, scope which local, cached, service, or administrative credentials may have been exposed, then reset or rotate affected credentials according to their role and exposure.
- Before eradication, review related hosts and users for the same source image, dump path pattern, or transfer target. Then remove dump utilities, scripts, archives, copied dumps, persistence mechanisms, and remediate the privilege path or initial access route that enabled the LSASS access.
- Post-incident hardening: retain Sysmon Event ID 10 plus supporting process, file, and authentication telemetry, and document adjacent LSASS dump paths such as ProcDump-style switches or rundll32 with comsvcs.dll for the detection engineering team.
References
Related rules
- Potential Credential Access via Renamed COM+ Services DLL
- Potential LSASS Memory Dump via PssCaptureSnapShot
- Wireless Credential Dumping using Netsh Command
- Kirbi File Creation
- LSASS Memory Dump Creation