Support | THM — Walkthrough

Room Overview

The target is an Internal Support Operations Platform designed for IT and Helpdesk teams.

From the room description, we know the application handles:

User management
Internal APIs
System-level operations

The mention of system-level operations immediately suggests that remote command execution (RCE) may eventually be possible.

The room also hints that security was never a design priority, which means we should pay close attention to common web application vulnerabilities.

Passive Recon

Let's start with some passive recon before touching any tools.

I checked the page source first, but there were no comments, hidden endpoints, or hardcoded credentials. The Network and Debugger tabs were clean as well.

Just by browsing the site, we can already gather a few useful details:

Support email: help@support.thm
Web server: Apache
Backend: PHP

No cookies are set at this point, so there's nothing interesting in Storage yet.

Active Recon

Time to politely ask the server what else it's hiding.

I started with an Nmap scan to enumerate the open ports and identify the running services.

nmap -sC -sV <IP>

nmap -sC -sV <IP>

-sC runs the default NSE scripts.
-sV performs service and version detection.

Nothing particularly interesting showed up, so I moved on to directory and file enumeration with Gobuster.

Gobuster didn't uncover anything particularly useful, so now it's time for something my PC absolutely hates and makes it question its life choices… brute forcing.

ffuf -w /usr/share/wordlists/rockyou.txt -u http://IP -X POST -d "email=help%40support.thm&password=FUZZ" -fs 2678 -H "Content-Type: application/x-www-form-urlencoded"

ffuf -w /usr/share/wordlists/rockyou.txt -u http://IP -X POST -d "email=help%40support.thm&password=FUZZ" -fs 2678 -H "Content-Type: application/x-www-form-urlencoded"

You might be wondering why I used -fs 2678. Go on, remove it and run the command… I'll wait.

See that mess? Yeah, enjoy scrolling through identical responses like it's your new full-time job. Every failed login comes back with the same size, so good luck spotting the right one.

Great, we got the password.

Log in and inspect the application again. The Source, Network, and Debugger tabs are still uneventful, but the Storage tab finally gives us something interesting:

where we have "isITUser" under cookies with some value

Let's keep that in mind for a moment and revisit some of the directories Gobuster found earlier. As expected, we're redirected because we're not an administrator.

but hey we still have our "isITUser" ..

Broken Access Control

The value is an MD5 hash. After cracking it with CrackStation, it turns out to be: false

Which is basically the application politely saying, "No, you are not important."

So naturally, we do what any responsible hacker would do and flip it to: true

Because if life won't give you admin privileges, you simply assign them to yourself.

After generating the new MD5 hash with CyberChef, replacing the cookie value, and refreshing the page… boom. Instant promotion. No interview, no HR, no background check.

Turns out trusting client-side cookies for authorization is about as secure as putting a "Do Not Enter" sign on an open door and hoping nobody reads it.

IDOR (Insecure Direct Object Reference)

After bypassing the authorization check, a new option called View API becomes available.

Opening it reveals our user information. One thing that immediately stands out is our user ID: id = 3

Naturally, the next thought is: what about IDs 1 and 2?

After changing the ID to 1, we discover another user:

{
"email": "specialadmin@support.thm"
"admin": "true"
}

{
"email": "specialadmin@support.thm"
"admin": "true"
}

Great, we now have the administrator's email address along with confirmation that the account has admin privileges.

Naturally, my first thought was, "Let's brute force the admin account."

LOL

It turns out my GPU and I had just wasted quality bonding time.

After wandering around the application instead, I noticed the Select Theme option. Changing the theme also changes the skin parameter in the URL.

Time to poke it.

After trying a few payloads, this one caught my attention:

http://IP/dashboard.php?skin=../config

http://IP/dashboard.php?skin=../config

The page didn't break. Instead, the UI changed slightly.

I checked the page source again, and this time there was something interesting. Part of the PHP code was being exposed, revealing the master password

support@110

support@110

Easy, right?

I tried logging in with it, and… nothing.

At this point I was convinced either I was losing my mind or the room creator was having a laugh.

After trying a few variations, the solution turned out to be removing the @ symbol.

support110

support110

With that, we finally logged in as the administrator and captured the first flag.

Now for the second one. This part is less about exploiting and more about paying attention.

After logging in as the administrator, a new Date [ Try getting one in real life… this one is considerably easier ] option appears in the UI.

Clicking it sends a POST request. Looking at the Network tab, we can see the following parameter:

sys=date

sys=date

Command Injection

Remember the room description mentioning system-level operations? This looks like exactly what it was hinting at.

Time to see if the application trusts our input a little too much.

Replace the request with:

sys=date|pwd

sys=date|pwd

The server happily executes both commands, confirming that the sys parameter is vulnerable to command injection.

To grab the second flag, modify the request to:

sys=date|cat /home/ubuntu/user.txt

sys=date|cat /home/ubuntu/user.txt

The response returns the second flag, and that's the room complete! 🎉

Thank you so much for reading my very first TryHackMe walkthrough. Hopefully it made the room a little easier… or at least gave you a laugh along the way.

Now let's go touch some grass before jumping into the next room.

Happy Hacking! 🚩