Suspicious Lsass Process Access

Identifies access attempts to LSASS handle, this may indicate an attempt to dump credentials from Lsass memory.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2023/01/22"
  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 = "Identifies access attempts to LSASS handle, this may indicate an attempt to dump credentials from Lsass memory.\n"
 12from = "now-9m"
 13index = ["winlogbeat-*", "logs-windows.sysmon_operational-*"]
 14language = "eql"
 15license = "Elastic License v2"
 16name = "Suspicious Lsass Process Access"
 17references = ["https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1003.001/T1003.001.md"]
 18risk_score = 47
 19rule_id = "128468bf-cab1-4637-99ea-fdf3780a4609"
 20setup = """## Setup
 21
 22If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2,
 23events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2.
 24Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate
 25`event.ingested` to @timestamp.
 26For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html
 27"""
 28severity = "medium"
 29tags = [
 30    "Domain: Endpoint",
 31    "OS: Windows",
 32    "Use Case: Threat Detection",
 33    "Tactic: Credential Access",
 34    "Data Source: Sysmon",
 35    "Resources: Investigation Guide",
 36]
 37timestamp_override = "event.ingested"
 38type = "eql"
 39
 40query = '''
 41process where host.os.type == "windows" and event.code == "10" and
 42  winlog.event_data.TargetImage : "?:\\WINDOWS\\system32\\lsass.exe" and
 43  not winlog.event_data.GrantedAccess :
 44                ("0x1000", "0x1400", "0x101400", "0x101000", "0x101001", "0x100000", "0x100040", "0x3200", "0x40", "0x3200") and
 45  not process.name : ("procexp64.exe", "procmon.exe", "procexp.exe", "Microsoft.Identity.AadConnect.Health.AadSync.Host.ex") and
 46  not process.executable : (
 47        "?:\\ProgramData\\Microsoft\\Windows Defender\\platform\\*",
 48        "?:\\ProgramData\\WebEx\\webex\\*",
 49        "?:\\Program Files (x86)\\*",
 50        "?:\\Program Files\\*",
 51        "?:\\Windows\\CCM\\CcmExec.exe",
 52        "?:\\Windows\\LTSvc\\LTSVC.exe",
 53        "?:\\Windows\\Sysmon.exe",
 54        "?:\\Windows\\Sysmon64.exe",
 55        "C:\\Windows\\CynetMS.exe",
 56        "?:\\Windows\\system32\\csrss.exe",
 57        "?:\\Windows\\System32\\lsm.exe",
 58        "?:\\Windows\\system32\\MRT.exe",
 59        "?:\\Windows\\System32\\msiexec.exe",
 60        "?:\\Windows\\system32\\wbem\\wmiprvse.exe",
 61        "?:\\Windows\\system32\\wininit.exe",
 62        "?:\\Windows\\SystemTemp\\GUM*.tmp\\GoogleUpdate.exe",
 63        "?:\\Windows\\sysWOW64\\wbem\\wmiprvse.exe",
 64        "C:\\oracle\\64\\02\\instantclient_19_13\\sqlplus.exe",
 65        "C:\\oracle\\64\\02\\instantclient_19_13\\sqlldr.exe",
 66        "d:\\oracle\\product\\19\\dbhome1\\bin\\ORACLE.EXE",
 67        "C:\\wamp\\bin\\apache\\apache*\\bin\\httpd.exe",
 68        "C:\\Windows\\system32\\netstat.exe",
 69        "C:\\PROGRA~1\\INFORM~1\\apps\\jdk\\*\\jre\\bin\\java.exe",
 70        "C:\\PROGRA~2\\CyberCNSAgentV2\\osqueryi.exe",
 71        "C:\\Utilityw2k19\\packetbeat\\packetbeat.exe",
 72        "C:\\ProgramData\\Cisco\\Cisco AnyConnect Secure Mobility Client\\Temp\\CloudUpdate\\vpndownloader.exe",
 73        "C:\\ProgramData\\Cisco\\Cisco Secure Client\\Temp\\CloudUpdate\\vpndownloader.exe"
 74  ) and
 75  not winlog.event_data.CallTrace : ("*mpengine.dll*", "*appresolver.dll*", "*sysmain.dll*")
 76'''
 77note = """## Triage and analysis
 78
 79> **Disclaimer**:
 80> 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.
 81
 82### Investigating Suspicious Lsass Process Access
 83
 84The Local Security Authority Subsystem Service (LSASS) is crucial for enforcing security policies and managing user logins in Windows environments. Adversaries often target LSASS to extract credentials, enabling unauthorized access. The detection rule identifies unusual access attempts to LSASS by filtering out legitimate processes and access patterns, focusing on anomalies that suggest credential dumping activities.
 85
 86### Possible investigation steps
 87
 88- Review the process details that triggered the alert, focusing on the process name and executable path to determine if it is a known legitimate application or potentially malicious.
 89- Examine the GrantedAccess value in the event data to understand the level of access attempted on the LSASS process and compare it against typical access patterns.
 90- Investigate the parent process of the suspicious process to identify how it was spawned and assess if it is part of a legitimate workflow or an anomaly.
 91- Check the CallTrace field for any unusual or suspicious DLLs that might indicate malicious activity or exploitation attempts.
 92- Correlate the alert with other security events or logs from the same host to identify any related suspicious activities or patterns, such as network connections or file modifications.
 93- Verify the host's security posture, including the status of antivirus or endpoint protection solutions, to ensure they are functioning correctly and have not been tampered with.
 94
 95### False positive analysis
 96
 97- Legitimate security tools like Sysinternals Process Explorer and Process Monitor can trigger false positives. Exclude these by adding their process names to the exception list.
 98- Windows Defender and other antivirus software may access LSASS for legitimate scanning purposes. Exclude their executable paths from the detection rule to prevent false alerts.
 99- System processes such as csrss.exe, lsm.exe, and wmiprvse.exe are known to access LSASS as part of normal operations. Ensure these are included in the process executable exceptions to avoid unnecessary alerts.
100- Software updates and installers, like those from Cisco AnyConnect or Oracle, may access LSASS during legitimate operations. Add these specific paths to the exclusion list to reduce false positives.
101- Custom enterprise applications that interact with LSASS for authentication purposes should be identified and their paths added to the exceptions to prevent disruption in monitoring.
102
103### Response and remediation
104
105- Isolate the affected system from the network immediately to prevent further unauthorized access or lateral movement by the adversary.
106- Terminate any suspicious processes identified in the alert that are attempting to access the LSASS process, ensuring that legitimate processes are not disrupted.
107- Conduct a memory dump analysis of the affected system to identify any malicious tools or scripts used for credential dumping, focusing on the LSASS process.
108- Change all potentially compromised credentials, especially those with administrative privileges, to prevent unauthorized access using stolen credentials.
109- Apply patches and updates to the affected system to address any vulnerabilities that may have been exploited by the adversary.
110- Monitor the network for any signs of further suspicious activity or attempts to access LSASS on other systems, using enhanced logging and alerting mechanisms.
111- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
112
113
114[[rule.threat]]
115framework = "MITRE ATT&CK"
116[[rule.threat.technique]]
117id = "T1003"
118name = "OS Credential Dumping"
119reference = "https://attack.mitre.org/techniques/T1003/"
120[[rule.threat.technique.subtechnique]]
121id = "T1003.001"
122name = "LSASS Memory"
123reference = "https://attack.mitre.org/techniques/T1003/001/"
124
125
126
127[rule.threat.tactic]
128id = "TA0006"
129name = "Credential Access"
130reference = "https://attack.mitre.org/tactics/TA0006/"

Triage and analysis

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.

Investigating Suspicious Lsass Process Access

The Local Security Authority Subsystem Service (LSASS) is crucial for enforcing security policies and managing user logins in Windows environments. Adversaries often target LSASS to extract credentials, enabling unauthorized access. The detection rule identifies unusual access attempts to LSASS by filtering out legitimate processes and access patterns, focusing on anomalies that suggest credential dumping activities.

Possible investigation steps

  • Review the process details that triggered the alert, focusing on the process name and executable path to determine if it is a known legitimate application or potentially malicious.
  • Examine the GrantedAccess value in the event data to understand the level of access attempted on the LSASS process and compare it against typical access patterns.
  • Investigate the parent process of the suspicious process to identify how it was spawned and assess if it is part of a legitimate workflow or an anomaly.
  • Check the CallTrace field for any unusual or suspicious DLLs that might indicate malicious activity or exploitation attempts.
  • Correlate the alert with other security events or logs from the same host to identify any related suspicious activities or patterns, such as network connections or file modifications.
  • Verify the host's security posture, including the status of antivirus or endpoint protection solutions, to ensure they are functioning correctly and have not been tampered with.

False positive analysis

  • Legitimate security tools like Sysinternals Process Explorer and Process Monitor can trigger false positives. Exclude these by adding their process names to the exception list.
  • Windows Defender and other antivirus software may access LSASS for legitimate scanning purposes. Exclude their executable paths from the detection rule to prevent false alerts.
  • System processes such as csrss.exe, lsm.exe, and wmiprvse.exe are known to access LSASS as part of normal operations. Ensure these are included in the process executable exceptions to avoid unnecessary alerts.
  • Software updates and installers, like those from Cisco AnyConnect or Oracle, may access LSASS during legitimate operations. Add these specific paths to the exclusion list to reduce false positives.
  • Custom enterprise applications that interact with LSASS for authentication purposes should be identified and their paths added to the exceptions to prevent disruption in monitoring.

Response and remediation

  • Isolate the affected system from the network immediately to prevent further unauthorized access or lateral movement by the adversary.
  • Terminate any suspicious processes identified in the alert that are attempting to access the LSASS process, ensuring that legitimate processes are not disrupted.
  • Conduct a memory dump analysis of the affected system to identify any malicious tools or scripts used for credential dumping, focusing on the LSASS process.
  • Change all potentially compromised credentials, especially those with administrative privileges, to prevent unauthorized access using stolen credentials.
  • Apply patches and updates to the affected system to address any vulnerabilities that may have been exploited by the adversary.
  • Monitor the network for any signs of further suspicious activity or attempts to access LSASS on other systems, using enhanced logging and alerting mechanisms.
  • Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.

References

Related rules

to-top