Potential Credential Access via LSASS Memory Dump

  1[metadata]
  2creation_date = "2021/10/07"
  3integration = ["windows"]
  4maturity = "production"
  5updated_date = "2025/03/20"
  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"
 18note = """## Triage and analysis
 19
 20> **Disclaimer**:
 21> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
 22
 23### Investigating Potential Credential Access via LSASS Memory Dump
 24
 25LSASS (Local Security Authority Subsystem Service) is crucial for managing Windows security policies and storing sensitive data like user credentials. Adversaries exploit this by using tools that leverage MiniDumpWriteDump from libraries like DBGHelp.dll to extract credentials. The detection rule identifies suspicious LSASS access by monitoring for these libraries in call traces, excluding legitimate crash handlers, thus flagging potential credential theft attempts.
 26
 27### Possible investigation steps
 28
 29- Review the process details associated with the alert, focusing on the process name, executable path, and parent process to determine if the process accessing LSASS is legitimate or suspicious.
 30- Examine the call trace details to confirm the presence of DBGHelp.dll or DBGCore.dll, which are indicative of potential credential dumping attempts.
 31- Check for any recent crash reports or legitimate use of WerFault.exe, WerFaultSecure.exe, or similar processes that might explain the LSASS access as a non-malicious event.
 32- Investigate the user account context under which the suspicious process is running to assess if it aligns with expected behavior or if it indicates potential compromise.
 33- Correlate the event with other security logs or alerts to identify any related suspicious activities, such as unauthorized access attempts or lateral movement within the network.
 34- Assess the risk and impact by determining if any sensitive credentials could have been exposed, and consider isolating the affected system to prevent further compromise.
 35
 36### False positive analysis
 37
 38- Legitimate crash handlers like WerFault.exe may access LSASS during system crashes. To prevent these from being flagged, ensure that the rule excludes processes such as WerFault.exe, WerFaultSecure.exe, and their SysWOW64 counterparts.
 39- Debugging tools used by developers or IT administrators might trigger this rule if they access LSASS for legitimate purposes. Consider creating exceptions for known and trusted debugging tools within your environment.
 40- Security software or endpoint protection solutions may perform similar actions as part of their normal operations. Verify with your security vendor and exclude these processes if they are confirmed to be benign.
 41- Automated system diagnostics or maintenance scripts that interact with LSASS for health checks could be misidentified. Review and whitelist these scripts if they are part of routine system management tasks.
 42- Ensure that any custom or third-party applications that require access to LSASS for legitimate reasons are documented and excluded from the rule to avoid unnecessary alerts.
 43
 44### Response and remediation
 45
 46- Immediately isolate the affected system from the network to prevent further credential access or lateral movement by the adversary.
 47- Terminate any suspicious processes that are accessing the LSASS memory, especially those involving DBGHelp.dll or DBGCore.dll, to stop the credential dumping activity.
 48- Conduct a thorough review of the affected system's security logs to identify any unauthorized access or changes, focusing on event code "10" and call traces involving LSASS.
 49- Change passwords for all accounts that were active on the affected system, prioritizing high-privilege accounts, to mitigate the risk of compromised credentials being used.
 50- Restore the affected system from a known good backup to ensure that any malicious changes or tools are removed.
 51- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems may be affected.
 52- Implement enhanced monitoring and alerting for similar suspicious activities, focusing on LSASS access and the use of MiniDumpWriteDump, to improve detection and response capabilities."""
 53references = [
 54    "https://www.ired.team/offensive-security/credential-access-and-credential-dumping/dump-credentials-from-lsass-process-without-mimikatz",
 55    "https://www.elastic.co/security-labs/detect-credential-access",
 56    "https://www.elastic.co/security-labs/elastic-protects-against-data-wiper-malware-targeting-ukraine-hermeticwiper",
 57]
 58risk_score = 73
 59rule_id = "9960432d-9b26-409f-972b-839a959e79e2"
 60setup = """## Setup
 61
 62If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2,
 63events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2.
 64Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate
 65`event.ingested` to @timestamp.
 66For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html
 67"""
 68severity = "high"
 69tags = [
 70    "Domain: Endpoint",
 71    "OS: Windows",
 72    "Use Case: Threat Detection",
 73    "Tactic: Credential Access",
 74    "Tactic:Execution",
 75    "Data Source: Sysmon",
 76    "Resources: Investigation Guide",
 77]
 78timestamp_override = "event.ingested"
 79type = "eql"
 80
 81query = '''
 82process where host.os.type == "windows" and event.code == "10" and
 83  winlog.event_data.TargetImage : "?:\\WINDOWS\\system32\\lsass.exe" and
 84
 85   /* DLLs exporting MiniDumpWriteDump API to create an lsass mdmp*/
 86  winlog.event_data.CallTrace : ("*dbghelp*", "*dbgcore*") and
 87
 88   /* case of lsass crashing */
 89  not process.executable : (
 90        "?:\\Windows\\System32\\WerFault.exe",
 91        "?:\\Windows\\SysWOW64\\WerFault.exe",
 92        "?:\\Windows\\System32\\WerFaultSecure.exe"
 93      )
 94'''
 95
 96
 97[[rule.threat]]
 98framework = "MITRE ATT&CK"
 99[[rule.threat.technique]]
100id = "T1003"
101name = "OS Credential Dumping"
102reference = "https://attack.mitre.org/techniques/T1003/"
103[[rule.threat.technique.subtechnique]]
104id = "T1003.001"
105name = "LSASS Memory"
106reference = "https://attack.mitre.org/techniques/T1003/001/"
107
108
109
110[rule.threat.tactic]
111id = "TA0006"
112name = "Credential Access"
113reference = "https://attack.mitre.org/tactics/TA0006/"
114[[rule.threat]]
115framework = "MITRE ATT&CK"
116[[rule.threat.technique]]
117id = "T1106"
118name = "Native API"
119reference = "https://attack.mitre.org/techniques/T1106/"
120
121
122[rule.threat.tactic]
123id = "TA0002"
124name = "Execution"
125reference = "https://attack.mitre.org/tactics/TA0002/"