Potential Sudo Hijacking

Identifies the creation of a sudo binary located at /usr/bin/sudo. Attackers may hijack the default sudo binary and replace it with a custom binary or script that can read the user's password in clear text to escalate privileges or enable persistence onto the system every time the sudo binary is executed.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2023/07/26"
  3integration = ["endpoint"]
  4maturity = "production"
  5updated_date = "2025/12/23"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies the creation of a sudo binary located at /usr/bin/sudo. Attackers may hijack the default sudo binary and
 11replace it with a custom binary or script that can read the user's password in clear text to escalate privileges or
 12enable persistence onto the system every time the sudo binary is executed.
 13"""
 14from = "now-9m"
 15index = ["logs-endpoint.events.file*"]
 16language = "eql"
 17license = "Elastic License v2"
 18name = "Potential Sudo Hijacking"
 19note = """## Triage and analysis
 20
 21> **Disclaimer**:
 22> 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.
 23
 24### Investigating Potential Sudo Hijacking
 25
 26Sudo is a critical utility in Linux environments, allowing users to execute commands with elevated privileges. Adversaries may exploit this by replacing the sudo binary with a malicious version to capture passwords or maintain persistence. The detection rule identifies suspicious creation or renaming of the sudo binary, excluding legitimate package management processes, to flag potential hijacking attempts.
 27
 28### Possible investigation steps
 29
 30- Review the file creation or rename event details to confirm the file path is either /usr/bin/sudo or /bin/sudo, as these are critical locations for the sudo binary.
 31- Check the process executable that triggered the event to ensure it is not part of the legitimate package management processes listed in the query, such as /bin/dpkg or /usr/bin/yum.
 32- Investigate the user account associated with the event to determine if the activity aligns with their typical behavior or if it appears suspicious.
 33- Examine the system logs around the time of the event for any unusual activity or errors that might indicate tampering or unauthorized access.
 34- Verify the integrity of the current sudo binary by comparing its hash with a known good version to detect any unauthorized modifications.
 35- Assess the system for any additional signs of compromise, such as unexpected network connections or new user accounts, which may indicate broader malicious activity.
 36
 37### False positive analysis
 38
 39- Package management processes can trigger false positives when legitimate updates or installations occur. To handle this, ensure that processes like dpkg, rpm, yum, and apt are included in the exclusion list as they are common package managers.
 40- Custom scripts or automation tools that modify the sudo binary for legitimate reasons may cause alerts. Review these scripts and consider adding their paths to the exclusion list if they are verified as safe.
 41- Temporary files or directories used during legitimate software installations or updates, such as those in /var/lib/dpkg or /tmp, can lead to false positives. Exclude these paths if they are part of a known and safe process.
 42- Development or testing environments where sudo binaries are frequently modified for testing purposes might trigger alerts. In such cases, consider excluding these environments from monitoring or adding specific exclusions for known safe modifications.
 43- Ensure that any process or executable that is known to interact with the sudo binary in a non-malicious way is added to the exclusion list to prevent unnecessary alerts.
 44
 45### Response and remediation
 46
 47- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker.
 48- Verify the integrity of the sudo binary by comparing its hash with a known good version from a trusted source. If compromised, replace it with the legitimate binary.
 49- Conduct a thorough review of system logs and the process execution history to identify any unauthorized changes or suspicious activities related to the sudo binary.
 50- Reset passwords for all user accounts on the affected system, especially those with elevated privileges, to mitigate potential credential theft.
 51- Implement additional monitoring on the affected system and similar environments to detect any further attempts to modify critical binaries or escalate privileges.
 52- Escalate the incident to the security operations team for a comprehensive investigation and to determine if other systems may be affected.
 53- Review and update access controls and permissions to ensure that only authorized personnel can modify critical system binaries."""
 54references = [
 55    "https://eapolsniper.github.io/2020/08/17/Sudo-Hijacking/",
 56    "https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms",
 57]
 58risk_score = 47
 59rule_id = "88fdcb8c-60e5-46ee-9206-2663adf1b1ce"
 60setup = """## Setup
 61
 62This rule requires data coming in from Elastic Defend.
 63
 64### Elastic Defend Integration Setup
 65Elastic 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.
 66
 67#### Prerequisite Requirements:
 68- Fleet is required for Elastic Defend.
 69- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
 70
 71#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
 72- Go to the Kibana home page and click "Add integrations".
 73- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
 74- Click "Add Elastic Defend".
 75- Configure the integration name and optionally add a description.
 76- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
 77- 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).
 78- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
 79- 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.
 80For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
 81- Click "Save and Continue".
 82- 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.
 83For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
 84"""
 85severity = "medium"
 86tags = [
 87    "Domain: Endpoint",
 88    "OS: Linux",
 89    "Use Case: Threat Detection",
 90    "Tactic: Privilege Escalation",
 91    "Tactic: Persistence",
 92    "Data Source: Elastic Defend",
 93    "Resources: Investigation Guide",
 94]
 95timestamp_override = "event.ingested"
 96type = "eql"
 97query = '''
 98file where host.os.type == "linux" and event.action in ("creation", "rename") and
 99file.path in ("/usr/bin/sudo", "/bin/sudo") and not (
100  process.name like ("python*", "platform-python*") or
101  file.Ext.original.path in ("/usr/bin/sudo", "/bin/sudo") or
102  process.executable in (
103    "/bin/dpkg", "/usr/bin/dpkg", "/bin/dockerd", "/usr/bin/dockerd", "/usr/sbin/dockerd", "/bin/microdnf",
104    "/bin/rpm", "/usr/bin/rpm", "/bin/snapd", "/usr/bin/snapd", "/bin/yum", "/usr/bin/yum", "/bin/dnf", "/usr/bin/dnf",
105    "/bin/podman", "/usr/bin/podman", "/bin/dnf-automatic", "/usr/bin/dnf-automatic", "/bin/pacman", "/usr/bin/pacman",
106    "/usr/bin/dpkg-divert", "/bin/dpkg-divert", "/sbin/apk", "/usr/sbin/apk", "/usr/local/sbin/apk", "/usr/bin/apt",
107    "/usr/sbin/pacman", "/usr/bin/microdnf", "/usr/local/bin/dockerd", "/usr/local/bin/podman", "/usr/local/bin/dnf",
108    "/kaniko/executor", "/proc/self/exe", "/usr/bin/apt-get", "/usr/bin/apt-cache", "/usr/bin/apt-mark",
109    "./usr/bin/podman", "./usr/lib/snapd/snap-update-ns", "/kaniko/kaniko-executor", "/usr/libexec/packagekitd",
110    "/usr/bin/dnf5", "/usr/lib/pamac/pamac-daemon", "./usr/libexec/snapd/snap-update-ns", "/usr/bin/update-alternatives"
111  ) or
112  file.Ext.original.extension == "dpkg-new" or
113  process.executable : (
114    "/nix/store/*", "/var/lib/dpkg/*", "/tmp/vmis.*", "/snap/*", "/dev/fd/*", "/var/lib/docker/*",
115    "./snap/snapd/*/usr/lib/snapd/snap-update-ns", "/opt/docker/overlay2/*/dockerd", 
116    "/var/lib/containers/storage/overlay/*/dockerd"
117  ) or
118  process.executable == null or
119  (process.name == "sed" and file.name : "sed*")
120)
121'''
122
123[[rule.threat]]
124framework = "MITRE ATT&CK"
125
126[[rule.threat.technique]]
127id = "T1548"
128name = "Abuse Elevation Control Mechanism"
129reference = "https://attack.mitre.org/techniques/T1548/"
130
131[[rule.threat.technique.subtechnique]]
132id = "T1548.003"
133name = "Sudo and Sudo Caching"
134reference = "https://attack.mitre.org/techniques/T1548/003/"
135
136[rule.threat.tactic]
137id = "TA0004"
138name = "Privilege Escalation"
139reference = "https://attack.mitre.org/tactics/TA0004/"
140
141[[rule.threat]]
142framework = "MITRE ATT&CK"
143
144[[rule.threat.technique]]
145id = "T1574"
146name = "Hijack Execution Flow"
147reference = "https://attack.mitre.org/techniques/T1574/"
148
149[rule.threat.tactic]
150id = "TA0003"
151name = "Persistence"
152reference = "https://attack.mitre.org/tactics/TA0003/"

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 Potential Sudo Hijacking

Sudo is a critical utility in Linux environments, allowing users to execute commands with elevated privileges. Adversaries may exploit this by replacing the sudo binary with a malicious version to capture passwords or maintain persistence. The detection rule identifies suspicious creation or renaming of the sudo binary, excluding legitimate package management processes, to flag potential hijacking attempts.

Possible investigation steps

  • Review the file creation or rename event details to confirm the file path is either /usr/bin/sudo or /bin/sudo, as these are critical locations for the sudo binary.
  • Check the process executable that triggered the event to ensure it is not part of the legitimate package management processes listed in the query, such as /bin/dpkg or /usr/bin/yum.
  • Investigate the user account associated with the event to determine if the activity aligns with their typical behavior or if it appears suspicious.
  • Examine the system logs around the time of the event for any unusual activity or errors that might indicate tampering or unauthorized access.
  • Verify the integrity of the current sudo binary by comparing its hash with a known good version to detect any unauthorized modifications.
  • Assess the system for any additional signs of compromise, such as unexpected network connections or new user accounts, which may indicate broader malicious activity.

False positive analysis

  • Package management processes can trigger false positives when legitimate updates or installations occur. To handle this, ensure that processes like dpkg, rpm, yum, and apt are included in the exclusion list as they are common package managers.
  • Custom scripts or automation tools that modify the sudo binary for legitimate reasons may cause alerts. Review these scripts and consider adding their paths to the exclusion list if they are verified as safe.
  • Temporary files or directories used during legitimate software installations or updates, such as those in /var/lib/dpkg or /tmp, can lead to false positives. Exclude these paths if they are part of a known and safe process.
  • Development or testing environments where sudo binaries are frequently modified for testing purposes might trigger alerts. In such cases, consider excluding these environments from monitoring or adding specific exclusions for known safe modifications.
  • Ensure that any process or executable that is known to interact with the sudo binary in a non-malicious way is added to the exclusion list to prevent unnecessary alerts.

Response and remediation

  • Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker.
  • Verify the integrity of the sudo binary by comparing its hash with a known good version from a trusted source. If compromised, replace it with the legitimate binary.
  • Conduct a thorough review of system logs and the process execution history to identify any unauthorized changes or suspicious activities related to the sudo binary.
  • Reset passwords for all user accounts on the affected system, especially those with elevated privileges, to mitigate potential credential theft.
  • Implement additional monitoring on the affected system and similar environments to detect any further attempts to modify critical binaries or escalate privileges.
  • Escalate the incident to the security operations team for a comprehensive investigation and to determine if other systems may be affected.
  • Review and update access controls and permissions to ensure that only authorized personnel can modify critical system binaries.

References

Related rules

to-top