Linux and Mac Permissions

On Linux and macOS, a file's permission bits control not just who can read or write it, but whether it runs with the privileges of the user who launched it, or the privileges of whoever owns the file. The setuid bit specifically makes a program run as its owner, regardless of who actually executes it, which is exactly how a small number of legitimate system utilities are able to do privileged things on behalf of an ordinary user.

Setting that same bit on an attacker-placed file turns an ordinary copy of a shell into a standing, reusable way to become root, without needing to exploit anything or use sudo at all, every single time it's run.

Once an attacker has root access, even briefly, a very durable way to keep it is to copy a shell binary somewhere unremarkable, then set the setuid bit on that copy with `chmod +s` or an equivalent. From that point on, anyone who can execute that specific file gets a root shell instantly, completely independent of whatever got the attacker root access in the first place.

This is what makes it a persistence technique rather than just an escalation one: even if the original vulnerability is patched or the sudoers misconfiguration is fixed, this backdoor keeps working, since it doesn't depend on either of those things anymore.

Data source: auditd chmod/fchmodat syscall records -- the granted mode is in the raw arguments, not the file mode field -- plus the execve record for the calling process

{
  "host": {
    "name": "signet-host"
  },
  "event": {
    "code": "1",
    "action": "exec"
  },
  "process": {
    "name": "chmod",
    "command_line": "chmod u+s /usr/local/bin/.cache/sh"
  }
}

Prebuilt Elastic rule: SUID/SGID Bit Set

Filter process-creation events for chmod or install with setuid/setgid-setting arguments, then look closely at the target file. The overwhelming majority of legitimate setuid binaries are well-known, standard system utilities in expected locations; a setuid bit newly appearing on a file in a user's home directory, a temp folder, or anywhere off the normal system path is a strong signal on its own.

Once a suspicious setuid file is found, checking its actual contents or hash against known-good system binaries (rather than trusting the filename) confirms whether it's a genuine copy of something like a shell, since an attacker has no reason to name it obviously.

Package installation and system updates legitimately set the setuid bit on a defined, expected set of system binaries as part of completely normal operation, and configuration management tools may do the same for specific, sanctioned utilities.

The distinguishing signal is location and identity: the setuid bit appearing on a well-known system path during a package manager's own process is routine; the same bit appearing on a file sitting somewhere it has no business being, especially one that turns out to be a shell interpreter, is not.

• MITRE ATT&CK T1222.002: Linux and Mac File and Directory Permissions Modification
• Elastic Security: SUID/SGID Bit Set

1 scenario in this catalog covers T1222.002. We don't name it — identifying the technique is part of what a scenario grades. Explore the dashboard →