Sudo and Sudo Caching

Sudo lets a system administrator grant specific users permission to run specific commands as root, often without re-entering a password each time (the NOPASSWD directive). This is a genuinely useful, common convenience, letting an automated maintenance task or a limited-purpose service account do exactly one privileged thing without full root access.

The trouble is that "exactly one privileged thing" is only as narrow as the command actually is. If that one allowed command can be tricked into spawning a shell, editing an unintended file, or reading something outside its normal scope, the narrow permission an administrator intended becomes a path to a full root shell.

An attacker who's compromised an account with any sudo privilege checks what that account is actually allowed to run as root, usually with `sudo -l`. Many common Unix utilities, when invoked in specific ways, can be made to spawn an interactive shell or execute arbitrary commands even though they weren't designed as privilege-escalation tools, a well-documented pattern often called a "shell escape." Once found, the attacker uses the already-permitted command as a stepping stone to a full root shell, without ever needing to know a password or exploit a software vulnerability.

The privilege was real and intentionally granted. The gap was in trusting that a specific command's normal use case matches every possible way it can be invoked.

Data source: auditd records for each sudo invocation -- the authorization result, the command run, the invoking user -- plus the process-execution records for what it spawned

{
  "host": {
    "name": "signet-host"
  },
  "user": {
    "id": "0"
  },
  "event": {
    "code": "1",
    "action": "exec"
  },
  "process": {
    "name": "sudo",
    "command_line": "sudo /usr/local/bin/backup-check --shell"
  }
}

Prebuilt Elastic rule: Potential Privilege Escalation via Sudoers File Modification

Start from the sudo invocation itself: filter process-creation events for sudo, and look at exactly what was run and by whom. An account using sudo for its one expected, narrow purpose looks very different from the same account suddenly reaching a shell prompt or a command it's never run before.

If a sudoers entry is suspected of being too permissive rather than misused, checking `/etc/sudoers` and any files under `/etc/sudoers.d/` directly for NOPASSWD entries is the more direct path, cross-referenced against which of those entries are genuinely necessary versus leftover convenience that's broader than it needs to be.

NOPASSWD sudo entries are a completely standard part of automation, configuration management tools, monitoring agents, and scheduled maintenance scripts all commonly need exactly this kind of narrow, passwordless privilege for one specific task.

The distinguishing signal is whether the command actually run matches the narrow purpose the entry was created for. A monitoring agent running its one expected health-check command is unremarkable; the same account suddenly invoking something that spawns a shell or touches files outside its normal scope is a very different story, even though both technically "used sudo.

• MITRE ATT&CK T1548.003: Sudo and Sudo Caching
• Elastic Security: Potential Privilege Escalation via Sudoers File Modification

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