TryHackMe Startup machine banner

Disclaimer

This walkthrough is for educational purposes only. All activities were performed on legally authorised TryHackMe systems.

Initial Reconnaissance

I started with a basic Nmap scan to identify open ports and services:

nmap -sC -sV -p- -v <IP>

While the scan was running, I decided to check if there was a website running. There was. I checked the source code (Ctrl+U) but found nothing useful, so I moved on to directory enumeration.

Directory Enumeration with ffuf

I copied the URL and ran ffuf against it. You can use dirbuster or gobuster too. I just prefer ffuf because it’s fast.

Advice — Tools don’t matter. What matters is whether you understand what you’re doing. Tools come and go; logic and skill stay.

The wordlist I used is from SecLists, specifically common.txt.

ffuf -u http://<IP>/FUZZ -w common.txt -t 100

Here are the results:

ffuf results showing /files directory

Exploring /files

There is a /files directory. I copied the URL and opened it in my browser:

/files directory listing in browser

I opened notice.txt and spotted a name: Maya. Interesting. I checked the other files and directories but nothing stood out. Meanwhile, my Nmap scan finished:

Nmap scan results

Digging Into Open Ports

Port 21 is running FTP with anonymous login enabled. I logged in and poked around, but found the same files we already saw in the browser. Nothing new. Time to switch.

Port 22 is running OpenSSH 7.2p2. I went online to look for known vulnerabilities and found CVE-2016-6210, an information disclosure vulnerability that lets you check whether a username exists on the target system.

CVE-2016-6210 exploit details

Exploit: exploit-db.com/exploits/40136

CVE-2016-6210 Rabbit Hole

Remember the name we found in notice.txt? Maya. I thought it could lead somewhere. The plan was simple: confirm the username with this vulnerability, then brute-force my way in.

I fired up Metasploit and found the SSH username enumerator at scanners/ssh/ssh_enumusers. I set RHOST as the machine IP and hit run, but got an error straight away. I forgot to set USERNAME. I set it to Maya, hit run again, and got a false positive error. I then set CHECK_FALSE to false, hit run again, and it said USER MAYA FOUND.

Metasploit SSH username enumeration result

Something felt off, so I tried the username rfvewbfibk. It also came back as FOUND. Now I knew something was wrong.

I went online and tried every CVE-2016-6210 exploit I could find. Nothing worked because of a bug in Python’s paramiko library. I tried Python virtual environments, forcefully installing requirements on main Python, everything. Still nothing.

CVE-2016-6210 exploit errors in terminal

At this point I let Gemini generate a custom exploit for it. I was confident. Hit enter. MAYA FOUND. Let’s go.

AI generated exploit result showing Maya found

I cross-checked it with a random string as the username. Found again. False positives across the board. This time I chose not to fall into the same rabbit hole I did last time, debugging broken code I found online. I stepped back completely. No more SSH. Back to FTP.

The Real Way In: FTP Write Access

I started retracing my steps. How did I reach FTP? Did I miss anything? Any bug on the website? Any port I ignored? I read through the Nmap results again and saw it. Here are the results again. Do you see it?

Nmap scan showing FTP directory is writable

The FTP directory is writable.

I logged back into FTP and uploaded two files to the /files/ftp directory:

I was confident PHP was installed since this was a web server. I started a Netcat listener, opened the browser, and clicked payload.php.

Successful reverse shell connection in terminal

And I was in. Successful reverse shell. I navigated to the FTP directory and ran LinPEAS.

LinPEAS output highlighting /incidents directory

Finding Credentials in a PCAP

If you know what a Linux file system normally looks like, you will spot it immediately. There is an /incidents directory. That is not standard. I checked it and found a file called suspicious.pcapng. I downloaded it to my machine and opened it in Wireshark.

suspicious.pcapng opened in Wireshark

Lots going on. I tried filtering HTTP packets first but found nothing useful. I tried searching for passwords as strings but still nothing. Finally, I followed the TCP stream and that is where it all was.

TCP stream in Wireshark showing plaintext credentials

There is a user named Lennie, and her password was captured in plaintext. I copied it and SSHed in immediately. User flag found.

SSH login as Lennie and user flag

Privilege Escalation: Writable Cronjob Script

Time to get the root flag. I explored Lennie’s files and a scripts folder caught my eye. Inside it was a script called planner.sh. I opened it and saw it executes another script at an unusual path: /etc/print.sh. That screamed cronjob to me.

planner.sh script contents showing /etc/print.sh

I added a Bash reverse shell line to /etc/print.sh, saved it, and started a Netcat listener. About a minute later, the shell came back. Root flag found.

Root shell and root flag

Key Takeaways

Takeaway Explanation
Check FTP write permissions Anonymous FTP login is suspicious on its own. Writable FTP plus a web server is a direct path to a reverse shell
Know when to move on I wasted time on CVE-2016-6210 when every result was a false positive. If the tool is giving nonsense output, the tool is broken
Non-standard directories are a signal /incidents does not belong in a normal Linux file system. When something looks out of place, check it
Cronjobs run as root A script executed by root that a low-privilege user can write to is game over. Always check scripts being called by other scripts

Thanks for reading. Happy hacking.