Skip to content

CONCEPT Cited by 1 source

Account takeover (ATO)

Definition

Account takeover (ATO) is an incident in which an attacker gains control of an account belonging to a legitimate user or organisation, typically by combining credential theft (phishing, credential stuffing, session hijack, SIM swap, malware on the user's endpoint) with an immediate rotation of authentication factors so the legitimate owner cannot self-recover. The canonical playbook is:

  1. Acquire the credential. Most commonly via phishing — a reverse-proxy page that captures password + OTP, or a lookalike domain that tricks the user into pasting credentials pulled from a password manager.
  2. Sign in to the real account.
  3. Rotate everything the owner would use to reclaim access: change the email-of-record, revoke sessions/tokens, enrol a fresh 2FA device, remove backup codes.
  4. Use the account for whatever attacker-benefiting purpose (crypto scams, further phishing of the org's followers, brand damage, extortion).

Cf. Fly.io's 2025-10-08 postmortem of the @flydotio ATO:

"The attacker immediately revoked all tokens and set up new 2FA, so while we were quickly able to reset our password, we couldn't lock them out of our account without an intervention from X.com, which took something like 15 hours to set up." (Source: sources/2025-10-08-flyio-kurt-got-got)

The asymmetry is load-bearing: password reset is self-serve, but 2FA reset is platform-gated — once the attacker has rotated 2FA and email, the legitimate owner must route through the platform's human-reviewed recovery channel, which on major platforms takes hours to days.

Detection signals

  • Email-of-record change notification sent to the old email. Fly.io's detection was this: the platform emailed every staff account-email when the attacker set achilles19969@gmail.com as the new email. Detection latency: "we knew 45 seconds after it happened" (Source: sources/2025-10-08-flyio-kurt-got-got).
  • Unexpected login from new location / device.
  • Password-reset or 2FA-setup email the user didn't initiate.
  • Posts / actions from the account the owner didn't make — but this is a late signal and implies the attacker is already using the account.

Response playbook (from the Fly.io post)

  1. Audit the credential store. "Our immediate response was to audit all accesses to the login information in 1Password, to cut all access for anybody who'd recently pulled it; your worst-case assumption in a situation like this is that someone's endpoint has been owned up."
  2. Revoke adjacent access on worst-case assumption. The password is presumed known + the pulling endpoint is presumed compromised. Rotate all credentials the compromised endpoint could touch.
  3. File the platform recovery request. Expect ~10+ hours.
  4. Calibrate response intensity to blast radius — see patterns/incident-response-calibrated-to-blast-radius. Fly.io ran watchful-waiting because: "Our users weren't under attack, and the account wasn't being used to further intercept customer accounts."
  5. Post-recovery: move the account behind phishing-resistant auth. "Our Twitter access is Passkeys now."

Why ATO succeeds

  • Password + OTP is phishable end-to-end via reverse-proxy kits.
  • Training doesn't scale — see concepts/phishing-resistant-authentication.
  • Legacy shared accounts fall outside the org's IdP regime — canonical failure mode in Fly.io's incident (concepts/legacy-shared-account).
  • Platform recovery asymmetry — attackers can rotate factors in seconds; owners need hours-to-days to reverse it.

Why ATO fails (when defences work)

  • Phishing-resistant auth breaks the replay step. The attacker never obtains a reusable credential.
  • SSO-behind-IdP reduces the attack surface to whichever account the IdP covers — and strong IdPs enforce phishing- resistant MFA.
  • Password-manager autofill ([[patterns/password-manager-as- phishing-guardrail]]) defeats some lookalike-domain attacks — but not against a user who copy-pastes manually (exactly how Kurt got phished).

Seen in

  • Fly.io Kurt Got Got (2025-10-08) — canonical wiki instance. Full playbook: phishing → credential pulled from 1Password → sign-in to lookalike members-x.com → attacker rotates 2FA + email → 15-hour recovery window → watchful- waiting response → post-incident move to Passkeys (sources/2025-10-08-flyio-kurt-got-got).
Last updated · 517 distilled / 1,221 read