Potential Sudo Token Manipulation via Process Injection

  1[metadata]
  2creation_date = "2023/07/31"
  3integration = ["endpoint"]
  4maturity = "production"
  5min_stack_version = "8.16.0"
  6min_stack_comments = "Breaking change at 8.16.0 for the Endpoint Integration with respect to ecs field process.group.id"
  7updated_date = "2025/02/04"
  8
  9[rule]
 10author = ["Elastic"]
 11description = """
 12This rule detects potential sudo token manipulation attacks through process injection by monitoring the use of a
 13debugger (gdb) process followed by a successful uid change event during the execution of the sudo process. A sudo token
 14manipulation attack is performed by injecting into a process that has a valid sudo token, which can then be used by
 15attackers to activate their own sudo token. This attack requires ptrace to be enabled in conjunction with the existence
 16of a living process that has a valid sudo token with the same uid as the current user.
 17"""
 18from = "now-9m"
 19index = ["logs-endpoint.events.process*"]
 20language = "eql"
 21license = "Elastic License v2"
 22name = "Potential Sudo Token Manipulation via Process Injection"
 23references = ["https://github.com/nongiach/sudo_inject"]
 24risk_score = 47
 25rule_id = "ff9bc8b9-f03b-4283-be58-ee0a16f5a11b"
 26setup = """## Setup
 27
 28This rule requires data coming in from Elastic Defend.
 29
 30### Elastic Defend Integration Setup
 31Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
 32
 33#### Prerequisite Requirements:
 34- Fleet is required for Elastic Defend.
 35- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
 36
 37#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
 38- Go to the Kibana home page and click "Add integrations".
 39- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
 40- Click "Add Elastic Defend".
 41- Configure the integration name and optionally add a description.
 42- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
 43- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
 44- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
 45- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
 46For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
 47- Click "Save and Continue".
 48- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
 49For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
 50"""
 51severity = "medium"
 52tags = [
 53    "Domain: Endpoint",
 54    "OS: Linux",
 55    "Use Case: Threat Detection",
 56    "Tactic: Privilege Escalation",
 57    "Data Source: Elastic Defend",
 58    "Resources: Investigation Guide",
 59]
 60type = "eql"
 61
 62query = '''
 63sequence by host.id, process.session_leader.entity_id with maxspan=15s
 64[ process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
 65  process.name == "gdb" and process.user.id != "0" and process.group.id != "0" ]
 66[ process where host.os.type == "linux" and event.action == "uid_change" and event.type == "change" and
 67  process.name == "sudo" and process.user.id == "0" and process.group.id == "0" ]
 68'''
 69note = """## Triage and analysis
 70
 71> **Disclaimer**:
 72> 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.
 73
 74### Investigating Potential Sudo Token Manipulation via Process Injection
 75
 76In Linux environments, process injection can be exploited by adversaries to manipulate sudo tokens, allowing unauthorized privilege escalation. Attackers may use debugging tools like gdb to inject code into processes with valid sudo tokens, leveraging ptrace capabilities. The detection rule identifies this threat by monitoring for gdb execution followed by a uid change in the sudo process, indicating potential token manipulation.
 77
 78### Possible investigation steps
 79
 80- Review the alert details to identify the specific host and process session leader entity ID involved in the potential sudo token manipulation.
 81- Examine the process tree on the affected host to trace the parent and child processes of the gdb execution, focusing on any unusual or unauthorized processes.
 82- Check the system logs for any recent sudo commands executed by the user associated with the gdb process to determine if there were any unauthorized privilege escalations.
 83- Investigate the user account associated with the gdb process to verify if it has legitimate reasons to use debugging tools and if it has been compromised.
 84- Analyze the timing and context of the uid change event in the sudo process to assess if it aligns with legitimate administrative activities or if it appears suspicious.
 85- Review the system's ptrace settings to ensure they are configured securely and assess if there have been any recent changes that could have enabled this attack vector.
 86
 87### False positive analysis
 88
 89- Debugging activities by developers or system administrators using gdb for legitimate purposes can trigger this rule. To manage this, create exceptions for specific user IDs or groups known to perform regular debugging tasks.
 90- Automated scripts or maintenance tools that utilize gdb for process analysis might cause false positives. Identify these scripts and exclude their associated process names or paths from the rule.
 91- System monitoring or security tools that perform uid changes as part of their normal operation could be mistaken for malicious activity. Review and whitelist these tools by their process names or specific user IDs.
 92- Training or testing environments where sudo and gdb are used frequently for educational purposes may generate alerts. Consider excluding these environments by host ID or network segment to reduce noise.
 93- Scheduled tasks or cron jobs that involve gdb and sudo processes might inadvertently match the rule criteria. Analyze these tasks and exclude them based on their execution times or specific process attributes.
 94
 95### Response and remediation
 96
 97- Immediately isolate the affected host from the network to prevent further unauthorized access or privilege escalation.
 98- Terminate any suspicious gdb and sudo processes identified in the alert to stop ongoing process injection attempts.
 99- Conduct a thorough review of the affected system's process and user activity logs to identify any unauthorized changes or access patterns.
100- Reset credentials and sudo tokens for all users on the affected system to prevent further exploitation using compromised tokens.
101- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited.
102- Re-enable ptrace restrictions if they were previously disabled, to limit the ability of attackers to perform process injection.
103- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network."""
104
105
106[[rule.threat]]
107framework = "MITRE ATT&CK"
108[[rule.threat.technique]]
109id = "T1055"
110name = "Process Injection"
111reference = "https://attack.mitre.org/techniques/T1055/"
112[[rule.threat.technique.subtechnique]]
113id = "T1055.008"
114name = "Ptrace System Calls"
115reference = "https://attack.mitre.org/techniques/T1055/008/"
116
117
118[[rule.threat.technique]]
119id = "T1548"
120name = "Abuse Elevation Control Mechanism"
121reference = "https://attack.mitre.org/techniques/T1548/"
122[[rule.threat.technique.subtechnique]]
123id = "T1548.003"
124name = "Sudo and Sudo Caching"
125reference = "https://attack.mitre.org/techniques/T1548/003/"
126
127
128
129[rule.threat.tactic]
130id = "TA0004"
131name = "Privilege Escalation"
132reference = "https://attack.mitre.org/tactics/TA0004/"