« Suspicious Lsass Process Access Potential LSASS Memory Dump via PssCaptureSnapShot »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.23

Potential Credential Access via LSASS Memory Dump

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

Potential Credential Access via LSASS Memory Dump

edit

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.

Rule type: eql

Rule indices:

  • winlogbeat-*
  • logs-windows.sysmon_operational-*

Severity: high

Risk score: 73

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

  • Domain: Endpoint
  • OS: Windows
  • Use Case: Threat Detection
  • Tactic: Credential Access
  • Data Source: Sysmon
  • Resources: Investigation Guide

Version: 314

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

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, and winlog.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.
  • Does the source process match a recognized diagnostic tool?
  • 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{"description":"","label":"Source process events by GUID","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{winlog.event_data.SourceProcessGUID}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • 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.
  • 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.
  • 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, and user.id; use process.Ext.ancestry when parent context is incomplete.
  • 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.
  • Do same-source file events show dump creation, rename, or staging?
  • 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{"description":"","label":"File activity for the source process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{winlog.event_data.SourceProcessGUID}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • 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.
  • Do surrounding process events show dump handling, archive, copy, or cleanup?
  • 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{"description":"","label":"Child process events for the source process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{winlog.event_data.SourceProcessGUID}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • 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.
  • 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_id and host.id to review authentication events via winlog.event_data.TargetLogonId; search winlog.event_data.SubjectLogonId separately 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.id shows 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.id alerts for credential access, lateral movement, privilege escalation, or suspicious authentication. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
  • Hint: compare host.id alerts to separate account reuse from host-local dump staging. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
  • 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.
  • 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, 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.
  • 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.

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, 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.
  • 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.

Setup

edit

Setup

This rule requires Sysmon telemetry to be enabled and ingested.

Setup instructions: https://ela.st/sysmon-event-10-setup

Rule query

edit
process where host.os.type == "windows" and event.code == "10" and
  winlog.event_data.TargetImage : "?:\\WINDOWS\\system32\\lsass.exe" and

  /* dbgcore.dll hosts MiniDumpWriteDump on modern Windows; dbghelp-only traces are non-dump usage */
  winlog.event_data.CallTrace : "*dbgcore*" and

  /* crash handlers */
  not process.executable : (
        "?:\\Windows\\System32\\WerFault.exe",
        "?:\\Windows\\SysWOW64\\WerFault.exe",
        "?:\\Windows\\System32\\WerFaultSecure.exe"
      )

Framework: MITRE ATT&CKTM

« Suspicious Lsass Process Access Potential LSASS Memory Dump via PssCaptureSnapShot »