Artifact Analysis: Sudo Rights & Privilege Escalation (sudoers)

Note

Executive Summary: The sudo (SuperUser DO) utility is the standard mechanism in Unix-like systems allowing authorized users to execute commands as root (or another user) while generating an audit trail. For DFIR analysts, analyzing the sudo configuration files during a post-mortem investigation provides the definitive answer to a critical question: “Who has the legal (or illegal) right to become root on this machine?” Threat actors frequently manipulate these files to establish stealthy persistence or facilitate Local Privilege Escalation (LPE) without needing to exploit kernel vulnerabilities.

1. Artifact Locations (The Configuration Puzzle)

The sudo configuration is rarely confined to a single file. System administrators and automated provisioning tools (like Ansible or Terraform) heavily utilize modular drop-in directories.

Assuming the compromised forensic image is mounted at /mnt/analysis/, analysts must inspect two primary locations:

1. The Main Configuration File: /mnt/analysis/etc/sudoers
2. The Drop-in Directory: /mnt/analysis/etc/sudoers.d/

Danger

DFIR Focus: The /etc/sudoers.d/ directory is an attacker’s favorite hiding spot. Instead of modifying the highly scrutinized main sudoers file—which risks breaking system stability or being overwritten by OS updates—an adversary will quietly drop a small, innocuously named file (e.g., backup-agent or 01-system-update) into this directory.

2. Decoding Sudo Syntax

The sudoers syntax dictates exactly what actions are permitted. It follows a strict paradigm: WHO WHERE=(AS_WHO) WHAT

To hunt for malicious modifications, analysts must understand how to read these rules:

• The “Open Bar” Rule (Dangerous): nico ALL=(ALL:ALL) ALL

  • Who: user nico
  • Where: on all hosts (ALL)
  • As Who: as any user or any group (ALL:ALL)
  • What: can run any command (ALL).

• The “NOPASSWD” Directive (The Attacker’s Dream): www-data ALL=(ALL) NOPASSWD: ALL

  • This rule allows the www-data web service account to become root without ever typing a password. If threat actors deploy a webshell on a server with this configuration, they immediately achieve root dominance without needing a secondary exploit.

3. The GTFOBins Trap (Subtle Privilege Escalation)

Administrators often attempt to apply the Principle of Least Privilege by restricting a user to a single, specific administrative command. However, this often creates a severe vulnerability.

• The Intent: backup ALL=(root) /usr/bin/find (The backup user is only allowed to use the find command to locate files).
• The Flaw: Many native Unix binaries possess interactive features or the ability to spawn subshells. The find command, for instance, has an -exec flag.
• The Attack: sudo find . -exec /bin/sh \;

By executing this command, the attacker instantly bypasses the restriction and spawns an interactive root shell.

This concept is known as GTFOBins (Get The F*** Out Binaries). Hundreds of legitimate binaries (vim, less, awk, tar, python, nmap) can be abused in this manner. If you observe a highly specific binary authorized in the sudoers file, cross-reference it with the GTFOBins repository to determine if it allows shell escapes.

4. DFIR Triage & File Integrity

When conducting offline analysis, you must examine the files’ metadata before analyzing their content.

1. MAC Times Analysis: Check the modification time (mtime) of /etc/sudoers and all files within /etc/sudoers.d/. A recent modification timestamp that aligns with the suspected intrusion window is definitive proof of an LPE or persistence attempt.
2. File Permissions: By design, sudoers files must be read-only (0440 or -r--r-----). If a file within /etc/sudoers.d/ possesses writable permissions (0640 or higher), it is a severe anomaly indicating tampering or gross misconfiguration.

5. Automated Hunting Queries

Bash (Offline Audit Script)

audit_sudoers_offline.sh

#!/bin/bash
TARGET_DIR="/mnt/analysis"

echo "[+] Auditing main sudoers file for NOPASSWD..."
grep -E -i "nopasswd" $TARGET_DIR/etc/sudoers | grep -v "^#"

echo "[+] Auditing sudoers.d drop-in directory..."
grep -rE -i "nopasswd" $TARGET_DIR/etc/sudoers.d/ | grep -v "^#"

echo "[+] Checking for dangerous file permissions (Should be 440)..."
stat -c "%a %n" $TARGET_DIR/etc/sudoers $TARGET_DIR/etc/sudoers.d/* | grep -v "440"

Sigma (Live Hunting)

sigma_sudo_gtfobins_execution.yaml

title: Sudo Execution of Potential GTFOBins
id: 1a2b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d
status: experimental
description: Detects the execution of known GTFOBins via sudo, a common technique for escaping restricted environments and achieving LPE.
logsource:
    category: process_creation
    product: linux
detection:
    selection:
        Image|endswith: '/sudo'
        CommandLine|contains|any:
            - ' find '
            - ' awk '
            - ' nmap '
            - ' vim '
            - ' less '
            - ' tar '
        CommandLine|contains|any:
            - '-exec '
            - '--exec '
            - '!/bin/sh'
            - 'os.system'
    condition: selection
level: high
tags:
    - attack.privilege_escalation
    - attack.t1548.003

Correlation Next Steps

If you identify a malicious rule, pivot immediately to the Linux Authentication Logs (auth.log or secure). Query the logs for COMMAND= to identify exactly when the attacker utilized their newly minted sudo privileges and which post-exploitation commands they executed. Furthermore, review the Account Analysis to check if the attacker added themselves directly to the sudo or wheel groups in /etc/group.

---

References & Further Reading

• GTFOBins: Bypassing local security restrictions
• MITRE ATT&CK: Abuse Elevation Control Mechanism: Sudo and Sudo Caching (T1548.003)
• Related Artifact: Linux Account & Privilege Analysis
• Related Artifact: Linux Authentication Logs (auth.log)