TryHackMe Support Writeup
Written By Aryan Giri
TryHackMe Support โ Web Exploitation Writeup
Initial Recon and Access
Target application exposed a support operations login portal. Traffic was routed through Burp Suite to observe backend behavior and intercept requests.
Upon visiting the URL, a login interface was discovered.
During basic enumeration, the page leaked a valid support email:
help@support.thm
This immediately reduced the authentication surface to a single known identifier.
SQL injection authentication bypass attempts were tested but did not succeed, indicating proper input handling at the login layer.
Authentication Brute Force
Since injection was not viable, password brute forcing was the next approach.
A valid request was captured in Burp Suite to understand parameter structure:
This revealed a standard POST authentication flow:
- email parameter
- password parameter
Hydra was then used for password brute force:
hydra -l help@support.thm -P rockyou.txt 10.49.148.63 -s 80 http-post-form "/:email=^USER^&password=^PASS^:Invalid credentials"
After a short run, valid credentials were recovered and login access was obtained.
Post Login Enumeration
After authentication, a dashboard was exposed with the following endpoint:
/dashboard.php?skin=default
This parameter became an immediate candidate for Local File Inclusion testing.
Before deeper testing, further inspection of client-side storage was performed.
Cookie Analysis and Privilege Manipulation
A browser cookie named:
IsITUser
was identified containing an MD5 hash.
This value was decoded using offline and online cracking methods (e.g., CrackStation).
Result:
- Hash value resolved to
false
This indicated a boolean-based privilege flag.
The cookie was manually modified:
false โ true
This can be achieved using:
- CyberChef
- Python MD5 encoding
- manual replacement depending on implementation
After refreshing the page, new functionality was unlocked.
Internal API Discovery and IDOR
A hidden API documentation panel became accessible:
The API exposed user data endpoints:
GET /user/{id}
This allowed direct object reference testing.
IDOR Testing
/user/1โ revealed admin-level user data/user/3โ revealed normal user data
From enumeration:
Admin email discovered:
specialadmin@support.thm
Additionally, API responses hinted at privilege flags such as:
admin=true
Attempts were made to escalate privileges via:
- PATCH requests modifying user role
However, server-side enforcement prevented privilege escalation through API manipulation.
LFI via Skin Parameter
Attention returned to:
/dashboard.php?skin=default
Directory traversal payloads were tested:
../../etc/passwd
../config
The parameter was vulnerable to Local File Inclusion behavior.
A sensitive configuration file was successfully accessed via:
../config
This revealed credential material.
Recovered credential:
support110
This was accepted for authentication (despite variations observed during testing).
First Flag Retrieval
Using the recovered credentials, access to restricted content was achieved and the first flag was obtained.
Command Injection via Date Parameter
Inside the admin panel, a feature was discovered allowing date/time interaction.
Requests showed backend execution pattern:
sys=date
This parameter was forwarded directly to system-level execution.
Intercepting the request in Burp Suite confirmed command execution behavior.
Example payload:
date; ls
Remote Command Execution and Flag Extraction
With command injection confirmed, file retrieval was straightforward.
Target file:
/home/ubuntu/user.txt
Payload:
date; cat /home/ubuntu/user.txt
Response returned the final flag.
Conclusion
The compromise chain followed a classic layered exploitation path:
- Information leakage (email disclosure)
- Authentication brute force
- Weak client-side privilege flag (cookie manipulation)
- IDOR via internal API
- Local File Inclusion via unsanitized parameter
- Command injection leading to full system access
Each stage progressively escalated access until full command execution was achieved.