Post cover image

July 28, 2026

TryHackMe Hacker Holidays Day 2 Walkthrough “Room 404”

Introduction

By Shamita

2 min read

Introduction

Room 404 is a beginner-friendly web security challenge on TryHackMe that focuses on one of the most common and dangerous web application misconfigurations: an exposed Git repository.

The room's objective is straightforward:

  • Dump the exposed source code.
  • Find the hidden flag.

Although the challenge is classified as "Very Easy," it introduces an important real-world vulnerability that has resulted in numerous security incidents.

Initial Enumeration

The first step was to visit the application hosted on port 8080.

http://<TARGET_IP>:8080

The homepage displayed a professional hotel-themed website called Byte Lotus.

A quick inspection revealed:

  • A Flask application (Werkzeug server headers)
  • A broken /booking link
  • No obvious functionality to exploit

Since the room description hinted that "the rooms it never lists are the ones worth finding," it was clear that directory enumeration was the next logical step.

Directory Enumeration

I started with Gobuster.

gobuster dir \
-u http://TARGET:8080 \
-w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt

Interestingly, Gobuster returned nothing useful.

At this point there were two possibilities:

  • Hidden files rather than directories
  • An exposed development artifact

Looking for Common Developer Mistakes

One of the most common mistakes developers make is accidentally exposing the .git directory.

Testing for it was as simple as requesting the Git HEAD file.

curl http://TARGET:8080/.git/HEAD

The response immediately confirmed the vulnerability.

ref: refs/heads/main

This meant the entire Git repository was publicly accessible.

Confirming Repository Exposure

Next I checked a few additional Git files.

curl http://TARGET:8080/.git/config
curl http://TARGET:8080/.git/index
curl http://TARGET:8080/.git/refs/heads/main

The repository exposed:

  • HEAD
  • config
  • index
  • refs
  • objects

This confirmed that the application's entire version history was accessible over HTTP.

Downloading the Repository

Since the AttackBox could not access GitHub to install Git dumping tools, I used wget to mirror the exposed repository.

wget -r -np -nH --cut-dirs=1 \
http://TARGET:8080/.git/

The download included:

  • Git objects
  • references
  • logs
  • hooks
  • configuration
  • repository metadata

With all repository files downloaded locally, reconstructing the repository became straightforward.

Recovering the Source Code

After placing the downloaded files inside a local .git directory, Git was able to recognise the repository.

From there I recovered the working tree and inspected the project files.

Once the source code was available, searching for the flag was trivial.

Typical searches include:

grep -R "THM{" .

or

grep -R "flag" .

Eventually the flag appeared.

THM{byt3_l0tus_n3v3r_f0rg3ts}

Why This Vulnerability Matters

An exposed .git directory is far more dangerous than many people realise.

If an attacker can access the repository, they may obtain:

  • Source code
  • API keys
  • Database credentials
  • Environment variables
  • Authentication secrets
  • Internal documentation
  • Commit history
  • Deleted files that still exist in Git history

Even if sensitive files have been removed from the application, Git history often preserves them indefinitely.

How to Prevent This

Developers should never deploy the .git directory to production.

Recommended mitigations include:

  • Exclude .git from deployments.
  • Configure the web server to deny access to hidden files.
  • Use deployment pipelines that export only the application source rather than the repository.
  • Regularly scan production environments for exposed development artifacts.

Lessons Learned

Although Room 404 is a beginner-level challenge, it reinforces an important lesson:

Enumeration is often more valuable than exploitation.

No complex payloads, brute forcing, or vulnerability chaining were required.

A single HTTP request to:

/.git/HEAD

revealed enough information to recover the application's source code and ultimately retrieve the flag.

This room is an excellent reminder that simple misconfigurations can completely undermine the security of an otherwise well-designed application.

Happy hacking!