Post cover image

July 28, 2026

Room 404- TryHackMe Walkthrough

One of the most overlooked web application misconfigurations is exposing the .git directory over HTTP.

By Ishant

3 min read

Developers often deploy web applications directly from their local repositories. If the .git directory is accidentally left inside the web root, an attacker may recover the application's source code, configuration files, secrets, API keys, or even credentials.

In this write-up, I'll walk through my methodology while solving the TryHackMe Room 404 lab, where an exposed Git repository became the key to obtaining the application's source code.

I guess there's already a lot hint about the lab using this Introduction, But still if you are gonna read ahead, carry on with a bunch of claps and shares!!

Initial Enumeration

As always, the first step was identifying the available services and doing a depth recon!

I performed a massive Rustscan scan:

rustscan -a -r 1-65535
None

But i thought it's missing something, so i carry forwarded it with nmap>

None None

Although, the results didnt surprised me anyway.

The scan revealed only two open ports.

22/tcp    OpenSSH
8080/tcp  Werkzeug HTTP Server

The web application was running on port 8080, while SSH was protected using public key authentication, making password-based login unavailable.

At first glance, the web application looked extremely minimal.

Only the landing page (index.html) was accessible.

Directory brute forcing didn't reveal anything interesting.

Discovering the Hidden Git Repository

Running directory enumeration eventually produced something unexpected.

None 
/.git/HEAD

The file when i located using browser, downloaded a file named "HEAD".

which when did 'file', returned ASCII and did 'cat', returned:

ref: refs/heads/main
None

This immediately suggested that a Git repository existed on the server.

Naturally, I attempted to access the written url files.

refs/heads/main
refs/heads/
refs/
.git/refs/heads/main
.git/refs/heads/
.git/refs/
.git

and as expected…

None

then i tried accessing each one of them, and non of them worked.

Every request returned 404 Not Found.

At this stage, it looked like the repository had either been deleted or intentionally broken. but the confusing part was why are all indexed here??

This created the illusion that nothing useful remained inside the repository.

Most people would probably stop here.

Fortunately, I decided to verify the finding using Nmap's NSE scripts.

Nmap Reveals Something Interesting

Running:

nmap -Pn -A <TARGET-IP>

produced a very interesting result.

http-git:
Git repository found!
Repository description:
Unnamed repository
Last commit message:
initial Byte Lotus guest platform

This was the turning point.

Even though manual browsing suggested the repository was inaccessible, the NSE script successfully extracted Git metadata.

That meant there was likely more information available than what the browser was showing.

Recovering the Repository

Instead of downloading files manually, I switched to an automated Git extraction tool.

git-dumper http://ip:8080/.git recovered_repo

To my surprise…

It worked.

The tool reconstructed the repository despite the broken-looking directory structure.

None

This demonstrates an important lesson:

Never assume a repository is unrecoverable simply because manual requests return 404.

Git recovery tools understand Git's internal object database and can often recover repositories that appear inaccessible through a browser.

Why Did This Work?

Git repositories consist of multiple internal components:

  • HEAD
  • refs
  • objects
  • pack files
  • index
  • logs

Even if some files are inaccessible individually, enough Git objects may still be exposed to reconstruct the repository.

Automated tools know how Git stores commits, trees, and blobs internally.

Instead of relying on directory browsing, they recover objects directly and rebuild the repository.

Impact of an Exposed Git Repository

Recovering a Git repository can expose sensitive information including:

  • Application source code
  • Hidden endpoints
  • API routes
  • Debug functionality
  • Credentials
  • Environment variables
  • Database connection strings
  • API tokens
  • Hardcoded secrets
  • Previous commits containing deleted sensitive data

Even if secrets are removed from the latest version, Git history may still contain them.

This is why exposing .git is considered a serious security misconfiguration.

Key Touch:

  • The tool if not available in your system can be installed easily using pipit or if not then can go with python virtual environment
  • Simplest method: download pipit, copy to /usr/bin then enter the command:
  • pipit git-dumper
  • https://github.com/ishant-g/pipit.git — url to get pipit and make your life easier<>

pipit is a pyython wrapper created by me for helping solve the python, pip and venv issues and save time, just enter pipit to install it!

See you guys in the next blog, until then

Happy Hacking!!