Potential LSASS Memory Dump via PssCaptureSnapShot

  1[metadata]
  2creation_date = "2021/10/14"
  3integration = ["windows"]
  4maturity = "production"
  5updated_date = "2026/04/27"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies suspicious access to an LSASS handle via PssCaptureSnapShot where two successive process accesses are
 11performed by the same process and target two different instances of LSASS. This may indicate an attempt to evade
 12detection and dump LSASS memory for credential access.
 13"""
 14from = "now-9m"
 15index = ["winlogbeat-*", "logs-windows.sysmon_operational-*"]
 16language = "kuery"
 17license = "Elastic License v2"
 18name = "Potential LSASS Memory Dump via PssCaptureSnapShot"
 19references = [
 20    "https://www.matteomalvica.com/blog/2019/12/02/win-defender-atp-cred-bypass/",
 21    "https://twitter.com/sbousseaden/status/1280619931516747777?lang=en",
 22]
 23risk_score = 73
 24rule_id = "0f93cb9a-1931-48c2-8cd0-f173fd3e5283"
 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 = "threshold"
 36
 37query = '''
 38event.category:process and host.os.type:windows and event.code:10 and
 39 winlog.event_data.TargetImage:("C:\\Windows\\system32\\lsass.exe" or
 40                                 "c:\\Windows\\system32\\lsass.exe" or
 41                                 "c:\\Windows\\System32\\lsass.exe")
 42'''
 43
 44note = """## Triage and analysis
 45
 46### Investigating Potential LSASS Memory Dump via PssCaptureSnapShot
 47
 48#### Possible investigation steps
 49
 50- What do the threshold summary and recovered members prove about the LSASS access pattern?
 51  - Why: grouped threshold alerts require member recovery before the count proves a snapshot or repeated-access pattern.
 52  - Focus: `process.entity_id`, `kibana.alert.threshold_result.count`, and Sysmon Event 10 members for `winlog.event_data.TargetProcessId`, `winlog.event_data.GrantedAccess`, and `winlog.event_data.CallTrace`. $investigate_0
 53  - Implication: escalate when one process entity touched two distinct LSASS target PIDs and access or call-trace evidence fits snapshot or dump collection; lower concern only when members form one recognized debugger, EDR, or IR memory-acquisition pattern. If members cannot be recovered, the grouped alert stays unresolved, not benign.
 54
 55- Which caller and stack evidence identify the snapshot or dump path?
 56  - Focus: caller path, access mask, and call trace from recovered members on the same `host.id`.
 57  - Implication: escalate when the caller is user-writable, renamed, unrelated to endpoint security, or the stack shows PssCaptureSnapshot, PssNtCaptureSnapshot, dbghelp, or MiniDumpWriteDump-style dumping; lower concern when caller, access mask, and stack match a recognized EDR, debugger, or forensic collector.
 58
 59- Does the user-host context fit deliberate LSASS memory acquisition?
 60  - Focus: `host.id`, `user.id`, `user.name`, and recovered caller.
 61  - Implication: escalate when activity runs under a normal user, service account, workstation, domain controller, or jump host with no matching IR or security-collection purpose; lower concern only when the same host, user, and caller map to one recognized memory-acquisition workflow.
 62
 63- If Windows Security logs are available, did authentication or source evidence show credential use after the LSASS access?
 64  - Why: PssCaptureSnapshot-based LSASS access commonly precedes credential dumping, so post-access identity use changes urgency.
 65  - Focus: `host.id` and `user.id`; if Windows Security logs exist for this host/window, recover authentication records before interpretation and use `source.*` only from those records, especially `event.code`, `winlog.event_data.TargetLogonId`, and `source.ip`.
 66  - Implication: escalate when the same user or host shows new 4624 logons, 4648 explicit-credential use, rare `source.ip`, or remote access after LSASS events; use `winlog.event_data.TargetLogonId` to group logon records, not claim process-session continuity. Missing authentication telemetry is unresolved, not benign.
 67
 68- If local evidence remains suspicious or unresolved, do related alerts change scope?
 69  - Focus: credential-access, archive, lateral-movement, or clone-related alerts for the same `process.entity_id`, `user.id`, or `host.id`. $investigate_1 $investigate_2 $investigate_3
 70  - Implication: broaden response when the same process entity also shows dumping, archive staging, suspicious authentication, lateral movement, or clone-related alerts; keep scope local when related alerts are absent, but do not use alert absence to clear recovered LSASS access evidence.
 71
 72- Escalate when member pattern, caller or stack evidence, user-host context, authentication/source evidence, or related-alert scope supports unauthorized LSASS access or credential use; close only when member events and host/user context bind the alert to one recognized debugger, EDR, forensic, IR, or lab workflow with no contradictory evidence; preserve evidence and escalate when recovery is incomplete or findings conflict.
 73
 74### False positive analysis
 75
 76- Authorized debugger, EDR, forensic, IR memory-acquisition, or lab validation tooling can trigger this rule. Confirm from telemetry first: member-event pattern, caller or stack, `host.id`, and `user.id` must converge on the same workflow. Use case records or tool inventory only to corroborate that telemetry-bound workflow. If members are unavailable or any anchor contradicts it, do not close as benign.
 77- Before creating an exception, validate that the same stable caller, recovered target-PID/access/call-trace pattern, `host.id`, and `user.id` recur across prior alerts from this rule. Build the exception from that minimum confirmed workflow pattern. Avoid exceptions on `process.entity_id`, `kibana.alert.threshold_result.count`, or LSASS targeting alone.
 78
 79### Response and remediation
 80
 81- If confirmed benign, reverse temporary containment and document the alert summary, grouped `process.entity_id`, recovered member-event pattern, caller or stack evidence, `host.id`, `user.id`, and the corroborating case, tool, or lab record. Create an exception only for the recurring workflow pattern.
 82- If suspicious but unconfirmed, preserve the alert, Timeline member records, target-PID/access/call-trace evidence, recovered caller, `process.entity_id`, `host.id`, `user.id`, and any recovered authentication or source records before containment.
 83- If suspicious but unconfirmed, apply reversible containment first, such as heightened monitoring or temporary network isolation for the affected `host.id`; weigh host criticality before isolating domain controllers, jump hosts, or production servers.
 84- If confirmed malicious, isolate the affected host when recovered member events and caller or stack evidence confirm unauthorized LSASS access. Disable or reset accounts only when recovered authentication or source evidence indicates credential use or likely exposure.
 85- If confirmed malicious, collect the suspicious binary, dump outputs, scripts, archives, and memory-acquisition tooling identified during investigation before terminating processes or deleting files.
 86- If confirmed malicious, block confirmed remote sources or transfer paths identified during investigation, then eradicate the collected dump tooling and remediate the execution or privilege path that enabled LSASS access.
 87- Post-incident hardening: restrict LSASS snapshot and dump tooling to controlled security workflows, enable LSASS protection controls where compatible, retain Sysmon Event 10 and Windows Security logs, and document PssCaptureSnapshot or clone-based variants surfaced during triage.
 88"""
 89
 90setup = """## Setup
 91
 92This rule requires Sysmon telemetry to be enabled and ingested.
 93
 94Setup instructions: https://ela.st/sysmon-event-10-setup
 95"""
 96
 97[rule.investigation_fields]
 98field_names = [
 99    "@timestamp",
100    "host.name",
101    "host.id",
102    "user.name",
103    "user.id",
104    "user.domain",
105    "process.entity_id",
106    "kibana.alert.threshold_result.count",
107]
108
109[transform]
110
111[[transform.investigate]]
112label = "Sysmon process access events for the grouped process entity"
113description = ""
114providers = [
115  [
116    { excluded = false, field = "event.code", queryType = "phrase", value = "10", valueType = "string" },
117    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
118    { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
119    { excluded = false, field = "winlog.event_data.TargetImage", queryType = "phrase", value = "C:\\Windows\\system32\\lsass.exe", valueType = "string" }
120  ],
121  [
122    { excluded = false, field = "event.code", queryType = "phrase", value = "10", valueType = "string" },
123    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
124    { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
125    { excluded = false, field = "winlog.event_data.TargetImage", queryType = "phrase", value = "c:\\Windows\\system32\\lsass.exe", valueType = "string" }
126  ],
127  [
128    { excluded = false, field = "event.code", queryType = "phrase", value = "10", valueType = "string" },
129    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
130    { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
131    { excluded = false, field = "winlog.event_data.TargetImage", queryType = "phrase", value = "C:\\Windows\\System32\\lsass.exe", valueType = "string" }
132  ]
133]
134relativeFrom = "now-1h"
135relativeTo = "now"
136
137[[transform.investigate]]
138label = "Alerts associated with the grouped process entity"
139description = ""
140providers = [
141  [
142    { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
143    { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }
144  ]
145]
146relativeFrom = "now-48h/h"
147relativeTo = "now"
148
149[[transform.investigate]]
150label = "Alerts associated with the user"
151description = ""
152providers = [
153  [
154    { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
155    { excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" }
156  ]
157]
158relativeFrom = "now-48h/h"
159relativeTo = "now"
160
161[[transform.investigate]]
162label = "Alerts associated with the host"
163description = ""
164providers = [
165  [
166    { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
167    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
168  ]
169]
170relativeFrom = "now-48h/h"
171relativeTo = "now"
172
173[[rule.threat]]
174framework = "MITRE ATT&CK"
175[[rule.threat.technique]]
176id = "T1003"
177name = "OS Credential Dumping"
178reference = "https://attack.mitre.org/techniques/T1003/"
179[[rule.threat.technique.subtechnique]]
180id = "T1003.001"
181name = "LSASS Memory"
182reference = "https://attack.mitre.org/techniques/T1003/001/"
183
184[rule.threat.tactic]
185id = "TA0006"
186name = "Credential Access"
187reference = "https://attack.mitre.org/tactics/TA0006/"
188
189[rule.threshold]
190field = ["process.entity_id"]
191value = 2
192
193[[rule.threshold.cardinality]]
194field = "winlog.event_data.TargetProcessId"
195value = 2