Potential Root Effective Shell from Non-Standard Path via Auditd

Identifies process execution events where the effective user is root while the real user is not, the process arguments include the privileged shell flag commonly associated with setuid-capable shells, and the executable path is outside standard system binary directories. That combination is consistent with abuse of setuid shells or similar helpers copied or linked into writable locations, a pattern used to regain a root context after local exploitation.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/04/24"
  3integration = ["auditd_manager"]
  4maturity = "production"
  5updated_date = "2026/04/24"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies process execution events where the effective user is root while the real user is not, the process arguments
 11include the privileged shell flag commonly associated with setuid-capable shells, and the executable path is outside
 12standard system binary directories. That combination is consistent with abuse of setuid shells or similar helpers
 13copied or linked into writable locations, a pattern used to regain a root context after local exploitation.
 14"""
 15false_positives = [
 16    """
 17    Custom administrative wrappers or hardened images that legitimately ship a setuid shell outside /usr/bin or /bin
 18    for emergency access may match; document and exclude by executable hash or path when verified.
 19    """,
 20    """
 21    Field mapping differences between auditd versions can occasionally mis-populate effective versus real user IDs;
 22    validate raw audit fields when triaging unexpected hits.
 23    """,
 24]
 25from = "now-9m"
 26index = ["auditbeat-*", "logs-auditd_manager.auditd-*"]
 27language = "kuery"
 28license = "Elastic License v2"
 29name = "Potential Root Effective Shell from Non-Standard Path via Auditd"
 30note = """## Triage and analysis
 31
 32### Investigating Potential Root Effective Shell from Non-Standard Path via Auditd
 33
 34The rule surfaces executed processes where effective UID is root, real UID is not, the argument list contains -p
 35(often used with bash, dash, or similar to preserve privileges), and the executable is not under typical distro paths.
 36That aligns with interactive or scripted abuse of elevated shells from user-controlled locations.
 37
 38### Possible investigation steps
 39
 40- Inspect process.executable, process.args, process.parent, and the full command line reconstructed in audit or ECS
 41  fields.
 42- Confirm user.id versus user.effective.id and map the login session, TTY, and parent chain (SSH, cron, container
 43  entrypoint).
 44- Check the on-disk binary for setuid bit, ownership, and recent file creation or rename events in the same directory.
 45- Correlate with authentication logs and sudo or polkit outcomes around the same timestamp.
 46
 47### False positive analysis
 48
 49- Rare vendor bundles that place setuid helpers under /opt or /usr/local may need allowlisting after review.
 50- Container hosts where audit captures host and namespace PIDs together can add noise; scope by host group if needed.
 51
 52### Response and remediation
 53
 54- If malicious, isolate the host, remove or quarantine the binary, revoke compromised accounts, audit all setuid
 55  binaries on the filesystem, and re-image if integrity cannot be proven.
 56"""
 57references = [
 58    "https://attack.mitre.org/techniques/T1548/001/",
 59    "https://gtfobins.github.io/gtfobins/bash/",
 60]
 61risk_score = 73
 62rule_id = "7f3a9c2e-1d4b-5e6f-8a9b-0c1d2e3f4a5b"
 63setup = """## Setup
 64
 65This rule requires data from Auditd Manager or legacy Auditbeat shipping comparable ECS process fields on Linux.
 66
 67### Auditd Manager Integration Setup
 68Auditd Manager receives events from the Linux audit subsystem. Deploy the integration from Kibana under Integrations,
 69add it to an agent policy, and install the Elastic Agent on Linux hosts that should emit syscall-backed process data.
 70
 71For integration details, see the [Auditd Manager documentation](https://docs.elastic.co/integrations/auditd_manager).
 72
 73Ensure process execution (for example execve) is audited so `event.action`, `user.id`, `user.effective.id`,
 74`process.args`, and `process.executable` are populated consistently for interactive shells.
 75"""
 76severity = "high"
 77tags = [
 78    "Domain: Endpoint",
 79    "OS: Linux",
 80    "Use Case: Threat Detection",
 81    "Tactic: Privilege Escalation",
 82    "Data Source: Auditd Manager",
 83    "Resources: Investigation Guide",
 84]
 85timestamp_override = "event.ingested"
 86type = "query"
 87query = '''
 88host.os.type:linux and event.category:process and 
 89event.action:(exec or executed) and user.id:(* and not 0) and 
 90process.executable:(* and not (/bin/* or /nix/store/*/bin/sudo or /run/wrappers/wrappers*/sudo or /sbin/* or /usr/bin/* or /usr/sbin/*)) and 
 91user.effective.id:0 and process.args:-p
 92'''
 93
 94[[rule.threat]]
 95framework = "MITRE ATT&CK"
 96
 97[[rule.threat.technique]]
 98id = "T1548"
 99name = "Abuse Elevation Control Mechanism"
100reference = "https://attack.mitre.org/techniques/T1548/"
101
102[[rule.threat.technique.subtechnique]]
103id = "T1548.001"
104name = "Setuid and Setgid"
105reference = "https://attack.mitre.org/techniques/T1548/001/"
106
107[rule.threat.tactic]
108id = "TA0004"
109name = "Privilege Escalation"
110reference = "https://attack.mitre.org/tactics/TA0004/"

Triage and analysis

Investigating Potential Root Effective Shell from Non-Standard Path via Auditd

The rule surfaces executed processes where effective UID is root, real UID is not, the argument list contains -p (often used with bash, dash, or similar to preserve privileges), and the executable is not under typical distro paths. That aligns with interactive or scripted abuse of elevated shells from user-controlled locations.

Possible investigation steps

  • Inspect process.executable, process.args, process.parent, and the full command line reconstructed in audit or ECS fields.
  • Confirm user.id versus user.effective.id and map the login session, TTY, and parent chain (SSH, cron, container entrypoint).
  • Check the on-disk binary for setuid bit, ownership, and recent file creation or rename events in the same directory.
  • Correlate with authentication logs and sudo or polkit outcomes around the same timestamp.

False positive analysis

  • Rare vendor bundles that place setuid helpers under /opt or /usr/local may need allowlisting after review.
  • Container hosts where audit captures host and namespace PIDs together can add noise; scope by host group if needed.

Response and remediation

  • If malicious, isolate the host, remove or quarantine the binary, revoke compromised accounts, audit all setuid binaries on the filesystem, and re-image if integrity cannot be proven.

References

Related rules

to-top