purpleailab 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/passwordGET /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
| Primary vuln | Chain partner | Outcome |
|---|---|---|
| Open redirect | OAuth redirect_uri allowlist | OAuth code → attacker → ATO |
| XSS (reflected) | session cookie not HttpOnly | Cookie exfil → ATO |
| XSS (stored) | victim views page | Cookie / session-storage exfil → ATO |
| IDOR on email change | reset flow | Change victim's email, reset, login |
| CSRF on password change | predictable URL | Phishing email triggers password change |
| Predictable reset token | weak RNG audit | Generate victim's token offline → reset |
| OAuth state missing | account linking by email | Attacker pre-creates account, links victim's OAuth → ATO |
| JWT alg=none | server accepts | Mint admin JWT → ATO |
| Email change w/o re-auth + ATO of email | full account graph | Standard playbook for multi-tenant SaaS |
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