Post cover image

July 29, 2026

🏨 Hacker Holidays: The Byte Lotus Hotel — Room 404 (Walkthrough)

https://tryhackme.com/room/hh-room404-804573bf

By ghosteye💀

3 min read

Scenario

The Byte Lotus Hotel runs a guest-experience web platform on port 8080. The briefing hints that the app was "shipped in a hurry" by a night-shift developer, and that something exists which "isn't on the floor plan" — a strong signal that this challenge revolves around information disclosure rather than active exploitation.

Step 1 — Reconnaissance

Every engagement starts with understanding what's actually exposed. Since the room specifies port 8080 and the category is Web, the first move is to simply open the target in a browser and see what's being served:

http://<TARGET_IP>:8080/
None

This confirms the app is up and gives a first look at the front-end — in this case, a static guest-experience landing page for the Byte Lotus Hotel.

Step 2 — Directory Enumeration

The briefing explicitly calls out "Web Directory Enumeration" as the objective, and mentions a room "not on the floor plan" — meaning there's content on the server that isn't linked from the visible site. This is a job for a content discovery tool like gobuster:

gobuster dir -u http://<TARGET_IP>:8080 -w /usr/share/wordlists/dirb/common.txt -x php,html,txt,json -t 50

Why this wordlist: common.txt is small and fast, and it includes many standard "developer leftover" paths — including .git, .env, backup/, admin/, etc. — which is exactly the kind of thing a rushed deployment tends to expose.

The scan returned:

.git/HEAD (Status: 200)

This single result is the whole challenge. A 200 OK on .git/HEAD means the entire Git repository is publicly exposed on the web server — a very common real-world misconfiguration where a developer copies their working directory (including the hidden .git folder) straight into the web root.

Step 3 — Confirming the Exposure

Before pulling anything down, it's worth manually confirming the exposure and understanding its scope:

curl http://<TARGET_IP>:8080/.git/
None

Directory listing was enabled, showing the full internal structure of the repo: HEAD, config, logs/, objects/, refs/, etc. This confirms not just that the repo is exposed, but that directory browsing makes it trivial to reconstruct.

Step 4 — Dumping the Repository

Rather than manually walking every object by hand, the standard tool for this exact scenario is git-dumper, which reconstructs a fully working local copy of an exposed .git folder:

pip install git-dumper --break-system-packages
git-dumper http://<TARGET_IP>:8080/.git/ ./byte-lotus-source

Why git-dumper specifically: it doesn't just grab loose files — it parses .git/index and the object store to correctly rebuild the commit tree, then runs git checkout . automatically to materialize the real working files. This matters because a naive wget --mirror would only get the raw Git internals, not a usable, readable source tree.

The dump produced three files:

app.js
index.html
README.md

Step 5 — Analyzing the Source

With the source recovered, the next step is manual review — this is the "dump the exposed source code" objective from the briefing completed. Reading through the files by hand (rather than blindly grepping) is important here, since a small internal README is easy to miss with automated tools if the flag format isn't anticipated.

cat README.md

Output:

# Byte Lotus — Guest Experience Platform
Internal staging repository for the guest app and concierge personalization
service. Do not deploy this folder to production.
Staging flag (remove before launch): THM{byt3_l0tus_n3v3r_f0rg3ts}

There it is — a staging flag that was clearly meant to be stripped out before the site went live, left behind because the .git folder (including this README) was deployed straight to production alongside the actual site.

🚩 Flag

THM{byt3_l0tus_n3v3r_f0rg3ts}

Root Cause / Lesson

This challenge models a real and common vulnerability class: exposed .git directories in production. It typically happens when:

  • A developer deploys via git pull or copies a working directory directly to the web server, instead of using a proper CI/CD build/export step.
  • The web server has no rule blocking access to dotfiles/dotfolders (.git, .env, .htaccess, etc.).

Mitigation

  • Never deploy the .git folder to a public web root.
  • Explicitly deny access to dotfiles at the web server level (e.g., in nginx: location ~ /\.git { deny all; }).
  • Use .gitignore and CI pipelines that export only build artifacts, not the full repo.

Tool Summary

Tool Purpose curl Manual verification of endpoints and headers gobuster Directory/file brute-force enumeration git-dumper Reconstructing an exposed .git repository into working source grep Searching source/history for flags, secrets, credentials

Writeup prepared for personal notes / portfolio use — TryHackMe: Hacker Holidays, "The Byte Lotus Hotel", Room 404.

  • #CTF
  • #Git
  • #GitExposure
  • #InformationDisclosure
  • #DirectoryEnumeration
  • #Gobuster
  • #SecurityResearch
  • #SourceCodeReview
  • #DevSecOps
  • #BugBounty