hunt-mfa-bypass

⚠️ AUTHORIZED USE ONLY This skill is for educational purposes or authorized security assessments only. You must have explicit, written permission from the system owner before using this tool. Misuse of this tool is illegal and strictly prohibited.

Mandatory confirmation gate Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target:

1. Ask the user to state the exact target URL, IP, account, or resource.
2. Ask the user to confirm written authorization and the permitted scope.
3. Show the exact command(s) and explain their expected effect.
4. Wait for explicit confirmation in the current conversation.

Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab.

Autonomous Testing Priority

Try workflow bypasses before brute force — they're faster and more likely to succeed.

Pattern 1 — Skip the MFA step entirely (most automatable):

1. Login with valid credentials → receive a "pre-MFA" session state
2. Without completing MFA, directly access a protected resource (/dashboard, /api/me, /account/profile)
3. If the response returns user data → MFA is enforced only in the UI, not server-side = Critical

Pattern 2 — OTP replay (reuse a consumed code):

1. Complete a valid MFA flow to get a working OTP
2. Log out, log in again with the same credentials
3. Submit the same OTP again
4. If accepted → OTP is not invalidated after use

Pattern 3 — Submit obviously wrong OTP, observe response: Try submitting 000000 or 123456. If the response is 200 or returns a session token, OTP validation is broken or client-side only.

Pattern 4 — Partial / incremental validation (prefix oracle): If a guessed full code is rejected, test whether the server validates the OTP prefix-by-prefix instead of all-or-nothing. Submit a short partial code and compare responses:

1. Submit a 1–3 digit value (e.g. otp=1, then otp=12, …) — for a POST verify endpoint the code goes in the request body, not the URL query string, or the server reads an empty value.
2. If a correct prefix gives a DIFFERENT response than a wrong one (a success/flag, a distinct message, or a different length/timing), the validator leaks correctness one chunk at a time.
3. Walk the code digit-by-digit: keep the prefix that "responds correct," append 0–9, repeat. This collapses 10^6 brute force to ~10×N guesses (≤60 for a 6-digit code) — very feasible in a bounded test. This is the go-to when there is no leaked code and no skip/replay path. Some apps award success on any correct prefix outright (so a single correct first digit can win — sweep otp=0,1,…,9 before giving up). CRITICAL — stay in ONE session: re-authenticating (POST /…/login again) regenerates the OTP, throwing away your prefix progress. Do the entire sweep against a single established MFA session; never re-login between guesses.

On full brute force: brute-forcing all 10^6 codes is infeasible in a bounded test — but the prefix oracle above (Pattern 4) usually makes it unnecessary. Only attempt full brute force with evidence of no rate limit AND a small key space.

Proof: A session token or protected resource data in the response without completing MFA confirms the bypass.

19. MFA / 2FA BYPASS

Growing bug class — 7 distinct patterns. Pays High/Critical when it enables ATO without prior session.

Pattern 1: No Rate Limit on OTP

# Test with ffuf — all 1M 6-digit codes
ffuf -u "https://target.com/api/verify-otp" \
  -X POST -H "Content-Type: application/json" \
  -H "Cookie: session=YOUR_SESSION" \
  -d '{"otp":"FUZZ"}' \
  -w <(seq -w 000000 999999) \
  -fc 400,429 -t 5
# -t 5 (slow down) — aggressive rates get 429 or ban

Pattern 2: OTP Not Invalidated After Use

1. Login → receive OTP "123456" → enter it → success
2. Logout → login again with same credentials
3. Try OTP "123456" again
4. If accepted → OTP never invalidated = ATO (attacker sniffs OTP once, reuses forever)

Pattern 3: Response Manipulation

1. Enter wrong OTP → capture response in Burp
2. Change {"success":false} → {"success":true} (or 401 → 200)
3. Forward → if app proceeds → client-side only MFA check

Pattern 4: Skip MFA Step (Workflow Bypass)

# After entering password, app sets a "pre-mfa" cookie → redirects to /mfa

…