Post cover image
Figure 1 — Room landing page introducing the challenge.

July 28, 2026

Room 404 | TryHackMe Write-up

Platform: TryHackMe Event: Hacker Holidays 2026 Category: Web Difficulty: Easy Severity: Medium Target: Byte Lotus Guest Experience…

By Abdelrahman Ahmed Saad

5 min read

Platform: TryHackMe Event: Hacker Holidays 2026 Category: Web Difficulty: Easy Severity: Medium Target: Byte Lotus Guest Experience Platform Completion Date: 28 July 2026 Room Link: https://tryhackme.com/room/hh-theconciergeknows-2d7eb4d9

Challenge Overview

Room 404 is a web security challenge from TryHackMe's Hacker Holidays 2026 event. The challenge revolves around discovering resources that are unintentionally exposed on a web server. Rather than exploiting a traditional web vulnerability, the objective is to investigate the target, uncover hidden resources, recover the exposed source code, and identify sensitive information left behind during development.

None

Challenge Objective

The objective of this challenge is to investigate the target web application, identify any unintentionally exposed resources, recover the application's source code, and locate the sensitive information left behind by the developers. The room demonstrates how a simple configuration mistake, such as exposing a Git repository, can lead to complete source code disclosure.

Reconnaissance

The first step was to access the target web application running on port 8080. Before using any automated tools, a manual inspection was performed to understand the application's structure and gather as much information as possible.

The homepage appeared to be a normal website for the Byte Lotus Guest Experience Platform, containing navigation links, promotional content, and a booking button. At first glance, nothing seemed unusual or vulnerable.

Instead of immediately attempting exploitation, the focus remained on reconnaissance by carefully examining the application's visible content and searching for any clues that could reveal hidden resources or development artifacts.

None

Clue 1 — Inspecting the Page Source

After manually exploring the homepage, the next step was to inspect the HTML source code. Reviewing the source revealed a navigation link pointing to the /booking endpoint.

Although the endpoint appeared to be part of the application, accessing it resulted in a 404 Not Found response. While this did not immediately expose any sensitive information, it confirmed that additional resources existed beyond the visible interface.

Rather than treating the 404 page as a failure, it served as an indication that the application might contain hidden or unlisted resources worth investigating further.

None

Observation The presence of the /booking endpoint demonstrated that the visible interface did not necessarily represent the complete application. Even though the endpoint returned a 404 Not Found response, it suggested that additional resources or development artifacts might still exist on the server. Rather than assuming the path was irrelevant, it became a clue that further enumeration was required.

Clue 2 — Directory Enumeration

Since the manual inspection did not reveal any useful information, the next step was to enumerate the web server for hidden files and directories. Before running any enumeration tool, I searched the AttackBox for an available wordlist.

find /usr/share/wordlists -name "*.txt"

The search confirmed that the default dirb wordlist was available:

/usr/share/wordlists/dirb/common.txt

With a suitable wordlist identified, I launched Gobuster to enumerate hidden resources on the target web server.

gobuster dir -u http://<MACHINE_IP>:8080 -w /usr/share/wordlists/dirb/common.txt

The scan produced an interesting result:

None

Instead of discovering a hidden page, the scan revealed that the server exposed a Git repository, making it possible to investigate the application's source code.

Observation The enumeration process revealed a publicly accessible Git repository. Exposing the .git directory is a critical security misconfiguration because it can allow attackers to recover the application's source code, commit history, configuration files, and other sensitive development artifacts.

Clue 3 — Verifying the Exposed Git Repository

After discovering the /.git/HEAD endpoint during directory enumeration, I accessed it directly through the browser.

Instead of displaying the content in the browser, the server automatically downloaded a file named HEAD. Opening the downloaded file revealed the following content:

None

This confirmed that the exposed directory belonged to a valid Git repository. Since the Git metadata was publicly accessible, the next objective was to recover the entire repository instead of downloading files one by one.

Observation Downloading the HEAD file confirmed that the server was exposing Git metadata instead of blocking access to it. This is a common security misconfiguration that can allow attackers to reconstruct the entire repository using publicly available tools.

Clue 4 — Recovering the Git Repository

After confirming that the exposed .git directory belonged to a valid Git repository, the next step was to recover its contents.

Since GitDumper was not available on the AttackBox, I cloned the GitTools repository, which includes the gitdumper.sh utility.

git clone https://github.com/internetwache/GitTools.git
cd GitTools/Dumper
./gitdumper.sh http://<MACHINE_IP>:8080/.git/ ~/repo

The recovery process successfully downloaded the exposed Git repository. After restoring the repository locally, the project files became available for inspection, including README.md, app.js, and index.html.

None

Observation An exposed Git repository can reveal far more than the application's public interface. Once the repository is recovered, attackers may gain access to source code, configuration files, development notes, and other sensitive information that was never intended to be exposed.

Clue 5 — Discovering the Hidden Flag

With the repository successfully recovered, I began reviewing the project files for sensitive information left behind during development.

One of the first files examined was README.md, where I discovered a flag that had been accidentally committed to the repository.

None

The file contained the challenge flag, confirming that sensitive information had been left inside the application's source code.

Observation Sensitive information should never be stored inside a Git repository, even if it is later removed from the application. Once a repository becomes publicly accessible, attackers can inspect source code and project files to recover secrets, credentials, or other confidential information.

Security Concepts

This challenge demonstrates how a simple misconfiguration can expose an application's entire source code.

Tools Used

  • Gobuster
  • GitTools (gitdumper.sh)
  • Git
  • Linux Terminal
  • Web Browser

Exposed Git Repository

A Git repository contains much more than the application's source code. It stores commit history, branches, configuration files, references, and other development metadata. If the .git directory is publicly accessible, attackers may be able to reconstruct the complete repository using freely available tools.

Directory Enumeration

Directory enumeration is the process of discovering hidden files and directories that are not linked from the application's interface. In this challenge, Gobuster was used to identify the exposed /.git/HEAD endpoint, which ultimately led to the recovery of the entire repository.

Information Disclosure

The recovered repository contained sensitive information that should never have been publicly accessible. Information disclosure vulnerabilities occur when applications unintentionally expose internal resources, source code, credentials, or confidential data to unauthorized users.

Key Takeaways

  • Never expose the .git directory on a production web server.
  • Perform directory enumeration during web application assessments, as hidden resources may reveal sensitive information.
  • Publicly exposed Git repositories can leak source code, commit history, configuration files, and development artifacts.
  • Sensitive information should never be stored inside a repository unless it is properly protected.
  • Small configuration mistakes can result in significant information disclosure vulnerabilities.

References