TryHackMe Corridor Walkthrough Finding the Hidden Room Through Predictable MD5 Hashes

Corridor is a beginner-friendly web security challenge that demonstrates how seemingly obscured resources can still be predictable. The application uses MD5 hashes as URL paths, but a closer look reveals a simple numerical pattern behind them.

Note: This write-up contains spoilers for the TryHackMe Corridor room.

Corridor, A beginner friendly challenge, TryHackMe

Step 1: Deploying the Machine

As soon as I started the machine, TryHackMe provided me with the target IP address:

10.49.183.88

My first step was to perform basic reconnaissance against the target.

I used the following Nmap command:

nmap -sC -sV -PE 10.49.183.88

Where:

• -sC runs Nmap's default scripts.
• -sV attempts to identify service versions.
• -PE performs an ICMP echo ping.
• The target IP is the machine provided by TryHackMe.

nmap scan on target ip

Therefore, the only accessible service was a web server running on port 80.

Step 2: Exploring the Website

Since port 80 was the only open port, I navigated to the website:

http://10.49.183.88

The website presented a corridor containing several doors. Each door led to a different URL.

After opening the doors and observing the URLs, I collected paths similar to the following:

First set of rooms

/c4ca4238a0b923820dcc509a6f75849b
/c81e728d9d4c2f636f067f89cc14862c
/eccbc87e4b5ce2fe28308fd9f2a7baf3
/a87ff679a2f3e71d9181a67b7542122c
/e4da3b7fbbce2345d7772b0674a318d5
/1679091c5a880faf6fb5e6087eb1b2dc

There were additional rooms with paths such as:

/8f14e45fceea167a5a36dedd4bea2543
/c9f0f895fb98ab9159f51fd0297e236d
/45c48cce2e2d7fbdea1afc51c7c6ad26
/d3d9446802a44259755d38e6d163e820
/6512bd43d9caa6e02c990b0a82652dca
/c20ad4d76fe97759aa27a0c99bff6710
/c51ce410c124a10e0db5e4b97fc2af39

At first glance, these values appeared to be random strings. However, all of them had something in common:

• They were 32 characters long.
• They contained hexadecimal characters.
• Their format strongly resembled MD5 hashes.

This suggested that the URL paths were generated by hashing some underlying values.

URLs to the rooms

Step 3: Looking for a Pattern

The next step was to determine what values were being hashed.

Rather than treating every hash as a completely random value, I looked at the rooms in their displayed order.

The simplest hypothesis was that the values might correspond to consecutive numbers:

1, 2, 3, 4, 5, 6, ...

I started with the first hash:

c4ca4238a0b923820dcc509a6f75849b

Using a hash lookup or by calculating the MD5 hash of 1, we get:

MD5("1") = c4ca4238a0b923820dcc509a6f75849b

This was an exact match.

The second path also followed the same pattern:

MD5("2") = c81e728d9d4c2f636f067f89cc14862c

The third:

MD5("3") = eccbc87e4b5ce2fe28308fd9f2a7baf3

And so on.

The pattern was now clear.

The application was using the MD5 hash of consecutive numbers as the URL path.

For instance,

Cracking the first hash

The hashes were not actually providing meaningful protection because the underlying values were extremely predictable.

Step 4: Testing for Hidden Resources

Now that I understood the URL-generation pattern, I began thinking about resources that might exist but were not visible through the application’s interface.

The visible doors appeared to correspond to sequential numbers, so I tested values outside the visible sequence.

For example, I calculated the MD5 hash of 14:

echo -n "14" | md5sum

This produced:

aab3238922bcc25a6f606eb525ffdc56

I then attempted to visit:

http://10.49.183.88/aab3238922bcc25a6f606eb525ffdc56

However, that resource did not exist.

Get Kriz’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

So, instead of only checking higher numbers, I considered the possibility that the hidden resource might be a value before the visible sequence.

The visible rooms began with:

1

What comes before 1?

0

I calculated the MD5 hash of 0:

echo -n "0" | md5sum

The result was:

cfcd208495d565ef66e7dff9f98764da

I then visited:

http://10.49.183.88/cfcd208495d565ef66e7dff9f98764da

And… boom! 🎉

The hidden room contained the flag.

Flag-Corridor

flag{2477ef02448ad9156661ac40a6b8862e}

The Core Vulnerability

The key issue in this challenge was the use of predictable identifiers.

The application attempted to obscure resources by using MD5 hashes in the URLs:

/resource/<md5-hash>

However, the original values being hashed were simply predictable sequential integers:

MD5(1)
MD5(2)
MD5(3)
MD5(4)
...

An MD5 hash may make the URL look random, but hashing predictable data does not make the underlying resource secure.

Once the pattern was identified, it was possible to generate hashes for other numbers and enumerate potential hidden resources.

Conceptually, the application looked something like this:

import hashlib

room_number = 1
path = hashlib.md5(str(room_number).encode()).hexdigest()

If an attacker can predict the input, they can calculate the resulting hash themselves.

Lessons Learned

This room taught me several useful lessons about web application security and enumeration.

1. Obscurity is not security

Just because an identifier looks random does not mean it is secure.

A URL such as:

/c4ca4238a0b923820dcc509a6f75849b

may look difficult to guess, but it becomes predictable if it is generated from a simple value such as:

MD5("1")

2. Always look for patterns

When multiple values have a similar format, compare them instead of analyzing each one independently.

In this case, the sequential order of the rooms provided an important clue.

The pattern was:

1 → MD5(1)
2 → MD5(2)
3 → MD5(3)
...

Once that relationship was identified, the challenge became much easier to solve.

3. Enumerate values around the known range

When a sequence starts at 1, do not forget to check:

0

Similarly, when resources appear to follow a sequence, testing values immediately before or after the visible range can reveal hidden resources.

4. Hashing is not access control

A hash should not be used as the only mechanism for protecting sensitive resources.

If access to a resource is supposed to be restricted, the application should implement proper:

• Authentication
• Authorization
• Server-side access-control checks
• Unpredictable, securely generated identifiers where appropriate

Simply converting a predictable ID into an MD5 hash does not provide real security.

Final Thoughts

The Corridor room was a simple but valuable challenge that demonstrated an important security principle: predictability can defeat obscurity.

The initial Nmap scan showed that the target only exposed an HTTP service, which directed the investigation toward the web application. By examining the URLs behind each door, I identified that the paths were MD5 hashes. Further analysis revealed that these hashes corresponded to sequential numbers.

Instead of trying to “crack” every hash individually, identifying the pattern allowed me to generate my own candidate hashes. Testing the value immediately before the visible sequence — 0—led directly to the hidden room and the flag.

The main takeaway is simple:

A predictable value does not become secure simply because it has been hashed.

Thanks for reading!

This write-up is intended for educational purposes and documents a challenge from the TryHackMe learning platform.