ato-methodology

name	ato-methodology
description	Account Takeover decision tree — 9 canonical ATO paths, chaining patterns (IDOR→ATO, XSS→ATO, OAuth→ATO), MFA bypass entry points.
metadata	{"when_to_use":"ato account takeover hijack chain password reset email change","mitre_attack":"T1078, T1110, T1528, T1539","subdomain":"authentication","upstream_ref":"skills/_corpus/payloads/Account Takeover/"}

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

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