September 14, 2026

Guided Pentest: Chaining Web Vulnerabilities to RCE

A hands-on TryHackMe web penetration testing walkthrough

By Anju

3 min read

A hands-on TryHackMe web penetration testing walkthrough

While learning web application penetration testing, I recently completed the TryHackMe Guided Pentest: Web room.

What I liked about this lab was that it wasn't about finding just one vulnerability. The interesting part was seeing how multiple weaknesses could be chained together to eventually achieve Remote Code Execution (RCE).

This walkthrough documents my approach and the important lessons I learned along the way.

Lab:_ TryHackMe — Guided Pentest: Web Target: RecruitX Environment: Authorized TryHackMe lab_

1. Reconnaissance

I started with basic service enumeration using Nmap:

nmap -sV -sC -p- MACHINE_IP

One of the important results was:

80/tcp    open    http    Apache httpd 2.4.58
3306/tcp  open    mysql
8080/tcp  open    http

The web server was running Apache 2.4.58, and MySQL was also exposed.

The web application became my primary focus.

2. Web Enumeration

I then started enumerating directories and files to understand the application's attack surface.

One interesting endpoint I discovered was:

/reset.php

There was also an administrative area and an upload functionality.

At this stage, I made a simple testing list:

/api        → investigate API
/reset.php  → test password reset
/admin      → investigate after authentication
/uploads    → investigate file handling

This is something I am learning to do during pentesting:

Don't randomly test everything. Build an attack surface map first.

3. Finding an IDOR

While testing the application, I noticed that user information was referenced using predictable IDs.

For example:

/profile.php?id=6

I changed the ID and found that I could access another user's information.

This was an Insecure Direct Object Reference (IDOR) because the application was not properly checking whether the logged-in user was authorized to access the requested object.

Through this, I was able to identify an administrator:

Sarah Mitchell
s.mitchell@recruitx.thm

The application also exposed user roles, which made this finding more interesting.

The important lesson here was:

A predictable ID isn't automatically a vulnerability. The real issue is the missing authorization check behind it.

4. Investigating Password Reset

Now that I had identified an administrator's email address, I investigated the password reset functionality:

/reset.php

The reset mechanism used a 6-digit numeric token.

While testing the reset functionality, I found weaknesses in how the token was handled, which allowed me to reset the administrator's password.

This resulted in access to the administrator account.

After logging in, the dashboard displayed:

Administrator

So the attack chain had now become:

IDOR
 ↓
Administrator information
 ↓
Weak password reset
 ↓
Administrator account

This was my first major lesson from the room:

Always think about how one vulnerability can help exploit another.

5. Investigating File Upload

With administrator access, I explored the available functionality and found a file upload feature.

The upload was handled by:

upload.php

The file input also used the HTML:

accept

attribute to restrict selectable extensions.

However, client-side restrictions are not sufficient security controls because the HTTP request can be modified directly.

I tested different file extensions.

A normal PHP file was blocked, but an alternative PHP extension worked:

.phtml

This successfully bypassed the upload filter.

6. From File Upload to RCE

An upload bypass alone doesn't prove Remote Code Execution.

I needed to verify whether the uploaded file would actually be interpreted as PHP.

I uploaded a simple PHP file using the .phtml extension and accessed it through the upload location.

The server executed the PHP code.

This confirmed:

Upload bypass
      ↓
.phtml accepted
      ↓
PHP executed
      ↓
Server-side code execution

I then used a simple web shell to execute commands through the application.

For example:

whoami

returned:

www-data

The web shell was therefore running as the www-data user.

I also checked the hostname:

hostname

which returned:

recruitx-prod

At this point, Remote Code Execution was confirmed.

7. The Complete Attack Chain

The most important part of this lab was not any single vulnerability.

It was the chain:

Reconnaissance
      ↓
IDOR
      ↓
Administrator information
      ↓
Weak password reset
      ↓
Administrator account
      ↓
File upload
      ↓
.phtml extension bypass
      ↓
PHP execution
      ↓
Web shell
      ↓
Remote Code Execution

The final flag was:

THM{ch41n3d_vulns_4r3_d3v4st4t1ng}

8. What I Learned

This lab changed how I look at web penetration testing.

Earlier, I focused mainly on:

"What vulnerability can I find?"

Now I'm trying to think:

"What information can this finding give me, and where can that information take me next?"

For example:

IDOR → user information

User information → administrator email

Password reset weakness → administrator access

Administrator access → file upload functionality

Upload bypass → executable PHP

Executable PHP → RCE

That is the biggest lesson I took from this room:

A pentest isn't always about finding one critical vulnerability. Sometimes the real impact comes from chaining several smaller weaknesses together.

Tools Used

  • Nmap — service enumeration
  • Gobuster — directory enumeration
  • Burp Suite — request/response analysis
  • cURL — HTTP/API testing
  • Browser Developer Tools — application inspection

Conclusion

This was a valuable lab for practicing the complete web pentesting mindset rather than simply learning individual vulnerabilities.

The biggest takeaway for me was simple:

Observe → Enumerate → Test → Understand → Chain → Validate.

I'm going to continue documenting my hands-on security labs and the lessons I learn from them as I build my skills in web application security and VAPT.

One lab at a time. One vulnerability at a time. 1% better every day.