CEH Compete

J

Because I followed the full CEH route I was eligible for a monthly challenge. These are fun, but the timebox forces you to move fast — you need good skills and quick decision making to grab all flags. Today’s box hinted at SSRF in the title. Fresh off a TryHackMe SSRF room, I felt confident I could at least find something useful.

Target & first impressions

  • Single IP target.
  • Quick nmap showed only port 80/tcp open.
  • Visiting the site reveals a simple login and register form

I created an account to get a feel for the app. That produced nothing immediately useful, but while viewing the page source I noticed the legal disclaimer referenced a file hosted on a different server — a prime SSRF candidate.

Enumeration — probing the SSRF vector

I tried a file:// style request to see if the server would fetch local files for me. I proxied the request through Burp and sent it to Repeater to experiment.

The returned content included PHP source snippets. From those snippets I saw a connection to a database file in DB/DbOperation.php. Following that reference led me to DbConnect.php, and inside that file there was another host listed along with database credentials.

From my attacker machine I could ping that new host. Using the discovered credentials I connected to MySQL from Kali:

mysql -h 10.10.2.222 -P 3306 -u ssrfdbuser -p --ssl=off

Notes:

  • -P to specify port (confirmed via nmap).
  • -p to input password interactively.
  • --ssl=off because the client threw an SSL error otherwise.

After succesfull connection we can query data from the users table:

Armed with the admin login, I went back to the web app to see what else I could do.

Exploitation — upload service and SSRF pivots

There was an image upload feature ostensibly for the admin. Upload attempts returned a message that the “upload service is offline” and pointed to a specific internal IP for status checks. Directly hitting that IP from my Kali was blocked, but I could load the admin page source via the SSRF and inspect the logic.

From the source I learned there’s an API with endpoints like /start. Querying the /start endpoint returned the status inactive — I needed a way to start that service. After some trial and error and fuzzing the API, I found an API command that let me change the state and trigger behaviour the app expected.

Timebox & results

And then: time. The one-hour box timer expired before I could fully exploit the service and complete the remaining flags. Frustrating, but I still captured 4 out of 7 flags — not bad given the clock.

Lessons learned & takeaways

  • SSRF is powerful: It let me read server-side files and discover internal hosts and secrets. Always check external references in page source and anywhere the app fetches third-party resources.
  • Follow the breadcrumbs: Small hints in source (file paths, includes) led to real credentials and a pivot. Don’t skip inspecting referenced files.
  • Fuzz smartly: When an endpoint returns inactive or similar, try parameter fuzzing and common control commands — often the admin endpoints are crude and can be triggered by a simple path or parameter you wouldn’t try first.
  • No public writeups — bigger win: Unlike a lot of TryHackMe rooms, there were no writeups or walkthroughs online for this particular challenge. That meant I couldn’t rely on someone else’s path or shortcuts — everything I found was purely my own work. That made pushing through the SSRF → DB creds → admin pivot feel a lot more satisfying and validated my methodology.
  • Timeboxing sucks but teaches: The pressure forces prioritization — enumeration + quick pivots wins over deep manual exploration early on. In this run, extra time (one more hour) would very likely have let me finish the machine.

What I would do next (if I had another hour)

  1. Use the discovered admin credentials to fully control the upload service or swap the uploaded image for a webshell (if file validation could be bypassed).
  2. Explore the API further for authenticated endpoints exposed only to internal networks.
  3. Try to get a persistent foothold on the internal host discovered via DB creds.
  4. Document everything cleanly — since there are no public writeups, I’d prepare a detailed walkthrough (notes, commands, and sanitized screenshots) so others can learn from the path I found without spoiling the challenge for new players. That’d also make a nice addition to my blog and help consolidate what I learned.

Final notes

I left with mixed feelings — annoyed by the time limit, but happy about the methodology that paid off: SSRF → internal file read → DB creds → admin account → API fuzzing. If you’re practicing SSRF: exercise reading local config files and chasing any hard-coded hostnames or includes. Those are often the fastest path to escalation.

Related Posts