Hunt Auth

Hunt: Auth Bypass & Account Takeover

Assumes hunt-core for the scope gate, two-account rule, confirmation gate, enumeration limits, stop conditions, wiki protocol, FIND output, and Deadends. Do not re-derive any of that here.

Wiki

qmd_query "authentication bypass account takeover password reset poisoning session fixation legacy protocol" via wiki-search MCP

Hub: [[web-moc]] (live index). Primary page: [[authentication-attacks]]. Payload arsenal: wiki/payloads/{auth-bypass,jwt,oauth-saml,session,mfa-bypass,crypto}.md. Anchors: [[session-management-attacks]], [[mfa-bypass]].

Attack surface (ranked)

Probe in this order; a higher entry is more often unguarded than a cleverer payload on the main form is likely to land.

1. Legacy protocol endpoints (matrix below) - a second door to the same credential store, frequently with no rate limit, MFA, or CAPTCHA. Probe first on any custom/branded login.
2. Password reset flows - host-header poisoning, token in Referer, token reuse/expiry, reset that does not invalidate live sessions.
3. Session and MFA - fixation, missing rotation on privilege change, MFA-optional endpoints, JWT manipulation.
4. Read the login form's fields, not just the endpoint. A login that takes username only, no password field is instant ATO - just submit the privileged/target username (custom auth on a CTF/lab app does this constantly). Same for a "just email"/"just token" form with no secret.
5. Predictable/leaked signing key -> forge as any user. When auth or a "signed message" rests on a per-user key, hunt for a /debug, docs, or /about endpoint (or source) that discloses the key-derivation (deterministic seed like f(username, CONST), nextprime(int(SHA256(seed)))). If the derivation is known, reconstruct the private key offline and forge signatures/sessions/JWTs for admin - no factoring, modulus size irrelevant. Build + oracle-brute steps in [[cryptography-attacks]] ("RSA private key from a known/deterministic seed").

Legacy Protocol Matrix (Probe First on Any Custom-Branded Login)

When a target has a custom/branded login UI, ALWAYS probe the platform's legacy protocol endpoints. These often accept native credentials with NO rate limit, NO MFA, NO CAPTCHA.

How to use:

1. Identify tech stack from headers/paths
2. Probe legacy endpoint anonymously (confirm reachable, not 403/404)
3. Test with synthetic credentials - confirm differential (success vs failure)
4. Verify NO rate limit against a synthetic or your OWN test account (never a real user - every failed attempt counts toward account lockout): send a bounded burst - 5 by default per hunt-core, 20 ceiling with operator approval, 0 under no_bruteforce - and confirm uniform timing, no 429, no lockout counter. The ABSENCE of the limit is the finding; do not actually brute-force to prove it.
5. Confirmed when the endpoint takes native creds with no rate limit / MFA / CAPTCHA (severity below).

JWT Attacks

# 1. Decode JWT
echo "HEADER.PAYLOAD.SIGNATURE" | cut -d. -f2 | base64 -d 2>/dev/null | python3 -m json.tool

# 2. Test none algorithm
# Change "alg":"RS256" -> "alg":"none", remove signature
eyJhbGciOiJub25lIn0.PAYLOAD.

# 3. HS256/RS256 key confusion
# If RS256, try signing with public key as HS256 secret

ATO Attack Paths (Priority Order)

1. Password reset poisoning: POST /forgot-password with X-Forwarded-Host: attacker.com -> reset link sent to attacker
2. Reset token in Referer leak: reset page loads external analytics -> full Referer with token leaked
3. Email change without re-auth: PUT /api/user/email {"new_email": "attacker@evil.com"} without current_password
4. Session fixation: set session cookie before auth -> persists after login
5. IDOR -> ATO chain: PATCH /api/users/{victim_uid} with attacker session -> change victim email -> reset password

Methodology

1. Map all authentication entry points (main, admin, API, partner, mobile)
2. Identify auth mechanism per entry (forms, SAML, OAuth, API key, session)
3. Test legacy endpoints per tech stack (use matrix above)
4. Probe XMLRPC if WordPress: system.listMethods, wp.getUsersBlogs
5. Test JWT if present: none algorithm, key confusion, weak secret
6. Test password reset: host header injection, token in Referer, token reuse after expiry
7. Test email change: no re-auth, no confirmation 7a. On a legacy PHP/MySQL stack (old Apache/PHP banner) with self-registration, try SQL truncation to forge a duplicate of a privileged username (register admin+spaces+junk, log in as admin/yourpass) - see [[authentication-attacks]] "SQL Truncation Duplicate-Account Auth Bypass".
8. Verify impact: demonstrate full ATO on test account B from attacker session A, then clear the confirmation gate below
9. Distill when confirmed (per hunt-core): a reusable legacy-endpoint bypass or JWT variant, GENERIC (no client host): python3 scripts/wiki-stage.py --kind technique --slug <slug> --target-page techniques/web/authentication-attacks.md