Elastic
Start free trial
Loading

Potential Privilege Escalation via UID INT_MAX Bug Detected

Elastic Stack Serverless Security

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.

Rule type: eql

Rule indices:

  • logs-endpoint.events.*
  • endgame-*
  • logs-crowdstrike.fdr*

Severity: medium

Risk score: 47

Runs every: 5m

Searches indices from: now-9m (https://www.elastic.co/guide/en/elasticsearch/reference/current/common-options.html#date-math[Date Math format], see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

  • Domain: Endpoint
  • OS: Linux
  • Use Case: Threat Detection
  • Tactic: Privilege Escalation
  • Data Source: Elastic Defend
  • Data Source: Elastic Endgame
  • Data Source: Crowdstrike
  • Resources: Investigation Guide

Version: 7

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

Triage and analysis

[TBC: QUOTE]
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.

Setup

Setup

This rule requires data coming in from Elastic Defend.

Elastic Defend Integration Setup

Elastic 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.

Prerequisite Requirements:

  • Fleet is required for Elastic Defend.
  • To configure Fleet Server refer to the documentation.

The following steps should be executed in order to add the Elastic Defend integration on a Linux System:

  • Go to the Kibana home page and click "Add integrations".
  • In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
  • Click "Add Elastic Defend".
  • Configure the integration name and optionally add a description.
  • Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
  • 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.
  • We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
  • 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. For more details on Elastic Agent configuration settings, refer to the helper guide.
  • Click "Save and Continue".
  • 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. For more details on Elastic Defend refer to the helper guide.

Rule query

process where host.os.type == "linux" and event.type == "start" and
  event.action in ("exec", "exec_event", "ProcessRollup2") and
  process.name == "systemd-run" and process.args == "-t" and process.args_count >= 3 and user.id >= "1000000000"

Framework: MITRE ATT&CKTM