How do you detect sudo abuse on Linux?

Watch the configuration, the logs and the process tree. Use auditd file watches on /etc/sudoers and /etc/sudoers.d to catch tampering, and log sudo executions by real users. Parse auth.log or secure for COMMAND= entries naming GTFOBins binaries such as vim, find, awk, less or nmap run as root, and alert on sudo -l by service accounts. At the process level, flag root shells whose parent is an editor, pager or interpreter. Review sudoers regularly for NOPASSWD rules on shell-capable binaries, and use sudoedit and NOEXEC to reduce the attack surface.

Detecting sudo Abuse on Linux: NOPASSWD, GTFOBins and sudoers Changes

Sudo misconfiguration is among the most common Linux escalation paths: a rule allowing a user to run an editor, pager, interpreter or file utility as root lets them shell out to root with a GTFOBins technique (T1548.003). Attackers also edit sudoers to make access permanent. The signals are in the auth log, in process telemetry and in file-integrity events on the sudoers files.

Signals at a Glance

Signal	Where	ATT&CK
sudo -l run by a service or web account	auditd execve, process telemetry	T1548.003
sudo COMMAND= naming a GTFOBins binary (vim, find, awk, less, man, nmap)	auth.log or secure	T1548.003
Root shell spawned by an editor, pager or interpreter	auditd execve, EDR	T1548.003
Write to /etc/sudoers or /etc/sudoers.d	auditd file watch, FIM	T1548.003
Repeated sudo authentication failures or not-in-sudoers messages	auth.log, secure	T1110

Auditing the Configuration Surface

The sudoers files and the sudo binary are the two assets worth watching. File watches give you tamper evidence, and execve records on sudo capture the enumeration step that usually precedes abuse:

# /etc/audit/rules.d/sudo.rules
-w /etc/sudoers -p wa -k sudoers_change
-w /etc/sudoers.d/ -p wa -k sudoers_change
-w /usr/bin/sudo -p x -k sudo_exec
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/sudo -F auid>=1000 -F auid!=-1 -k sudo_by_user
# tune/validate: confirm the sudo path on your distribution, then load with augenrules --load.

Reading auth.log and secure

Each sudo invocation writes a line with the invoking user, the target user and the full command. Parse it, then compare the command binary against the GTFOBins list for your environment. A single hit is a lead, a hit from a service account is an incident:

index=linux sourcetype=linux_secure "sudo:" "COMMAND="
| rex field=_raw "sudo:\s+(?<src_user>\S+)\s+:.*USER=(?<run_as>\S+)\s*;\s*COMMAND=(?<cmd>.+)$"
| where run_as="root"
| eval bin=mvindex(split(mvindex(split(cmd," "),0),"/"),-1)
| search bin IN ("vi","vim","find","awk","less","more","man","nmap","env","tar","zip","git","python*","perl","ruby","tcpdump")
| stats count values(cmd) as commands by host, src_user
```tune/validate: extend the binary list from GTFOBins and exclude your approved admin users```

title: Root Shell Spawned by Sudo-Able Utility
logsource:
  product: linux
  category: process_creation
detection:
  selection:
    ParentImage|endswith:
      - '/vim'
      - '/vi'
      - '/less'
      - '/man'
      - '/awk'
      - '/find'
      - '/nmap'
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
    User: 'root'
  condition: selection
level: high
# tune/validate: administrators legitimately shell out from inside vim; baseline by account.

Review sudoers with a periodic export, and flag any NOPASSWD entry that names a GTFOBins binary, a wildcard argument, or a writable script path.
Alert on sudo -l and sudo -ll by accounts that are not administrators. Enumeration by a web or database service account is rarely benign.
Prefer sudoedit over granting editors, and use NOEXEC for programs that do not need to spawn children, to remove whole classes of escapes.

Vetted sources

Use GTFOBins for the binary list, the SigmaHQ Linux auditd and process-creation rules, Elastic’s prebuilt rules for sudoers changes and sudo enumeration, and Atomic Red Team T1548.003 for validation. Baseline your own environment — every admin team has legitimate sudo patterns that look like abuse.

Build Detections That Fire

Mjolnir Security helps blue teams turn threat intelligence into high-fidelity detections across endpoint, network, identity and cloud telemetry.

Detection EngineeringManaged Detection & ResponseThreat HuntingIncident ResponsePurple Teaming

Detection Engineering We build and tune detections mapped to ATT&CK from your own telemetry.
Threat Hunting as a Service Hypothesis-driven hunts for the behaviours on this page.
24/7 Incident Response Containment when a detection fires. Call +1 833 403 5875.

Written by: Mjolnir Threat Research (MTAC)  |  Published: October 12, 2026  |  Last reviewed: October 12, 2026

Signals at a Glance

Auditing the Configuration Surface

Reading auth.log and secure

Build Detections That Fire

Privilege Escalation Detection

Detection Hub

SUID Abuse on Linux Detection