Threat Hunting Exercise: Analyzing Linux Setuid Binary Abuse Privilege Escalation Dataset

This hunt uses a simulated Linux auditd dataset (linux_auditd_setuid_2022-09-26T193000.json) capturing T1548.001: Abuse Elevation Control Mechanism (Setuid and Setgid), where an attacker with limited shell access finds or plants a binary with the SUID bit set that allows arbitrary command execution (e.g., find, vim, python, or a custom dropped binary), escalating from a standard user to root.

Step 1: Hypothesis Formation

Hypothesis: A chmod operation sets the SUID bit (+s/4755) on a binary not normally requiring it, or a pre-existing GTFOBins-listed SUID binary (e.g., find, nmap, python3) is invoked with arguments consistent with its known privilege-escalation abuse pattern, immediately followed by a shell spawning with euid=0 from a process that was previously running as a standard user. Indicators:

auditd SYSCALL record for chmod/fchmodat with mode bits including 04000 (setuid) on an executable outside standard system binaries.
Execution of a GTFOBins SUID-abuse pattern, e.g., find . -exec /bin/sh -p \; -quit or python3 -c 'import os; os.setuid(0); os.system("/bin/sh")'.
A subsequent process shows uid (real) still the standard user but euid/suid of 0, confirming successful privilege escalation via the SUID binary.
No corresponding sudo/su authentication event precedes the UID change.

Null Hypothesis: A legitimate system package (e.g., ping, mount, passwd) has the SUID bit as part of its normal, vendor-shipped installation, and no abuse pattern is present. Invalidate by confirming the binary and its permission bit against the package manager's manifest (dpkg -V / rpm -V).

Rationale: SUID/SGID misconfigurations are among the most common and reliable Linux privilege-escalation vectors, especially on systems where administrators grant SUID to utility binaries for convenience; detecting the abuse pattern at execution time catches both planted and misconfigured-legitimate binaries.

Step 2: Data Sources and Scope

Sources: auditd SYSCALL, EXECVE records; shell history; /var/log/auth.log.
Scope: ~2022-09-26T19:30:00-19:45:00 UTC; Host: srv-batch-04 (10.80.2.17); User: svc_reports (standard, non-sudo).
SIEM Queries (Splunk/ELK):
index=linux sourcetype=auditd type=SYSCALL syscall=chmod a2=4755
GTFOBins pattern: index=linux sourcetype=auditd type=EXECVE exe="/usr/bin/find" a1="-exec" a2="/bin/sh"
UID escalation confirmation: index=linux sourcetype=auditd type=SYSCALL uid!=euid euid=0

Step 3: Key Findings

Parsed events (5 shown) confirm svc_reports set the SUID bit on /usr/bin/find, then invoked its documented GTFOBins escalation pattern to spawn a root shell without ever authenticating via sudo.

Timestamp (UTC)	Host	Event	Detail	IOC/Why Suspicious?
2022-09-26 19:36:02	srv-batch-04	auditd SYSCALL (chmod)	`chmod 4755 /usr/bin/find` executed by uid=1004 (`svc_reports`)	SUID-Grant IOC: `find` does not ship with the SUID bit by default; this is a deliberate, non-standard permission change made by a low-privilege account.
2022-09-26 19:36:15	srv-batch-04	auditd EXECVE	`find . -exec /bin/sh -p \; -quit` executed	GTFOBins IOC: this exact command is the documented, widely-known `find` SUID privilege-escalation one-liner.
2022-09-26 19:36:15	srv-batch-04	auditd SYSCALL	Resulting `/bin/sh` process: `uid=1004 euid=0 suid=0`	Escalation-Confirmed IOC: real UID remains the standard user while effective/saved UID is root - definitive proof the SUID abuse succeeded.
2022-09-26 19:37:40	srv-batch-04	auditd EXECVE	Root shell used to run `cat /etc/shadow` and `useradd -o -u 0 -g 0 svc2` (UID-0 backdoor account)	Persistence IOC: the attacker immediately used root access to read credential material and create a second, hidden UID-0 account.
-	srv-batch-04	(auth log check)	No corresponding `sudo` or `su` authentication event in `/var/log/auth.log` for this session	Confirms the privilege escalation bypassed all standard authorization mechanisms entirely.

Validation:

Timeline: SUID bit set, GTFOBins abuse command executed, root shell confirmed, followed by credential access and backdoor account creation - a complete and fast privilege-escalation chain.
False Positives: no package-manager record explains the SUID permission on find, and no legitimate sudo/su authentication accounts for the UID-0 shell.
Correlation: permission change, known abuse pattern, UID confirmation, and post-escalation actions jointly confirm malicious privilege escalation.

Step 4: Recommendations & Next Steps

Immediate Response: Remove the SUID bit from /usr/bin/find immediately, delete the svc2 backdoor account, rotate credentials for svc_reports and any accounts whose hashes may have been read from /etc/shadow, and isolate srv-batch-04 for forensic review.
Detection: Sigma-style rule: title: SUID Bit Set on Non-Standard Binary Followed by Root Shell → selection1: type=SYSCALL AND syscall=chmod AND a2 contains '4755' selection2: type=SYSCALL AND euid=0 AND uid!=0 within 5m of selection1 → condition: selection1 and selection2.
Pro Tip: Run a scheduled find / -perm -4000 -type f inventory sweep across all Linux hosts and diff it daily against a known-good baseline - any new entry not shipped by the OS package manager is a near-certain privilege-escalation setup and should trigger immediate investigation.

Hypothesis confirmed - an attacker with limited shell access set the SUID bit on /usr/bin/find and used a well-known GTFOBins one-liner to spawn a root shell, then created a hidden UID-0 backdoor account!