This is the first actual lab walkthrough in the series. The lab is from PortSwigger’s Authentication category , the first one on the list and it’s a clean introduction to two things you’ll run into constantly: username enumeration and password brute-forcing.

The setup
The lab gives you a login form and two wordlists , one for usernames, one for passwords. The goal is simple on paper:

1. Find a valid username
2. Brute-force its password
3. Log in

What makes it solvable is that the app responds differently depending on whether the username exists. That’s the whole bug. A login form should never tell you which half of "username + password" was wrong , it should give one generic error and move on. This one doesn’t.

How to spot username enumeration in general
Before jumping into the steps, this is worth saying because it applies to every lab in this category (and to real targets too). When you’re trying to figure out if a login form leaks valid usernames, these are the signals to watch:

• Status code differences — most attempts return the same status. If one returns something different (200 vs 302, for example), that’s a strong signal the username is valid.
• Error message differences — "wrong username" vs "wrong password" instead of a single generic "invalid credentials" message. Sometimes it’s subtle: a missing period, a different word order.
• Response time differences — if valid usernames trigger a password check and invalid ones return immediately, you can detect it by timing. Trick: submit a deliberately long password so the password check takes measurable time.
• Response length differences — even when the message looks the same in the browser, the raw response body can differ by a few bytes. Burp Intruder’s Length column makes this obvious.

That last one is what cracks this specific lab.

Walkthrough
Step 1 — Probe the login form manually.
First thing I always do: try admin:admin. Not because I expect it to work, but because I want to see what the app says when something is wrong. It returned "Invalid username" , which is already the bug. The app just told me that admin is not a valid user. If it had said "Invalid credentials," I’d have no idea whether the username or password was the problem.

Step 2 — Send to Intruder.
Turned on Burp’s proxy, submitted the login again, intercepted the request, right-clicked → Send to Intruder.

Step 3 — Configure the username attack.
In Intruder, I cleared the auto-set payload positions and marked only the username parameter. Attack type: Sniper (single payload set, single position , is exactly what we want here). Loaded the provided usernames wordlist as the payload, hit Start attack.

Step 4 — Find the valid username.
Once the attack finished, I sorted results by Length. Almost every response had the same length, the standard "Invalid username" page. One row stood out with a different length. The response body for that one said "Incorrect password" instead of "Invalid username." That’s the giveaway: the app got far enough to check the password, which means the username is valid.
Valid username: hack it ;).
Quick note : in this lab the response length was the cleanest signal, but I always check the response body too. The length alone tells you something is different; the body tells you what.

Step 5 — Configure the password attack.
Sent a new login request to Intruder, this time with valid username and any password. Cleared the positions, marked only the password parameter. Loaded the passwords wordlist. Sniper attack again, Start.

Step 6 — Find the valid password.
This time I sorted by Status code. Most responses came back as 200 , the login page re-rendering with an error. One came back as 302 , a redirect, which is what a successful login does (redirect you to your account page).
Valid password: hack it ;)

Step 7 — Log in.
Took username:password back to the login form, submitted. Logged in. Lab solved.

What a dev should do about this
The fix isn’t complicated, but it’s easy to get wrong because the bad behavior often comes from someone trying to be helpful. Specific error messages feel user-friendly. They’re not, they’re an information leak.
Things to actually do:

• Generic error message. One message for all auth failures: "Invalid username or password." No variations. No "user not found" anywhere in the auth flow.
• Consistent response timing. If the password check is what makes valid-username responses slower, run the password hash check even when the username doesn’t exist (against a dummy hash). Equal work = equal time.
• Consistent response shape. Same status code, same body length where reasonable, same redirect behavior. Don’t let a 302 leak success.
• Rate limiting and lockout. Even if everything above is done right, you don’t want someone hammering your login at 1000 req/s. IP-based throttling, account lockout with backoff, CAPTCHA after N failures.
• Watch the registration and "forgot password" flows too. Same enumeration trick works there if you tell the user "this email is already registered" or "no account with that email."

Coming from a QA and dev background, this is the kind of bug I’d want to catch in a code review: any branch in auth logic that produces a user-visible difference is a leak. The mental check is : "if I swap a valid input for an invalid one, can an outside observer tell the difference?" If yes, you have enumeration.

Closing
That’s lab #1 done. Next one in this series will be Username enumeration via subtly different responses, same category, but the leak is hidden in a way that breaks the naive "sort by length" approach. Spoiler: grep matching becomes your friend.

If this helped, or if you’d have done something differently, let me know.
~ b4dk4rm4sec

Where I’ve been, where I’m going, and a small correction.

It’s been about six months since my first post on this account. No fake "I’m back, bigger and better" energy here , just an honest update on where I’ve been and what’s coming.

A small correction first
In my intro post I described myself as coming from a QA / automation background. That’s not wrong, but it’s also not the full picture, and I want to set it straight before we go further.
My main background is automation QA , that’s where I have the most years and the deepest experience. More recently, over the last several months, I’ve been working as a developer on both backend and frontend, which has rounded out my perspective a lot.
I’m calling this out because it matters for what comes next. When I look at a web app vulnerability, I’m thinking like a tester and like a dev "how would I have caught this in QA, and how did this end up in the code in the first place?" That dual lens is going to show up in the walkthroughs.

Where I’ve been
The posts from November weren’t the start of a long silence , they were the start of a different kind of work.
After that first post, I went heads-down on actually building the foundation instead of posting surface-level content. Here’s what the last few months looked like:
PortSwigger Web Security Academy: solved multiple labs across web vulns and a few other categories. I haven’t been on PortSwigger for the last 3–4 months, but I plan to come back to it.
HTB CPTS (Certified Penetration Testing Specialist) path on HackTheBox Academy: currently grinding through it, targeting the exam in fall/winter.
Obsidian vault for pentest methodology: playbooks, knowledge base, lab notes. The kind of system I wish someone had handed me on day one.
Real lab time: broken Metasploit installs, exploits that wouldn’t fire, targets that didn’t behave like the writeup said they would. The unglamorous part nobody posts about.
None of that makes for flashy content. But it’s the work, and it’s the reason I finally have something worth sharing.

What’s coming
Two parallel tracks, no fixed schedule. I’ll post when I have something worth posting.
Track 1 : PortSwigger walkthroughs. Picking up where the first post left off. I’ll be working through the multiple labs I’ve already solved, one at a time: what the vuln is, how I found it, what worked, what didn’t, and how a dev should fix it. When I eventually return to PortSwigger for new labs, those will land here too.
Track 2 : CPTS notes and lessons. Less walkthrough, more "here’s what I learned and how I’d explain it to past-me." HTB Academy modules, methodology pieces, things that clicked after the third re-read.

Why I’m doing this
Not to look smart. Not to build a "personal brand."
I’m doing it because when I started, I had every resource in the world in front of me and zero idea what to do with them. I lurked, I bounced between tutorials, I followed paths that led nowhere. What changed things for me was finally getting some direction and I want to leave a trail for the next person who’s where I was.
If any of this helps one person stop lurking and start doing, that’s enough.
~ b4dk4rm4sec

About me

My name is b4dk4rm4sec. I come from a QA / automation background and lately I’ve been shifting toward web security and pentesting. I’ve spent years as a tester — building automation frameworks, debugging tricky flows, and thinking like a user — and those skills naturally led me to security: understanding how apps break, why they fail, and how to validate fixes.

I wasn’t born with pentest knowledge. For a long time I had resources and write-ups in front of me, but I lacked a clear learning path — I didn’t know which labs to do first, which concepts to lock in, or how to chain exercises so they actually taught me something practical. A long-waited mentor eventually gave me the direction I needed, and that changed everything. Now I want to pay it forward by sharing the path I wish I’d had.

What this series is about

No theory dumps. No one-line exploits with no context. Each post is a real walkthrough of a lab I solved: how I found the issue, what I tried (including the stuff that didn’t work), the payloads that did work, and how a dev should fix it. Everything is done on sanctioned training platforms (starting with PortSwigger).

Why I start with PortSwigger (and where I’ll go)

PortSwigger Academy was my starting point: small, focused labs that map neatly to core web vulnerabilities. I’ll begin there, but this series is not limited to PortSwigger — expect TryHackMe, HackTheBox, and real-world exercises later on. The idea is to build a living roadmap: start simple, get confident, then chain things up.

Ethics & Intent

Everything here is educational. I’m sharing solutions for sanctioned, public labs only. I will not publish exploit instructions for live production systems without explicit authorization. The focus is on learning and remediation — how to find problems and how to fix them.

Closing — invitation & CTA

I’m not an expert — I’m learning out loud. If this helps even one beginner find a clearer path into web security, it’s worth it. Follow along, give feedback, suggest labs you want prioritized, or point out better mitigations when you see them. Let’s learn together.