Difficulty: Beginner-Friendly | Category: Web Exploitation

Hello everyone

I'm Chetan Chinchulkar (aka omnipresent), and we're switching gears! After conquering two OSINT challenges (the wooden duck mystery and the Among Us university), it’s time to dive into web exploitation.

Now, before you imagine me typing furiously with a hoodie on in a dark room (okay, maybe that’s accurate sometimes 😅), let me tell you about a challenge that taught me an important lesson: sometimes the best hacking technique is just knowing how to read.

The Challenge: Login Panel

Category: Web Exploitation
Points: 100
Description: Simple login panel
URL: https://tommytheduck.github.io/login

What we got: A URL leading to a login prompt. That’s it. No hints, no files, just a login form staring back at me.

When I first opened this challenge, I thought, “Alright, time to break out the big guns — SQL injection, XSS, brute force…” But then I remembered something my mentor once told me:

“Before you try to break in through the window, check if the door is unlocked.”

Wise words. Let’s see how they applied here.

My Approach: From Brute Force Dreams to Reality Checks

Step 1: The Classic Default Credentials Dance

Look, I know it’s 2025 (well, almost 2026), but you’d be shocked how often default credentials still work. So naturally, my first move was trying the classics:

• admin:admin ❌
• admin:password ❌
• user:user ❌
• user:password ❌ (had to try it)

Result: Nope, nope, and more nope.

Okay, so the challenge creator wasn’t that generous. Fair enough. Time to dig deeper.

Step 2: View Page Source (The Underrated MVP)

Here’s something I’ve learned from CTFs: View Page Source is your best friend in web challenges. It’s like the metadata check of OSINT — you always do it, even when you think it won’t help.

I right-clicked, hit “View Page Source,” and there it was — the entire login logic laid bare in beautiful, unobfuscated JavaScript.

My immediate reaction: “Wait… they just… left the hashes in the source code? In client-side JavaScript?”

Yes. Yes, they did. And honestly? This is more common in real-world applications than you’d think

Step 3: Understanding the Code (Reading Comprehension FTW)

Let me break down what this code is doing, because understanding is half the battle:

1. Takes user input — Username and password from prompt boxes
2. Hashes them — Uses SHA-256 to hash both inputs
3. Compares hashes — Checks if your hashed inputs match the hardcoded hashes
4. Reveals the flag — If they match, alerts the flag in format username{password}

Key observations:

• The hashing algorithm is SHA-256 (clearly stated in the code)
• The username hash: ba773c013e5c07e8831bdb2f1cee06f349ea1da550ef4766f5e7f7ec842d836e
• The password hash: 48d2a5bbcf422ccd1b69e2a82fb90bafb52384953e77e304bef856084be052b6
• The flag format is literally given: username{password}

So now the challenge becomes: crack these SHA-256 hashes.

Step 4: Hash Cracking (Or: Why Rainbow Tables Exist)

Now, I could fire up Hashcat and start a brute force attack. Set up a wordlist, configure the hash mode for SHA-256, let my laptop fan scream for a while…

Or…

I could check if these hashes are already cracked and sitting in an online database. Because let’s be real — if the challenge creator used common passwords (and they usually do for beginner challenges), someone’s already cracked them.

I headed over to CrackStation, pasted both hashes, and hit “Crack Hashes.”

Boom! 💥

• Username hash → v1t
• Password hash → p4ssw0rd

Fun fact: The password is literally “password” with leetspeak. Classic CTF move. I respect it.

Step 5: Assembling the Flag

Remember the flag format from the code?

alert(username + '{' + password + '}');

So: v1t + { + p4ssw0rd + }

The Flag

v1t{p4ssw0rd}

Submitted. Accepted. Web challenge conquered! 🎉

What This Challenge Taught Me

1. Client-Side Security Is Not Security

Storing credentials (even hashed ones) in client-side JavaScript is a massive security flaw. Anyone can view the source code and extract sensitive information. This challenge is a perfect example of what not to do in real-world applications.

Real-world lesson: Always validate and authenticate on the server-side, never trust the client.

2. Reading > Tools (Sometimes)

I could’ve gone straight to automated tools, but taking 2 minutes to read and understand the code saved me time and gave me the exact information I needed. In CTFs and real pentesting, understanding the logic is often more valuable than throwing tools at the problem.

3. Rainbow Tables Are Your Friend

Services like CrackStation maintain massive databases of pre-computed hashes. For common passwords, they’re instant. For CTF challenges, they’re often all you need.

When to use what:

• CrackStation/Online databases — First try for common hashes
• Hashcat — When you need custom wordlists or rules
• John the Ripper — Alternative to Hashcat, great for various hash types

4. Default Credentials Are Still Worth Trying

Even though they didn’t work here, checking default credentials takes 30 seconds and works surprisingly often. Never skip the basics!

Web Exploitation Toolkit

For this challenge, the essential tools were:

• Browser DevTools — View Page Source (F12 or right-click → Inspect)
• CrackStation — Online hash cracking database
• Hashcat — Offline hash cracking (if needed)
• John the Ripper — Alternative hash cracker
• Brain.exe — Reading comprehension and logic

Pro tip: Before reaching for complex tools, always check the page source. You’d be amazed what developers leave exposed.

Alternative Approaches

While I used CrackStation, here are other ways you could’ve solved this:

Method 1: Hashcat

# Save hashes to a file
echo "ba773c013e5c07e8831bdb2f1cee06f349ea1da550ef4766f5e7f7ec842d836e" > username_hash.txt
echo "48d2a5bbcf422ccd1b69e2a82fb90bafb52384953e77e304bef856084be052b6" > password_hash.txt

# Crack with rockyou.txt wordlist
hashcat -m 1400 -a 0 username_hash.txt /usr/share/wordlists/rockyou.txthashcat -m 1400 -a 0 password_hash.txt /usr/share/wordlists/rockyou.txt

Method 2: Browser Console Manipulation

You could’ve modified the JavaScript directly in the browser console to bypass the check entirely. But where’s the fun in that?

Method 3: Hash Lookup APIs

Use APIs like hashes.com or md5decrypt.net programmatically if you're automating.

Real-World Implications

This challenge, while simple, highlights a real security issue I’ve seen in production applications:

The Problem: Developers sometimes implement authentication logic client-side for “convenience” or “speed,” thinking that hashing makes it secure.

The Reality: If the client has access to the validation logic, an attacker does too.

The Fix:

• Authenticate on the server
• Never expose hashes or validation logic to the client
• Use proper session management
• Implement rate limiting to prevent brute force

If you’re building web apps, let this challenge be a reminder: security through obscurity is not security.

How Would You Have Solved This?

I’m curious about your approach:

• Did you try different hash cracking tools?
• Did you bypass the check entirely using browser console?
• Did you recognize the hashes immediately? (If so, teach me your ways!)

Drop your methodology in the comments — I love learning new techniques!

Let’s Connect!

If you’re enjoying these writeups, let’s stay connected:

• TryHackMe Profile — Currently top 1%, let’s compete!
• LinkedIn — For networking and professional stuff
• Twitter/X — CTF updates, cybersecurity thoughts, and occasional memes

Enjoyed this writeup? Give it a clap 👏 (or several — I won’t judge your enthusiasm), and follow for more CTF content!

Final Thoughts

This challenge was a perfect reminder that web exploitation isn’t always about complex exploits or zero-days. Sometimes it’s about:

• Reading the code carefully
• Understanding the logic
• Using the right tool for the job
• Not overcomplicating things

In cybersecurity, we often get caught up in learning the latest tools and techniques (guilty as charged). But fundamentals matter. Understanding how things work is more valuable than knowing which tool to use.

Whether you’re:

• Pentesting a web application
• Doing a security audit
• Hunting for bug bounties
• Or just solving CTF challenges for fun

…the methodology stays the same: observe, understand, exploit, verify.

Happy hacking, and may your hashes crack quickly!

P.S. — The password being “p4ssw0rd” is peak CTF humor. It’s like the challenge is saying, “Yes, we know it’s a terrible password. That’s the point.” I appreciate the self-awareness. 😂

P.P.S. — If you’re a web developer reading this and thinking, “I would never do this in production” — good! But also, do a quick audit of your codebase. You’d be surprised what sometimes slips through code reviews. Ask me how I know…