Process Capability Set via setcap Utility

  1[metadata]
  2creation_date = "2024/06/03"
  3integration = ["endpoint", "sentinel_one_cloud_funnel"]
  4maturity = "production"
  5min_stack_version = "8.13.0"
  6min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
  7updated_date = "2025/01/15"
  8
  9[rule]
 10author = ["Elastic"]
 11description = """
 12This rule detects the use of the setcap utility to set capabilities on a process. The setcap utility is used to set the
 13capabilities of a binary to allow it to perform privileged operations without needing to run as root. This can be used
 14by attackers to establish persistence by creating a backdoor, or escalate privileges by abusing a misconfiguration on a
 15system.
 16"""
 17from = "now-9m"
 18index = ["logs-endpoint.events.process*", "endgame-*", "logs-sentinel_one_cloud_funnel.*"]
 19language = "eql"
 20license = "Elastic License v2"
 21name = "Process Capability Set via setcap Utility"
 22risk_score = 21
 23rule_id = "f18a474c-3632-427f-bcf5-363c994309ee"
 24setup = """## Setup
 25
 26This rule requires data coming in from Elastic Defend.
 27
 28### Elastic Defend Integration Setup
 29Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows
 30the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
 31
 32#### Prerequisite Requirements:
 33- Fleet is required for Elastic Defend.
 34- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
 35
 36#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
 37- Go to the Kibana home page and click "Add integrations".
 38- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
 39- Click "Add Elastic Defend".
 40- Configure the integration name and optionally add a description.
 41- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
 42- 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).
 43- We suggest to select "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
 44- 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.
 45For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
 46- Click "Save and Continue".
 47- 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.
 48For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
 49"""
 50severity = "low"
 51tags = [
 52    "Domain: Endpoint",
 53    "OS: Linux",
 54    "Use Case: Threat Detection",
 55    "Tactic: Persistence",
 56    "Tactic: Privilege Escalation",
 57    "Data Source: Elastic Endgame",
 58    "Data Source: Elastic Defend",
 59    "Data Source: SentinelOne",
 60    "Resources: Investigation Guide"
 61]
 62timestamp_override = "event.ingested"
 63type = "eql"
 64query = '''
 65process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start") and
 66process.name == "setcap" and not (
 67  process.parent.executable == null or
 68  process.parent.executable : ("/var/lib/dpkg/*", "/var/lib/docker/*", "/tmp/newroot/*", "/var/tmp/newroot/*") or
 69  process.parent.name in ("jem", "vzctl")
 70)
 71'''
 72note = """## Triage and analysis
 73
 74> **Disclaimer**:
 75> 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.
 76
 77### Investigating Process Capability Set via setcap Utility
 78
 79The `setcap` utility in Linux assigns specific capabilities to executables, allowing them to perform privileged tasks without full root access. While beneficial for security, adversaries can exploit this to maintain persistence or escalate privileges by misconfiguring capabilities. The detection rule identifies suspicious `setcap` usage by monitoring process execution patterns, excluding benign parent processes, to flag potential misuse.
 80
 81### Possible investigation steps
 82
 83- Review the process execution details to confirm the use of the setcap utility, focusing on the process name and event action fields to ensure the alert is not a false positive.
 84- Investigate the parent process executable and name to determine if the setcap command was executed by a potentially malicious or unexpected process, especially if it is not among the excluded benign parent processes.
 85- Check the capabilities that were set by the setcap command to assess if they could allow privilege escalation or persistence, and determine if they align with normal operational requirements.
 86- Examine the timeline of events around the setcap execution to identify any preceding or subsequent suspicious activities that might indicate a broader attack or compromise.
 87- Correlate the alert with other security events or logs from the same host to identify any patterns or additional indicators of compromise that could suggest a coordinated attack.
 88
 89### False positive analysis
 90
 91- Legitimate software installations or updates may trigger the rule when package managers like dpkg or Docker set capabilities during their processes. To handle this, exclude paths such as /var/lib/dpkg/* and /var/lib/docker/* from the detection rule.
 92- Development environments or containerized applications might use setcap for testing purposes. Exclude processes originating from /tmp/newroot/* and /var/tmp/newroot/* to reduce noise from these environments.
 93- Custom scripts or administrative tools that use setcap for legitimate configuration tasks can be excluded by identifying their parent process names and adding them to the exclusion list, similar to the existing exclusions for jem and vzctl.
 94- Regular audits of the exclusion list should be conducted to ensure that no malicious processes are inadvertently whitelisted, maintaining a balance between reducing false positives and ensuring security.
 95
 96### Response and remediation
 97
 98- Immediately isolate the affected system from the network to prevent potential lateral movement by the attacker.
 99- Terminate any suspicious processes associated with the `setcap` utility that are not part of legitimate administrative tasks.
100- Review and remove any unnecessary capabilities set on executables using the `setcap` utility to prevent privilege escalation.
101- Conduct a thorough audit of the system to identify any backdoors or unauthorized changes made by the attacker, and remove them.
102- Restore affected systems from a known good backup if unauthorized changes or persistent threats are detected.
103- Escalate the incident to the security operations team for further investigation and to determine if additional systems are compromised.
104- Implement enhanced monitoring and logging for `setcap` usage and similar privilege escalation attempts to improve future detection capabilities."""
105
106[[rule.threat]]
107framework = "MITRE ATT&CK"
108
109[rule.threat.tactic]
110id = "TA0003"
111name = "Persistence"
112reference = "https://attack.mitre.org/tactics/TA0003/"
113
114[[rule.threat]]
115framework = "MITRE ATT&CK"
116
117[rule.threat.tactic]
118id = "TA0004"
119name = "Privilege Escalation"
120reference = "https://attack.mitre.org/tactics/TA0004/"