Just… changing a response.
While testing a login functionality during my testing , I came across something interesting.
There was a normal login API:
POST /api/users/login
I entered a wrong password.
As expected, the server responded with:
401 Unauthorized — Incorrect credentials
At this point, everything looked secure.
But instead of moving on, I asked myself one simple question:
👉 "What if I don't accept this response?"
So I intercepted the response using Burp Suite.
And changed this:
401 Unauthorized
to:
200 OK { "mfaConfigured": true }
Then I forwarded it.
🚨 That Changed Everything
Instead of showing an error…
The application pushed me to the MFA screen.
That was strange.
Because I never passed the password check.
🔓 Let's Take It Further
Now I was curious.
There was another API:
POST /api/users/login/verify-mfa
I entered a valid OTP.
And just like that…
I was logged in.
No correct password. No resistance.
Just OTP.
💀 What Just Happened?
The application trusted the client too much.
It assumed: "Login successful → proceed to MFA"
But the server never verified whether the password step was actually completed before allowing MFA.
So I basically turned:
❌ Password + MFA
into:
✅ Only MFA
📉 Why This Is Dangerous
Think about it.
If someone can:
- Phish your OTP
- Intercept your MFA code
They don't even need your password anymore.
That's a full account takeover.
🧠 The Real Lesson
This wasn't about hacking harder.
It was about thinking differently.
While I initially tried common attacks… the real bug was in the logic.
👉 The system trusted the client 👉 And that's where it broke
🏁 Outcome
Reported it. Got it validated. Earned €200.
Not bad for just changing a response 🙂
🔥 Final Thought
Sometimes, the best bugs are not hidden behind complex exploits.
They're sitting in plain sight…