Potential Credential Access via DuplicateHandle in LSASS

Identifies suspicious access to an LSASS handle via DuplicateHandle from an unknown call trace module. This may indicate an attempt to bypass the NtOpenProcess API to evade detection and dump LSASS memory for credential access.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2021/09/27"
  3integration = ["windows"]
  4maturity = "production"
  5updated_date = "2025/01/15"
  6min_stack_version = "8.14.0"
  7min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
  8
  9[rule]
 10author = ["Elastic"]
 11description = """
 12Identifies suspicious access to an LSASS handle via DuplicateHandle from an unknown call trace module. This may indicate
 13an attempt to bypass the NtOpenProcess API to evade detection and dump LSASS memory for credential access.
 14"""
 15from = "now-9m"
 16index = ["winlogbeat-*", "logs-windows.sysmon_operational-*"]
 17language = "eql"
 18license = "Elastic License v2"
 19name = "Potential Credential Access via DuplicateHandle in LSASS"
 20references = ["https://github.com/CCob/MirrorDump"]
 21risk_score = 47
 22rule_id = "02a4576a-7480-4284-9327-548a806b5e48"
 23setup = """## Setup
 24
 25If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2,
 26events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2.
 27Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate
 28`event.ingested` to @timestamp.
 29For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html
 30"""
 31severity = "medium"
 32tags = [
 33    "Domain: Endpoint",
 34    "OS: Windows",
 35    "Use Case: Threat Detection",
 36    "Tactic: Credential Access",
 37    "Data Source: Sysmon",
 38    "Resources: Investigation Guide",
 39]
 40timestamp_override = "event.ingested"
 41type = "eql"
 42
 43query = '''
 44process where host.os.type == "windows" and event.code == "10" and
 45
 46 /* LSASS requesting DuplicateHandle access right to another process */
 47 process.name : "lsass.exe" and winlog.event_data.GrantedAccess == "0x40" and
 48
 49 /* call is coming from an unknown executable region */
 50 winlog.event_data.CallTrace : "*UNKNOWN*"
 51'''
 52note = """## Triage and analysis
 53
 54> **Disclaimer**:
 55> 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.
 56
 57### Investigating Potential Credential Access via DuplicateHandle in LSASS
 58
 59The Local Security Authority Subsystem Service (LSASS) is crucial for enforcing security policies and managing user credentials in Windows environments. Adversaries may exploit the DuplicateHandle function to access LSASS memory, bypassing traditional API calls to avoid detection. The detection rule identifies suspicious LSASS handle access attempts from unknown modules, flagging potential credential dumping activities.
 60
 61### Possible investigation steps
 62
 63- Review the event logs for the specific event code "10" to gather more details about the suspicious activity, focusing on the process name "lsass.exe" and the granted access "0x40".
 64- Investigate the call trace details where the event data indicates "*UNKNOWN*" to identify any unknown or suspicious modules that may have initiated the DuplicateHandle request.
 65- Correlate the suspicious activity with other security events or alerts on the same host to determine if there are additional indicators of compromise or related malicious activities.
 66- Check the process tree and parent-child relationships of the lsass.exe process to identify any unusual or unauthorized processes that may have interacted with LSASS.
 67- Analyze the timeline of events to understand the sequence of actions leading up to and following the alert, which may help in identifying the adversary's objectives or next steps.
 68- Review recent changes or updates to the system that might have introduced the unknown module or altered the behavior of legitimate processes.
 69
 70### False positive analysis
 71
 72- Legitimate software or security tools that interact with LSASS for monitoring or protection purposes may trigger this rule. Users should identify and whitelist these trusted applications to prevent unnecessary alerts.
 73- System management or administrative scripts that perform legitimate operations on LSASS might be flagged. Review these scripts and, if verified as safe, add them to an exception list to reduce false positives.
 74- Custom in-house applications that require access to LSASS for valid reasons could be mistakenly identified. Conduct a thorough review of these applications and exclude them from the rule if they are deemed non-threatening.
 75- Security testing or penetration testing activities may mimic malicious behavior. Coordinate with security teams to recognize these activities and temporarily adjust the rule settings during testing periods to avoid false alerts.
 76
 77### Response and remediation
 78
 79- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
 80- Terminate any suspicious processes associated with the unknown executable region accessing LSASS to halt potential credential dumping activities.
 81- Conduct a thorough memory analysis of the affected system to identify any malicious artifacts or indicators of compromise related to the DuplicateHandle exploitation.
 82- Reset credentials for all accounts that may have been accessed or compromised, prioritizing high-privilege accounts.
 83- Review and update endpoint protection configurations to ensure they are capable of detecting and blocking similar unauthorized access attempts in the future.
 84- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
 85- Implement enhanced monitoring and logging for LSASS and related processes to detect any future attempts to exploit the DuplicateHandle function."""
 86
 87
 88[[rule.threat]]
 89framework = "MITRE ATT&CK"
 90[[rule.threat.technique]]
 91id = "T1003"
 92name = "OS Credential Dumping"
 93reference = "https://attack.mitre.org/techniques/T1003/"
 94[[rule.threat.technique.subtechnique]]
 95id = "T1003.001"
 96name = "LSASS Memory"
 97reference = "https://attack.mitre.org/techniques/T1003/001/"
 98
 99
100
101[rule.threat.tactic]
102id = "TA0006"
103name = "Credential Access"
104reference = "https://attack.mitre.org/tactics/TA0006/"
...
toml

Disclaimer: 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.

The Local Security Authority Subsystem Service (LSASS) is crucial for enforcing security policies and managing user credentials in Windows environments. Adversaries may exploit the DuplicateHandle function to access LSASS memory, bypassing traditional API calls to avoid detection. The detection rule identifies suspicious LSASS handle access attempts from unknown modules, flagging potential credential dumping activities.

  • Review the event logs for the specific event code "10" to gather more details about the suspicious activity, focusing on the process name "lsass.exe" and the granted access "0x40".
  • Investigate the call trace details where the event data indicates "UNKNOWN" to identify any unknown or suspicious modules that may have initiated the DuplicateHandle request.
  • Correlate the suspicious activity with other security events or alerts on the same host to determine if there are additional indicators of compromise or related malicious activities.
  • Check the process tree and parent-child relationships of the lsass.exe process to identify any unusual or unauthorized processes that may have interacted with LSASS.
  • Analyze the timeline of events to understand the sequence of actions leading up to and following the alert, which may help in identifying the adversary's objectives or next steps.
  • Review recent changes or updates to the system that might have introduced the unknown module or altered the behavior of legitimate processes.
  • Legitimate software or security tools that interact with LSASS for monitoring or protection purposes may trigger this rule. Users should identify and whitelist these trusted applications to prevent unnecessary alerts.
  • System management or administrative scripts that perform legitimate operations on LSASS might be flagged. Review these scripts and, if verified as safe, add them to an exception list to reduce false positives.
  • Custom in-house applications that require access to LSASS for valid reasons could be mistakenly identified. Conduct a thorough review of these applications and exclude them from the rule if they are deemed non-threatening.
  • Security testing or penetration testing activities may mimic malicious behavior. Coordinate with security teams to recognize these activities and temporarily adjust the rule settings during testing periods to avoid false alerts.
  • Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
  • Terminate any suspicious processes associated with the unknown executable region accessing LSASS to halt potential credential dumping activities.
  • Conduct a thorough memory analysis of the affected system to identify any malicious artifacts or indicators of compromise related to the DuplicateHandle exploitation.
  • Reset credentials for all accounts that may have been accessed or compromised, prioritizing high-privilege accounts.
  • Review and update endpoint protection configurations to ensure they are capable of detecting and blocking similar unauthorized access attempts in the future.
  • Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
  • Implement enhanced monitoring and logging for LSASS and related processes to detect any future attempts to exploit the DuplicateHandle function.

References

Related rules

to-top