MFA Bypass Lab
MFA gets bypassed every day — and almost never by beating the factor head-on. Work a queue of sign-in incidents and call each one: a legitimate login, or the real bypass — push-fatigue, a SIM-swap on SMS, a fallback downgrade to a weaker factor, a stolen session token replayed past MFA, a recovery-flow re-enrollment, or an adversary-in-the-middle proxy relaying your OTP. Then pick the control that actually stops it — because number matching kills fatigue but not AitM, only passkeys kill AitM, and token binding (not another prompt) kills a stolen session. You are scored on catch rate against false positives. Clear the queue clean.
The real job. More noise, a tighter clock.
Bypass queue
For each sign-in, name the bypass that actually happened (or call it legitimate), then pick the control that stops it.
#1
3 a.m. approval storm
setup: Authenticator push MFA, tap-to-approve (no number matching)
- ·Correct password entered from an unrecognised IP in Lagos at 03:11
- ·47 Microsoft Authenticator push prompts sent to the phone in 9 minutes
- ·User tapped Approve on prompt #47
- ·Single-tap approval — no number to match on the sign-in screen
#2
The ported number
setup: SMS OTP as the second factor
- ·Carrier record shows the user's mobile number ported to a new SIM at 14:02
- ·User's phone lost signal and showed 'No SIM' at 14:03
- ·SMS OTP for a password reset delivered to the attacker's device at 14:21
- ·Recovery email address changed at 14:25
#3
The 'use another method' link
setup: FIDO2 security key is the primary factor; SMS kept 'as a backup'
- ·Attacker has the password and reaches the MFA screen
- ·Attacker clicks 'Can’t use your security key? Text me a code instead'
- ·Service silently falls back to SMS OTP to the number on file
- ·Attacker completes sign-in with an SMS code (number already SIM-swapped)
#4
Session cookie replay
setup: User already passed MFA this morning
- ·User completed password + push MFA at 08:30 from their normal device
- ·Info-stealer malware on the laptop exfiltrated browser cookies at 08:45
- ·The session cookie is replayed from an attacker IP at 09:10 — no prompt, no MFA
- ·Attacker reaches the mailbox without ever authenticating
#5
'I lost my phone' reset
setup: Self-service account recovery
- ·Attacker knows the user's email and date of birth
- ·Recovery asks only for email + DOB + last 4 of a phone number — all findable
- ·Recovery lets the attacker register a NEW MFA device without presenting the old factor
- ·MFA fully reset and re-enrolled to the attacker in 90 seconds
#6
The pixel-perfect login
setup: User clicked a link in a 'shared document' email
- ·User landed on login.micr0soft-sso.com, a reverse-proxy relaying to the real Microsoft login in real time
- ·User entered the password AND the TOTP code — both relayed live to the genuine site
- ·The proxy captured the issued session cookie
- ·The user genuinely approved their own (relayed) sign-in
#7
The expected trip
setup: Push MFA with number matching enabled
- ·Sign-in from Berlin — user filed travel in the HR system for this week
- ·A single number-matching push, approved in 4 seconds with the correct number typed
- ·Device is the user's known, compliant, MDM-managed phone
- ·No fallback factor offered or used
#8
Two prompts, then in
setup: Push MFA, number matching NOT enabled
- ·Only 2 push prompts, 6 hours apart, from a datacenter ASN
- ·The 2nd arrived one minute after a spoofed call: 'IT here — please approve the test prompt'
- ·User approved, believing the caller
- ·Tap-to-approve; no number to match
#9
The refresh token that outlived the password
setup: User reset their password after a phishing scare
- ·User reset the password and 're-did' MFA after reporting a phishing email
- ·An OAuth refresh token issued to a 'mail client' before the reset is still valid, used from an attacker IP
- ·The password change did NOT revoke existing refresh tokens / sessions
- ·Attacker keeps minting fresh access tokens, never re-authenticating
#10
No signal, then a login
setup: SMS OTP + voice-callback OTP enrolled
- ·User reports 'no service' since this morning — an eSIM profile was silently re-provisioned
- ·The voice-call OTP fallback was answered on a device the user doesn't recognise
- ·Login to the banking portal from a new device using the voice OTP
- ·User never received the code
#11
The convincing caller
setup: Help-desk-assisted MFA reset
- ·Caller gives the help desk the employee's name, manager and employee ID (from LinkedIn + a prior breach)
- ·Help desk resets MFA after 'verifying' with only those knowledge facts
- ·A new device is enrolled by the caller
- ·No callback to a known-good number, no manager approval, no video check
#12
I number-matched and still got breached
setup: Push MFA WITH number matching enabled
- ·User number-matched a push during a login they started on a look-alike site
- ·The look-alike was an AitM proxy relaying to the real IdP in real time
- ·User typed the real number (shown by the relayed genuine prompt) — approval succeeded
- ·Session cookie captured by the proxy
#13
Step-up that steps down
setup: High-value transfers require passkey step-up
- ·A $40k transfer triggers step-up authentication
- ·Passkey step-up fails on the attacker's side (no key) — system offers 'email me a one-time code' instead
- ·The email account was already compromised
- ·Transfer approved via the emailed code
Catch rate vs. false positives
Call each scenario, then grade. So far 0/26 decisions made, 0/12 bypasses named, 0 false positive(s).
How it is scored
Two decisions per scenario — the bypass and its mitigation — each weighs equally.
A false positive (flagging a clean login) takes an extra hygiene bite: an analyst who cries wolf is as useless as one who misses.
Harder tiers add subtler bypasses and discriminators (number-matched AitM, PRT replay, a second clean trap).
Live arena
4 activeadversary staging…
What this lab is
- A free, browser-based MFA-bypass lab: work a queue of ~18 authored sign-in incidents and, for each, name the bypass that actually happened and pick the control that genuinely stops it.
- Bypasses seeded across the queue: push-fatigue / push bombing, SIM-swap on SMS/voice OTP, fallback-factor downgrade, OAuth token / session-cookie theft, recovery / reset-flow abuse, and adversary-in-the-middle OTP proxy phishing.
- The lesson is matching the control to the technique: number matching kills fatigue but not AitM, only passkeys (FIDO2) kill AitM, token binding — not another MFA prompt — kills a stolen session, and removing SMS kills SIM-swap and downgrades.
- You are graded on catch rate weighed against false positives — flagging a legitimate sign-in (a number-matched push from a compliant device, a fresh passkey ceremony on a new laptop) takes an extra hygiene penalty.
- Three difficulty tiers add subtler bypasses and discriminators — number-matched AitM, Primary Refresh Token replay, help-desk recovery abuse — and after grading every scenario shows why the right call is right.
Frequently asked questions
What is the MFA Bypass Lab?
A free, in-browser exercise where you triage a queue of sign-in incidents. Each has a set of telemetry signals — where the password came from, how many push prompts were sent, whether a number was ported, whether a session cookie was replayed, how recovery was used — and you give it two calls: which MFA bypass actually happened (push-fatigue, SIM-swap, fallback downgrade, token/cookie theft, recovery abuse, or adversary-in-the-middle), or that it is a legitimate sign-in, and then the control that stops it. You are scored on how many real bypasses you identify with the right control versus how many clean logins you wrongly flag.
How is it graded?
Each scenario has one correct technique and one correct mitigation, weighted equally. Your catch rate is the share of real bypasses you name correctly with the right fix. False positives — flagging a healthy, legitimate sign-in — carry an extra hygiene penalty, because an alert queue analysts cannot trust is as useless as one that misses real attacks. A perfect run calls every scenario exactly right on both axes, clean logins included.
Why is picking the mitigation the hard part?
Because controls are technique-specific and easy to mismatch. Number matching defeats blind-tap push fatigue but does nothing against an adversary-in-the-middle proxy, which relays the genuine prompt — only phishing-resistant MFA (FIDO2/passkeys), which binds the assertion to the real origin, stops AitM. Re-prompting MFA will not evict a stolen session token or a replayed Primary Refresh Token; token binding, revocation and continuous access evaluation do. Removing SMS/voice fallback is what actually neutralises SIM-swap and fallback downgrades. The lab makes you match the fix to the mechanism.
Who is it for?
IAM and identity engineers, SOC and incident-response analysts, and anyone prepping for a security interview who wants to feel why MFA still gets bypassed — and why the fix is rarely "add more MFA". It teaches real, current techniques (MFA fatigue, SIM-swap, AitM proxy phishing, token theft, help-desk recovery abuse) and the controls that defeat each one. It runs entirely in your browser — no account, no install, nothing sent anywhere.