Threat Hunting Exercise: Analyzing Linux Sudoers File Modification Privilege Escalation Dataset

This hunt uses a simulated Linux host dataset (linux_sudoers_mod_2022-08-21T160000.json) capturing T1548.003: Abuse Elevation Control Mechanism - Sudo and Sudo Caching, where an attacker with temporary root/write access modifies /etc/sudoers (or drops a file in /etc/sudoers.d/) to grant a low-privilege account passwordless, unrestricted sudo rights, establishing a durable privilege-escalation backdoor.

Step 1: Hypothesis Formation

Hypothesis: A new or modified entry appears in /etc/sudoers or /etc/sudoers.d/ granting ALL=(ALL) NOPASSWD:ALL to an account that previously had no or limited sudo rights, and this change is not attributable to a documented configuration-management run. Indicators:

File integrity monitoring flags a change to /etc/sudoers or a new file under /etc/sudoers.d/ outside of a known config-management (Ansible/Puppet/Chef) push window.
The granted account is a low-privilege service or user account with no prior legitimate need for unrestricted sudo.
NOPASSWD is used, removing the standard password-reauthentication control.
The account subsequently executes sudo commands successfully with no password prompt logged, shortly after the file change.

Null Hypothesis: A legitimate configuration-management tool pushed an approved sudoers change as part of a documented access-provisioning request. Invalidate by checking the CM tool's run log and the corresponding change/access-request ticket.

Rationale: A sudoers modification is one of the most direct and durable privilege-escalation backdoors on Linux, persisting independently of any process or network artifact; this hunt validates file-integrity monitoring on sudoers paths, correlated against configuration-management logs, as the primary control for catching unauthorized grants.

Step 2: Data Sources and Scope

Sources: File Integrity Monitoring (AIDE/Tripwire/osquery) on /etc/sudoers and /etc/sudoers.d/; auditd EXECVE and PATH records for the editing process; configuration-management (Ansible/Puppet) run logs; sudo log (/var/log/sudo.log or syslog sudo: entries).
Scope: ~2022-08-21T16:00:00-16:02:00 UTC; Host: lnx-app-node09 (10.260.4.31); Account granted: svc-metrics (previously no sudo rights).
SIEM Queries (Splunk/ELK):
index=fim path="/etc/sudoers*" action=modified
index=auditd type=PATH name="/etc/sudoers.d/*" nametype=CREATE
Cross-check CM: index=ansible_runs host="lnx-app-node09" | stats count by bucket(_time,10m) (absence of a matching run = unauthorized).
index=syslog sourcetype=sudo user=svc-metrics

Step 3: Key Findings

Parsed events (5 shown) confirm a new file was dropped in /etc/sudoers.d/ granting svc-metrics unrestricted, passwordless sudo, with no corresponding configuration-management run and immediate abuse of the new privilege.

Timestamp (UTC)	Host	Event	Detail	IOC/Why Suspicious?
2022-08-21 16:00:05	lnx-app-node09	auditd PATH (CREATE)	`/etc/sudoers.d/99-metrics-helper` created by root session	Grant-Vector IOC: use of the `sudoers.d` drop-in directory (rather than editing `/etc/sudoers` directly) is a common technique to avoid triggering `visudo`-specific monitoring while still applying instantly.
2022-08-21 16:00:06	lnx-app-node09	(file content, via FIM)	`svc-metrics ALL=(ALL) NOPASSWD: ALL`	Privilege IOC: unrestricted, passwordless root access granted to a service account that previously had no sudo entry at all.
2022-08-21 16:00:10	lnx-app-node09	(CM log check)	No Ansible/Puppet run recorded for lnx-app-node09 in the preceding 24 hours; no matching access-request ticket	Confirms the change was made manually and out-of-band, not via the approved provisioning pipeline.
2022-08-21 16:01:15	lnx-app-node09	sudo log	`svc-metrics : TTY=pts/2 ; PWD=/home/svc-metrics ; USER=root ; COMMAND=/bin/bash` - no password prompt logged	Abuse IOC: the newly-granted account immediately used its passwordless sudo rights to obtain an interactive root shell, within 70 seconds of the grant.
2022-08-21 16:01:16	lnx-app-node09	auditd EXECVE (as root)	`useradd svc-monitor2 -m -s /bin/bash` and `usermod -aG sudo svc-monitor2`	Redundancy IOC: attacker immediately created a second backdoor account, a common pattern to survive remediation of the first.

Validation:

Timeline: sudoers.d file drop, immediate passwordless root shell, and creation of a second backdoor account all within 90 seconds - a rapid, deliberate privilege-escalation-and-entrenchment sequence.
False Positives: no configuration-management run or access-request ticket corresponds to this change; the granted account had no prior legitimate need for sudo.
Correlation: file-integrity alert, absent CM run, and immediate privileged command execution together confirm unauthorized privilege escalation, not routine provisioning.

Step 4: Recommendations & Next Steps

Immediate Response: Remove /etc/sudoers.d/99-metrics-helper immediately; disable/remove the svc-monitor2 backdoor account; rotate credentials for svc-metrics and any account it accessed while privileged; audit all sudoers.d entries fleet-wide for similar unauthorized grants; identify how root/write access was initially obtained on this host.
Detection: Sigma-style rule: title: Unauthorized Sudoers Modification Granting NOPASSWD → selection: path IN ("/etc/sudoers","/etc/sudoers.d/*") AND content contains "NOPASSWD" AND NOT correlates_with(cm_run_log).
Pro Tip: Make /etc/sudoers and /etc/sudoers.d/ immutable via chattr +i outside of maintenance windows, and require all sudoers changes to flow exclusively through the configuration-management pipeline - this converts any direct edit attempt into an unambiguous, high-confidence alert rather than a silent success.

Hypothesis confirmed - an attacker planted an unauthorized sudoers.d file granting a service account passwordless root access, then immediately used it to obtain a root shell and create a second backdoor account!