Include — TryHackMe — Detailed Writeup

In this post, I break down a full TryHackMe room walkthrough with step-by-step methodology, practical commands, and real-world exploitation logic. Whether you’re preparing for VAPT interviews, building your lab skills, or just curious about how attackers think.

Before starting to solve the lab, I added IP of the target to the /etc/hosts as include.thm. Target URL: http://include.thm

Also, the room has the following questions:

1. Enumeration

As usual, I started with scanning open ports of the target. Normally i use rustscan for scanning the target.

During the initial Port scan, I observed a wide range of open ports — many of which were associated with mail services like IMAP and POP3. However, after a brief inspection, I didn’t identify any exploitable vulnerabilities tied to those services. So, I chose to focus my efforts on the web-facing ports instead.

One of the more interesting findings was on port 50000, which hosted a SysMon system page. This interface appeared to be part of a monitoring dashboard, and it became my starting point for deeper analysis.

port 5000

The page also featured a login form labeled “Restricted Portal.” I attempted to bypass authentication using SQL injection, but the input fields were not vulnerable.

Unfortunately, no interesting findings were made. The page source also contained no hidden hints.

Upon further port scanning, I identified Node.js running on port 4000, establishing it as the second web application hosted on the target machine.

Fortunately, the creator left me a hint for logging in to the website.

guest : guest

Again, I tried to fuzz for disclosing hidden directories and files on port 4000.

Nothing was found interesting.

2. Privilege Escalation via BOPLA

When I checked the account’s information page, it was possible to add new objects.

It was possible to add new objects to the user’s details:

But it was also possible to modify other objects:

What happens if I edit isAdmin’s value to true?

Yes, it will lead to BOPLA { Broken Object Property Level Authorization } vulnerability:

https://owasp.org/API-Security/editions/2023/en/0xa3-broken-object-property-level-authorization/

yeah, new tabs were available .

First, I visited the API tab:

The API tab contained the credentials needed to access the SysMon App, but I needed a way to send requests to localhost to retrieve them.

After exploring the different tabs, I discovered an input field in the settings that provided the solution.

BurpSuite

This input was vulnerable to Server-Side Request Forgery, which means I could get the administrator’s password. Basically, I changed the “url” parameter’s value and tried to sent request to the internal-api endpoint via localhost:

http://include.thm:4000/admin/settings

Here is the way I got the result — each time I made a request, it sent the results to the /admin/settings page as base64 encoded. I decoded the result:

base64.org

It was time to get the credentials to log in to the SysMon App:

Here was the credentials:

administrator : S$9$qk6d#**LQU

http://10.201.6.185:50000/login.php

I logged in to the system and got the first flag.

3. The second flag

Getting the second flag has 2 methods. Both starts with finding an input that is vulnerable to Local File Inclusion.

3.1. LFI2RCE — Local File Inclusion to Remote Code Execution

After searching for a while, I found an interesting vulnerability in the website’s page source.

view-source:http://10.201.6.185:50000/dashboard.php

view-source:http://10.201.6.185:50000/profile.php?img=profile.png

If I can view the image, then I should view the other files too. I tried some payloads for path traversal, and reading /etc/passwd file.

https://github.com/emadshanab/LFI-Payload-List

PAYLOAD: ….//….//….//….//….//….//….//….//….//….//etc/passwd

view-source:http://10.201.6.185:50000/profile.php?img=....//....//....//....//....//....//....//....//....//....//etc/passwd

There were 2 users:

joshua 
charles

I tried to gain access to the machine via SSH brute-forcing.

3.2. LFI2RCE via using mail log poisoning

Another method was mail log poisoning.

Basically, LFI allows reading mail logs, and if an attacker injects malicious script into the logs, the server will execute it.

view-source:http://10.201.6.185:50000/profile.php?img=....//....//....//....//....//....//....//....//....//....//var/log/mail.log

After identifying the LFI vulnerability, I attempted to send a basic PHP webshell to the server using netcat:

The 501 message was not an issue because it was already logged by the server.

Time to execute the commands.

view-source:http://10.201.6.185:50000/profile.php?img=....//....//....//....//....//....//....//....//....//....//var/log/mail.log&cmd=id

view-source:http://10.201.6.185:50000/profile.php?img=....//....//....//....//....//....//....//....//....//....//var/log/mail.log&cmd=ls -la /var/www/html

4. Prevention

4.1. Broken Object Property Level Authorization (BOPLA)

• Avoid using generic methods like to_string() and to_json(). Instead, select specific object properties to return.
• Implement schema-based response validation for an added security layer. Allow modifications only to object properties that the client should update.

4.2. Server-Side Request Forgery (SSRF)

• Ensure user inputs (URLs, IPs, etc.) are strictly validated to prevent malicious requests. Only allow requests to known, trusted servers/domains.
• Restrict access to internal or sensitive systems (e.g., localhost, internal networks) by resolving and checking the IP address of URLs to ensure they do not point to internal addresses. Isolate outgoing requests through a proxy to control server access.

4.3. Local File Inclusion (LFI)

• To prevent Local File Inclusion (LFI), implement these measures: Check user input against a whitelist or ensure it only contains allowed characters (e.g., alphanumeric).
• Append the input to the base directory, then use a platform API to canonicalize the path. Ensure the canonicalized path starts with the expected base directory.

4.4. Mail Log Poisoning

• To prevent mail log poisoning, sanitize all user-supplied data (e.g., email addresses, subjects, or content) to eliminate malicious characters or patterns.
• Restrict email log access to authorized users for read/write operations. Escape special characters in mail logs to prevent their interpretation as commands or code.
• Utilize structured logging formats and avoid directly logging user input unless essential.

Thanks for reading! If you found this writeup helpful, feel free to connect with me on LinkedIn and Twitter — I share daily tips, walkthroughs, and curated resources for aspiring penetration testers and cybersecurity learners.

Follow me on LinkedIn : www.linkedin.com/in/ankit-dhaka-10275223a

Twitter (X) : https://x.com/ak_xpl0it