Account Takeover (ATO) Methodology

ATO is an outcome, not a vuln class. Reach it via 9 canonical paths.

1. Password reset flaws

• Token in URL leaked to Referer (3rd-party CDN, analytics)
• Token guessable (timestamp + user_id, sequential int, predictable RNG)
• Token-no-expiry → reuse forever
• Reset accepts arbitrary email param (mass-assignment style)
• Token not invalidated after password change
• "Forgot username" flows revealing existence

2. Email change without re-auth

POST /api/users/me/email {email: ...} without verifying current password. Or with verification but verification token leaks.

3. Session fixation

Server accepts attacker-set session cookie. Victim's actions bind to attacker's session.

4. JWT-based ATO

See skills/exploit/web/jwt/SKILL.md — alg confusion, weak secret, kid injection.

5. OAuth-based ATO

See skills/exploit/web/oauth/SKILL.md — redirect_uri bypass + open-redirect chain → code to attacker.

6. IDOR-based ATO

• PATCH /api/users/<id> w/o auth check → change victim's email/password
• GET /api/users/<id>/sessions → harvest victim's session tokens

7. XSS-based ATO

Stored XSS on victim-visible page → exfil cookie / session token to attacker.

8. CSRF on critical state

• CSRF on password change endpoint (no anti-CSRF token)
• CSRF on email change
• CSRF on MFA disable

9. MFA bypass

• TOTP code accepted multiple times w/ short delay (race)
• TOTP code accepted from past N-step (clock skew abuse)
• Backup-code flow doesn't enforce TOTP
• "Trust this device" w/o re-auth on critical action
• Account recovery bypasses MFA entirely
• Phone-number takeover (SIM swap) → SMS 2FA hijack

Chain table

Decision tree

Has user MFA enabled?
├── No → Standard password-reset attacks (paths 1-3, 6, 8)
└── Yes →
    Bypass MFA available?
    ├── Yes (path 9) → MFA bypass → standard reset
    └── No → Look for paths 5, 7 (OAuth, XSS) that bypass MFA by design
              OR path 4 (JWT) that doesn't touch the MFA flow
              OR account-linking via OAuth (path 5) which often skips MFA

PoC framing

Every ATO PoC should:

• Attacker creates own account
• Demonstrate victim's account is fully controllable (login as victim, change their email, post as them)
• Capture video or step-by-step screenshots
• Show no destructive action taken on victim's actual data — just proof of access

Severity

ATO is always Critical (9.8-10.0) when fully achieved. Severity downgrade only when:

• Requires user interaction (click malicious link) — High 8-9 typically
• Requires multiple vulns to chain — capture the chain in single report
• Limited to specific user types — caveat in impact

Cross-references

• Upstream: skills/_corpus/payloads/Account Takeover/
• JWT: skills/exploit/web/jwt/SKILL.md
• OAuth: skills/exploit/web/oauth/SKILL.md
• IDOR: skills/analyst/idor.md
• XSS: skills/exploit/web/xss.md
• Open redirect: skills/exploit/web/open-redirect/SKILL.md