UID Elevation from Previously Unknown Executable

Monitors for the elevation of regular user permissions to root permissions through a previously unknown executable. Attackers may attempt to evade detection by hijacking the execution flow and hooking certain functions/syscalls through a rootkit in order to provide easy access to root via a special modified command.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2023/10/26"
  3integration = ["endpoint"]
  4maturity = "production"
  5updated_date = "2025/01/27"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Monitors for the elevation of regular user permissions to root permissions through a previously unknown executable.
 11Attackers may attempt to evade detection by hijacking the execution flow and hooking certain functions/syscalls through
 12a rootkit in order to provide easy access to root via a special modified command.
 13"""
 14from = "now-9m"
 15index = ["logs-endpoint.events.*"]
 16language = "kuery"
 17license = "Elastic License v2"
 18name = "UID Elevation from Previously Unknown Executable"
 19risk_score = 47
 20rule_id = "7787362c-90ff-4b1a-b313-8808b1020e64"
 21setup = """## Setup
 22
 23This rule requires data coming in from Elastic Defend.
 24
 25### Elastic Defend Integration Setup
 26Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows
 27the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
 28
 29#### Prerequisite Requirements:
 30- Fleet is required for Elastic Defend.
 31- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
 32
 33#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
 34- Go to the Kibana home page and click Add integrations.
 35- In the query bar, search for Elastic Defend and select the integration to see more details about it.
 36- Click Add Elastic Defend.
 37- Configure the integration name and optionally add a description.
 38- Select the type of environment you want to protect, either Traditional Endpoints or Cloud Workloads.
 39- 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).
 40- We suggest to select "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
 41- 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.
 42For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
 43- Click Save and Continue.
 44- 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.
 45For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
 46"""
 47severity = "medium"
 48tags = [
 49    "Domain: Endpoint",
 50    "OS: Linux",
 51    "Use Case: Threat Detection",
 52    "Tactic: Privilege Escalation",
 53    "Tactic: Defense Evasion",
 54    "Data Source: Elastic Defend",
 55    "Resources: Investigation Guide",
 56]
 57timestamp_override = "event.ingested"
 58type = "new_terms"
 59
 60query = '''
 61host.os.type:"linux" and event.category:"process" and event.action:"uid_change" and event.type:"change" and user.id:"0"
 62and process.parent.name:("bash" or "dash" or "sh" or "tcsh" or "csh" or "zsh" or "ksh" or "fish") and not (
 63  process.executable:(
 64    /bin/* or /usr/bin/* or /sbin/* or /usr/sbin/* or /snap/* or /tmp/newroot/* or /var/lib/docker/* or /usr/local/* or
 65    /opt/psa/admin/* or /usr/lib/snapd/snap-confine or /opt/dynatrace/* or /opt/microsoft/* or
 66    /var/lib/snapd/snap/bin/node or /opt/gitlab/embedded/sbin/logrotate or /etc/apt/universal-hooks/* or
 67    /opt/puppetlabs/puppet/bin/puppet or /opt/cisco/* or /run/k3s/containerd/* or /usr/lib/postfix/sbin/master or
 68    /usr/libexec/postfix/local or /var/lib/snapd/snap/bin/postgresql* or /opt/puppetlabs/puppet/bin/ruby
 69  ) or
 70  process.name:(
 71    "bash" or "dash" or "sh" or "tcsh" or "csh" or "zsh" or "ksh" or "fish" or "sudo" or "su" or "apt" or "apt-get" or
 72    "aptitude" or "squid" or "snap" or "fusermount" or "pkexec" or "umount" or "master" or "omsbaseline" or "dzdo" or
 73    "sandfly" or "logrotate" or "nix-installer" 
 74  ) or
 75  process.args:/usr/bin/python*
 76)
 77'''
 78note = """## Triage and analysis
 79
 80> **Disclaimer**:
 81> 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.
 82
 83### Investigating UID Elevation from Previously Unknown Executable
 84
 85In Linux environments, UID elevation is a process where a user's permissions are increased, often to root level, allowing full system control. Adversaries exploit this by using unknown executables to hijack execution flow, often via rootkits, to gain unauthorized root access. The detection rule identifies such activities by monitoring for UID changes initiated by non-standard executables, excluding known safe paths and processes, thus highlighting potential privilege escalation attempts.
 86
 87### Possible investigation steps
 88
 89- Review the process details to identify the unknown executable that triggered the alert, focusing on the process.executable field to determine its path and origin.
 90- Examine the parent process information using process.parent.name to understand the context in which the unknown executable was launched, checking for any unusual or unexpected shell activity.
 91- Investigate the user account associated with the UID change by analyzing the user.id field to determine if the account has a history of privilege escalation attempts or if it has been compromised.
 92- Check the system logs for any recent changes or installations that might have introduced the unknown executable, focusing on the time frame around the event.action:"uid_change".
 93- Assess the network activity around the time of the alert to identify any potential external connections or data exfiltration attempts that might correlate with the privilege escalation.
 94- Cross-reference the executable path and name against known threat intelligence databases to determine if it is associated with any known malicious activity or rootkits.
 95- If possible, perform a forensic analysis of the executable to understand its behavior and potential impact on the system, looking for signs of function or syscall hooking as indicated in the rule description.
 96
 97### False positive analysis
 98
 99- Executables in custom directories may trigger false positives if they are legitimate but not included in the known safe paths. Users can mitigate this by adding these directories to the exclusion list in the detection rule.
100- Scripts or binaries executed by system administrators from non-standard locations for maintenance or deployment purposes might be flagged. To handle this, users should document and exclude these specific processes or paths if they are verified as safe.
101- Development or testing environments where new executables are frequently introduced can cause alerts. Users should consider creating exceptions for these environments or paths to reduce noise while ensuring they are monitored separately for any unusual activity.
102- Automated scripts or tools that perform legitimate UID changes but are not part of the standard system paths can be excluded by adding their specific executable paths or names to the rule's exception list.
103- Temporary or ephemeral processes that are part of containerized applications might be flagged. Users should review and exclude these processes if they are confirmed to be part of normal operations.
104
105### Response and remediation
106
107- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
108- Terminate any suspicious processes identified by the detection rule that are not part of the known safe paths or processes.
109- Conduct a thorough review of the affected system's logs to identify any additional indicators of compromise or related suspicious activities.
110- Remove any unauthorized or unknown executables found on the system, especially those involved in the UID elevation attempt.
111- Restore the system from a known good backup if any rootkits or persistent threats are detected that cannot be easily removed.
112- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited.
113- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems."""
114
115[[rule.threat]]
116framework = "MITRE ATT&CK"
117
118[[rule.threat.technique]]
119id = "T1574"
120name = "Hijack Execution Flow"
121reference = "https://attack.mitre.org/techniques/T1574/"
122
123[[rule.threat.technique.subtechnique]]
124id = "T1574.013"
125name = "KernelCallbackTable"
126reference = "https://attack.mitre.org/techniques/T1574/013/"
127
128[rule.threat.tactic]
129id = "TA0004"
130name = "Privilege Escalation"
131reference = "https://attack.mitre.org/tactics/TA0004/"
132
133[[rule.threat]]
134framework = "MITRE ATT&CK"
135
136[[rule.threat.technique]]
137id = "T1014"
138name = "Rootkit"
139reference = "https://attack.mitre.org/techniques/T1014/"
140
141[rule.threat.tactic]
142id = "TA0005"
143name = "Defense Evasion"
144reference = "https://attack.mitre.org/tactics/TA0005/"
145
146[rule.new_terms]
147field = "new_terms_fields"
148value = ["process.executable"]
149
150[[rule.new_terms.history_window_start]]
151field = "history_window_start"
152value = "now-14d"
...
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.

In Linux environments, UID elevation is a process where a user's permissions are increased, often to root level, allowing full system control. Adversaries exploit this by using unknown executables to hijack execution flow, often via rootkits, to gain unauthorized root access. The detection rule identifies such activities by monitoring for UID changes initiated by non-standard executables, excluding known safe paths and processes, thus highlighting potential privilege escalation attempts.

  • Review the process details to identify the unknown executable that triggered the alert, focusing on the process.executable field to determine its path and origin.
  • Examine the parent process information using process.parent.name to understand the context in which the unknown executable was launched, checking for any unusual or unexpected shell activity.
  • Investigate the user account associated with the UID change by analyzing the user.id field to determine if the account has a history of privilege escalation attempts or if it has been compromised.
  • Check the system logs for any recent changes or installations that might have introduced the unknown executable, focusing on the time frame around the event.action:"uid_change".
  • Assess the network activity around the time of the alert to identify any potential external connections or data exfiltration attempts that might correlate with the privilege escalation.
  • Cross-reference the executable path and name against known threat intelligence databases to determine if it is associated with any known malicious activity or rootkits.
  • If possible, perform a forensic analysis of the executable to understand its behavior and potential impact on the system, looking for signs of function or syscall hooking as indicated in the rule description.
  • Executables in custom directories may trigger false positives if they are legitimate but not included in the known safe paths. Users can mitigate this by adding these directories to the exclusion list in the detection rule.
  • Scripts or binaries executed by system administrators from non-standard locations for maintenance or deployment purposes might be flagged. To handle this, users should document and exclude these specific processes or paths if they are verified as safe.
  • Development or testing environments where new executables are frequently introduced can cause alerts. Users should consider creating exceptions for these environments or paths to reduce noise while ensuring they are monitored separately for any unusual activity.
  • Automated scripts or tools that perform legitimate UID changes but are not part of the standard system paths can be excluded by adding their specific executable paths or names to the rule's exception list.
  • Temporary or ephemeral processes that are part of containerized applications might be flagged. Users should review and exclude these processes if they are confirmed to be part of normal operations.
  • Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
  • Terminate any suspicious processes identified by the detection rule that are not part of the known safe paths or processes.
  • Conduct a thorough review of the affected system's logs to identify any additional indicators of compromise or related suspicious activities.
  • Remove any unauthorized or unknown executables found on the system, especially those involved in the UID elevation attempt.
  • Restore the system from a known good backup if any rootkits or persistent threats are detected that cannot be easily removed.
  • Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited.
  • Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems.

Related rules

to-top