A.K.A Sometimes HTB Machines Don’t Have What They Need

As someone still relatively new to the CTF world, my methodology is far from perfect. There are plenty of times I overlook basic steps (e.g., Vhost fuzzing, using a specific wordlist for directory brute-forcing, XXE testing, etc.), but I can see steady improvement. Being a novice in offensive security and ethical hacking means I often spend too much time looking up solutions. This can be particularly frustrating when the problem turns out to be something outside my control, like a configuration error with the target machine.

LinkVortex, an “Easy” box on the HTB Labs platform, was one of those challenging yet enlightening experiences. I kicked things off with my usual workflow:

nmap {Target IP} -sCV -p- --stats-every 5

This initial scan gave me some valuable information about the target, such as the CMS it was running, the operating system, and available protocols. After adding the target to my /etc/hosts file (using nano to add {Target IP} linkvortex.htb at the bottom), I moved on to explore the site.

Since this is still an active machine (and I’ve had issues with HTB over spoilers before—lesson learned, lol), I’ll keep things vague from here. The general process involved directory brute-forcing using Gobuster:

gobuster dir --url http://linkvortex.htb --wordlist /usr/share/seclists/Discovery/Web-Content/common.txt -t 40 -b 301,404

This revealed a login portal. While exploring the site, I checked its robots.txt file, which pointed me to a sitemap.xml. I also came across some blog posts that hinted at what the username for the login portal might be.

From there, I performed Vhost enumeration:

gobuster vhost -u http://linkvortex.htb -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-110000.txt --append-domain

This uncovered a development site the web devs had left online after rolling out the production version. Another round of directory brute-forcing revealed some interesting source code files.

Here’s where things got frustrating. While sifting through these files for potential credentials, I found several candidates and carefully documented them in my notes. None of them worked, and I couldn’t make sense of the next step. After chatting with some folks in the community, I realized the password I needed should have been in one of the files I’d already examined. Turns out, it wasn’t there anymore! Whether it was a misconfiguration or someone deliberately messing with the setup, this made the experience unnecessarily difficult.

To anyone tempted to say, “Stop whining and just ‘Try Harder,’ bro,” I’d respond with a heavy sigh and an eyeroll. The missing password created a dead end, and without it, there was no obvious way to proceed.

I attempted to use Hydra for brute-forcing the login portal but quickly got locked out due to the sheer volume of requests. Slowing down the attack to avoid detection would have taken forever, and trying to cycle through IPs felt far from the spirit of an “Easy” box.

Fortunately, after resolving the password issue with help from the community, the rest of the box was fairly smooth. A basic CVE search and a GitHub proof-of-concept (PoC) exploit did the trick. The key was locating the CMS’s configuration file. The repository on GitHub (thank you, open source!) revealed where to look. With an authenticated arbitrary file read exploit, I accessed the file via the CMS’s management dashboard, grabbed the SSH credentials, and secured user.txt.

The post-exploitation phase was standard Linux enumeration and privilege escalation. Understanding how bash scripts worked was key to getting root. The path to root.txt made sense, and before long, I had the flag in hand and the satisfaction of solving an “Easy” box (with some sarcasm attached).

TL;DR: While working on LinkVortex, I ran into an issue where the password I needed wasn’t where it was supposed to be—either due to a misconfiguration or sabotage. After some help from the community, I moved forward and got (fairly) smooth access to root.txt.