Potential Privilege Escalation via UID INT_MAX Bug Detected
This rule monitors for the execution of the systemd-run command by a user with a UID that is larger than the maximum allowed UID size (INT_MAX). Some older Linux versions were affected by a bug which allows user accounts with a UID greater than INT_MAX to escalate privileges by spawning a shell through systemd-run.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2023/07/27"
3integration = ["endpoint", "crowdstrike"]
4maturity = "production"
5updated_date = "2025/01/15"
6
7[rule]
8author = ["Elastic"]
9description = """
10This rule monitors for the execution of the systemd-run command by a user with a UID that is larger than the maximum
11allowed UID size (INT_MAX). Some older Linux versions were affected by a bug which allows user accounts with a UID
12greater than INT_MAX to escalate privileges by spawning a shell through systemd-run.
13"""
14from = "now-9m"
15index = ["logs-endpoint.events.*", "endgame-*", "logs-crowdstrike.fdr*"]
16language = "eql"
17license = "Elastic License v2"
18name = "Potential Privilege Escalation via UID INT_MAX Bug Detected"
19references = [
20 "https://twitter.com/paragonsec/status/1071152249529884674",
21 "https://github.com/mirchr/security-research/blob/master/vulnerabilities/CVE-2018-19788.sh",
22 "https://gitlab.freedesktop.org/polkit/polkit/-/issues/74",
23]
24risk_score = 47
25rule_id = "d55436a8-719c-445f-92c4-c113ff2f9ba5"
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 "Data Source: Elastic Endgame",
59 "Data Source: Crowdstrike",
60 "Resources: Investigation Guide",
61]
62timestamp_override = "event.ingested"
63type = "eql"
64
65query = '''
66process where host.os.type == "linux" and event.type == "start" and
67 event.action in ("exec", "exec_event", "ProcessRollup2") and
68 process.name == "systemd-run" and process.args == "-t" and process.args_count >= 3 and user.id >= "1000000000"
69'''
70note = """## Triage and analysis
71
72> **Disclaimer**:
73> 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.
74
75### Investigating Potential Privilege Escalation via UID INT_MAX Bug Detected
76
77In certain Linux environments, systemd-run is a utility that allows users to create and start a transient service or scope unit. A bug in older Linux versions permits users with a UID exceeding INT_MAX to exploit this utility for privilege escalation, potentially gaining unauthorized access. The detection rule identifies suspicious executions of systemd-run by monitoring for processes initiated by users with unusually high UIDs, signaling potential exploitation attempts.
78
79### Possible investigation steps
80
81- Review the alert details to confirm the presence of a user with a UID greater than INT_MAX, as indicated by the user.id field in the query.
82- Examine the process execution context, including the process.args and process.args_count fields, to verify the use of systemd-run with the specified arguments, which may indicate an exploitation attempt.
83- Check the system logs for any other suspicious activities or anomalies around the time of the alert, focusing on processes initiated by the same user or related to systemd-run.
84- Investigate the history and purpose of the user account with the high UID to determine if it was intentionally created or if it appears to be an anomaly.
85- Assess the affected system's Linux version to determine if it is one of the older versions known to be vulnerable to this bug, and consider updating or patching if necessary.
86- Look for any additional indicators of compromise or privilege escalation attempts on the system, such as unauthorized access to sensitive files or changes in user permissions.
87
88### False positive analysis
89
90- High UID service accounts: Some legitimate service accounts may have UIDs exceeding INT_MAX for specific operational purposes. Review these accounts and, if verified as non-threatening, add them to an exception list to prevent unnecessary alerts.
91- Custom scripts or automation tools: Organizations may use scripts or tools that invoke systemd-run with high UID accounts for legitimate tasks. Identify these scripts and whitelist their execution paths or specific user IDs to reduce false positives.
92- Testing environments: In testing or development environments, users might intentionally create accounts with high UIDs to test system behavior. Ensure these environments are isolated and consider excluding them from monitoring to avoid false alerts.
93- Legacy systems: Older systems might have configurations that inadvertently trigger this rule. Conduct a thorough review of these systems and apply exceptions where the behavior is deemed safe and necessary for operational continuity.
94
95### Response and remediation
96
97- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
98- Terminate any suspicious processes initiated by users with UIDs exceeding INT_MAX, especially those involving systemd-run, to halt potential privilege escalation.
99- Conduct a thorough review of user accounts on the affected system to identify and disable any accounts with UIDs greater than INT_MAX.
100- Apply available patches or updates to the Linux operating system to address the specific bug related to UID handling in systemd-run.
101- Review and adjust user account creation policies to ensure no new accounts are created with UIDs exceeding the standard range.
102- Monitor for any further attempts to exploit this vulnerability by setting up alerts for similar suspicious activities, focusing on high UID values and systemd-run usage.
103- Report the incident to the appropriate internal security team or external authorities if necessary, providing details of the exploit and actions taken."""
104
105
106[[rule.threat]]
107framework = "MITRE ATT&CK"
108[[rule.threat.technique]]
109id = "T1068"
110name = "Exploitation for Privilege Escalation"
111reference = "https://attack.mitre.org/techniques/T1068/"
112
113
114[rule.threat.tactic]
115id = "TA0004"
116name = "Privilege Escalation"
117reference = "https://attack.mitre.org/tactics/TA0004/"
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 Privilege Escalation via UID INT_MAX Bug Detected
In certain Linux environments, systemd-run is a utility that allows users to create and start a transient service or scope unit. A bug in older Linux versions permits users with a UID exceeding INT_MAX to exploit this utility for privilege escalation, potentially gaining unauthorized access. The detection rule identifies suspicious executions of systemd-run by monitoring for processes initiated by users with unusually high UIDs, signaling potential exploitation attempts.
Possible investigation steps
- Review the alert details to confirm the presence of a user with a UID greater than INT_MAX, as indicated by the user.id field in the query.
- Examine the process execution context, including the process.args and process.args_count fields, to verify the use of systemd-run with the specified arguments, which may indicate an exploitation attempt.
- Check the system logs for any other suspicious activities or anomalies around the time of the alert, focusing on processes initiated by the same user or related to systemd-run.
- Investigate the history and purpose of the user account with the high UID to determine if it was intentionally created or if it appears to be an anomaly.
- Assess the affected system's Linux version to determine if it is one of the older versions known to be vulnerable to this bug, and consider updating or patching if necessary.
- Look for any additional indicators of compromise or privilege escalation attempts on the system, such as unauthorized access to sensitive files or changes in user permissions.
False positive analysis
- High UID service accounts: Some legitimate service accounts may have UIDs exceeding INT_MAX for specific operational purposes. Review these accounts and, if verified as non-threatening, add them to an exception list to prevent unnecessary alerts.
- Custom scripts or automation tools: Organizations may use scripts or tools that invoke systemd-run with high UID accounts for legitimate tasks. Identify these scripts and whitelist their execution paths or specific user IDs to reduce false positives.
- Testing environments: In testing or development environments, users might intentionally create accounts with high UIDs to test system behavior. Ensure these environments are isolated and consider excluding them from monitoring to avoid false alerts.
- Legacy systems: Older systems might have configurations that inadvertently trigger this rule. Conduct a thorough review of these systems and apply exceptions where the behavior is deemed safe and necessary for operational continuity.
Response and remediation
- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
- Terminate any suspicious processes initiated by users with UIDs exceeding INT_MAX, especially those involving systemd-run, to halt potential privilege escalation.
- Conduct a thorough review of user accounts on the affected system to identify and disable any accounts with UIDs greater than INT_MAX.
- Apply available patches or updates to the Linux operating system to address the specific bug related to UID handling in systemd-run.
- Review and adjust user account creation policies to ensure no new accounts are created with UIDs exceeding the standard range.
- Monitor for any further attempts to exploit this vulnerability by setting up alerts for similar suspicious activities, focusing on high UID values and systemd-run usage.
- Report the incident to the appropriate internal security team or external authorities if necessary, providing details of the exploit and actions taken.
References
Related rules
- Kernel Load or Unload via Kexec Detected
- Potential Sudo Privilege Escalation via CVE-2019-14287
- Potential Unauthorized Access via Wildcard Injection Detected
- Base16 or Base32 Encoding/Decoding Activity
- Cupsd or Foomatic-rip Shell Execution