Introduction

The Lo-Fi room on TryHackMe is a beginner-friendly web exploitation challenge themed around a lo-fi music streaming site. The goal is simple: find the flag hidden in the / (root) of the filesystem. Despite the chill aesthetic, the vulnerability inside is a classic and critical one — Local File Inclusion (LFI), combined with a Path Traversal attack.

This writeup walks through the full exploitation process step by step, from initial reconnaissance all the way to capturing the flag.

Room link: https://tryhackme.com/room/lofi

Background — What is LFI?

Local File Inclusion (LFI) is a web vulnerability that occurs when an application uses user-supplied input to include files on the server without proper sanitization. If an attacker can control the file path parameter, they can "traverse" outside the intended directory using sequences like ../ to read arbitrary files on the server.

Path Traversal (also called Directory Traversal) is the technique used to navigate the directory tree. On Linux systems, each ../ moves one level up the directory hierarchy. By chaining enough of these, an attacker can reach the filesystem root (/) and read any file the web server process has access to.

Impact can include: reading sensitive config files, exposing credentials, leaking source code, or — in more severe cases — achieving Remote Code Execution (RCE) via log poisoning or /proc/self/environ injection.

Step 1 — Reconnaissance

Nmap Scan

The first step in any engagement is reconnaissance. After deploying the machine on TryHackMe and connecting via the AttackBox, a service version scan was run against the target:

Two ports are open:

• Port 22 — SSH (OpenSSH 8.2p1)

• Port 80 — HTTP (Apache 2.2.22 on Ubuntu)

The web server is the obvious attack surface. Apache 2.2.22 is notably old, but the real vulnerability here is in the web application itself.

Website Enumeration

Navigating to http://10.49.143.45 reveals a Lo-Fi music site with an embedded YouTube player and a sidebar with a Discography section containing links to different pages: Relax, Sleep, Chill, Coffee, Vibe, and Game.

Viewing the page source immediately reveals the critical information — the URL structure used for navigation:

The ?page= parameter is being used to dynamically include PHP files into the page. This is a textbook LFI vulnerability — the application takes user input and passes it directly to a file inclusion function (likely include() or require() in PHP) without sanitizing the input.

Step 2 — Exploitation

Testing for LFI

To confirm the vulnerability, the classic LFI test is to attempt to read /etc/passwd — a world-readable file present on all Linux systems that stores user account information.

The payload uses ../ sequences to traverse up from the web application's working directory to the filesystem root:

http://10.49.143.45/?page=../../../../../etc/passwd

The server responds by including the full contents of /etc/passwd directly in the page — confirming the LFI vulnerability is exploitable with no filtering in place.

Why five ../ sequences? The web application likely lives a few directories deep (e.g., /var/www/html/). Each ../ moves one level up. Using five or more ensures we reliably reach the filesystem root regardless of the exact depth. Once you've passed the root, additional ../ sequences are simply ignored by the OS.

Reading the Flag

The room description states the flag is located at the root of the filesystem. On Linux that means the path is simply /flag.txt. Crafting the payload:

http://10.49.143.45/?page=../../../../../flag.txt

The server responds with the flag rendered directly on the page:

flag{FIND_IT_BY_YOURSELF_LOL}

Step 3 — Why Does This Work?

The vulnerable PHP code likely looks something like this on the backend:

<?php

$page = $_GET['page'];

include($page);

?>

The application takes the value of ?page= directly from the URL and passes it to PHP's include() function. There is no validation, no whitelist of allowed filenames, and no sanitization of ../ sequences. The web server process (running as www-data) has read access to /flag.txt, so the file is served back to us in the response.

Key Takeaways

• Never trust user input — always validate and sanitize parameters used in file operations.

• The ?page= pattern is an immediate red flag — always check for LFI when you see it.

• Viewing page source can reveal the vulnerability structure instantly, without any tools.

• LFI + Path Traversal is a beginner technique but remains a real-world threat vector.

• Defense requires whitelisting, not just blacklisting — filtering ../ alone is often bypassable.