Otp Bruteforce Testing

OTP Brute-Force Testing

Validate whether an OTP verification endpoint can be brute-forced: unlimited attempts, no lockout, long TTL, weak entropy, or a response oracle that reveals the correct code. Targets must be within the scope of the engagement you are authorized to test.

When to use

• Phone/email verification flows (e.g., "add phone number to profile")
• MFA / 2FA challenge steps and login-by-OTP
• Password reset and account recovery
• Transaction confirmation (payments, withdrawals, admin actions)
• Any endpoint that accepts a 4-8 digit numeric code and returns success/failure

Core attack pattern (reference: HackerOne #3265780, CoinMate.io)

1. Trigger an OTP challenge, submit any code, and intercept the verification request (Burp proxy).
2. Brute-force the OTP space (100000–999999) with Burp Intruder or the bundled script.
3. Detect the valid OTP via a response oracle — in the CoinMate case, the response containing a valid OTP had a Content-Length of 961 bytes vs. ~150 for failures.
4. Replay the original intercepted request with the recovered OTP to complete the operation (the phone number is added to the profile).
5. Chain the impact: attacker-controlled phone number on the account → the number receives login/reset OTPs → account takeover.

Phase 0 — Recon the OTP flow

• Map all OTP-issuing and OTP-verifying endpoints; note parameter names (otp, code, token, verificationCode), length (4/6/8 digits), format.
• Check whether the code is ever returned in responses, logs, or debug headers.
• Check OTP entropy: sequential, timestamp-derived, or weak-PRNG codes have a much smaller candidate space than the nominal digit range.
• Note whether the same OTP is reusable across accounts or across flows (verify vs. reset vs. login).

Phase 1 — Baseline and response-oracle discovery

Send 10–20 wrong OTPs plus 1 valid OTP and diff the responses. Use the script's probe mode to inspect a single attempt:

python3 scripts/otp_bruteforce.py --url https://target/api/verify-phone \
    --method POST \
    --headers '{"Content-Type":"application/json","Cookie":"session=abc"}' \
    --body '{"phone":"+15551234567","otp":"{{OTP}}"}' \
    --probe 123456

Signals to look for:

• Content-Length (e.g., valid = 961 bytes — the CoinMate oracle)
• HTTP status (200 vs 400/403)
• Body markers ("verified": true, new session token, redirect)
• Timing (valid code may take a different code path)
• Set-Cookie / session mutation

If no oracle is obvious, run the full sweep in auto mode: the valid OTP is statistically the outlier bucket among otherwise uniform responses.

Phase 2 — Rate-limit and lockout probing

• Fire 10–30 rapid wrong attempts. If you never see 429/403, CAPTCHA, lockout, or escalating delay, the endpoint is a brute-force candidate.
• Test throttling scope: limits keyed to session/IP only are bypassable via new sessions, IP rotation, or X-Forwarded-For spoofing — retest per account.
• Check lockout semantics: per-account, per-session, or global? Does a lockout also kill the legitimate user (DoS angle)?
• Test OTP TTL and reuse: does a code survive past expiry? Is it single-use? Does resending invalidate the previous code?

Phase 3 — Brute-force automation

Use scripts/otp_bruteforce.py:

# Known oracle: valid responses are 961 bytes (the CoinMate signal)
python3 scripts/otp_bruteforce.py --url https://target/api/verify-phone \
    --method POST \
    --headers '{"Content-Type":"application/json","Cookie":"session=abc"}' \
    --body '{"phone":"+15551234567","otp":"{{OTP}}"}' \
    --oracle-length 961 --threads 10

# No oracle known: auto-detect the outlier response
python3 scripts/otp_bruteforce.py --url https://target/api/verify-phone \
    --method POST \
    --headers '{"Content-Type":"application/json","Cookie":"session=abc"}' \
    --body '{"phone":"+15551234567","otp":"{{OTP}}"}' \
    --range 100000-999999 --threads 20 --delay 0.05

# Route everything through Burp for visibility
python3 scripts/otp_bruteforce.py ... --proxy http://127.0.0.1:8080

Burp Intruder alternative (the original researcher's method):

• Positions: replace the OTP value with §100000§.
• Payload type: Numbers, 100000 to 999999, step 1, min/max fraction digits = 6.
• Resource pool: 10–20 concurrent requests; watch for 429 and slow down.
• Grep-Match on the oracle signal (length column, marker, or status).
• On hit: copy the valid response, replay the original intercepted request with that OTP (Burp Repeater) to complete the action.

Phase 4 — Confirmation and impact chaining

• Confirm the OTP on a fresh replay of the original request — this proves the finding end-to-end (the CoinMate report's Step 4). For single-use code flows, use --confirm-trials 1 since the sweep may have consumed the code.
• Chain impacts and re-score:
  • Phone added to profile → OTP-based password reset → ATO
  • MFA bypass → session hijack on victim accounts
  • Payment confirmation bypass → financial fraud
  • Reset-flow brute force → mass account takeover
• If the flow targets victim accounts (attacker triggers reset on someone else's account), interaction/privilege requirements change the score.

Detection heuristics summary

Reporting

• CWE-307 (Improper Restriction of Excessive Authentication Attempts) is the primary mapping; also consider CWE-640 (weak password recovery) and CWE-287 (improper authentication). Note: platform auto-tags can be off — the CoinMate case was tagged "Insecure Storage of Sensitive Information".
• CVSS 3.1: base ~4.3–6.5 medium (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N). Escalate to 7.5+ high when it directly yields account takeover or bypasses MFA on victim accounts.
• PoC write-up: endpoint, request template, oracle used, candidate space, request rate, time-to-recovery, and the replay confirmation.

Remediation checklist

1. Rate-limit per account + IP (e.g., 5 attempts / 15 min) with CAPTCHA escalation; key limits on the user identifier, not just session/IP.
2. Short OTP TTL (2–5 min), single-use, invalidated on resend.
3. Cryptographically secure RNG for code generation; never sequential or time-derived codes.
4. Server-side attempt counter with lockout; uniform responses so no length/status oracle leaks validity.
5. Monitor and alert on verification-failure bursts; add jitter to error paths.
6. Prefer TOTP/HOTP (RFC 6238/4226) with rate-limited verification windows.

Files

• scripts/otp_bruteforce.py — threaded Python3 brute-forcer with explicit and auto-detect oracles, throttling backoff, confirmation replays, and Burp proxy support.