Account takeover (ATO) is the umbrella term for attacks that result in an attacker gaining unauthorized access to an account belonging to someone else. The attack surface is broader than most users realize — it spans weak credentials, reused passwords, phishable second factors, stolen session tokens, and social engineering of support agents. Each of these represents a distinct attack vector with distinct defenses.
We've covered SIM swapping separately — that's one high-profile ATO vector. This post covers the rest: credential stuffing, adversary-in-the-middle (AiTM) phishing, session hijacking, and MFA fatigue attacks, along with what actually stops them.
Credential Stuffing
When a service is breached and its password database is leaked, the attacker doesn't just gain access to that service. They gain a list of email/password combinations that a subset of users have reused elsewhere. Credential stuffing is the automated process of testing those stolen credentials against other services — banks, email providers, social media platforms — at scale.
Credential stuffing is not brute forcing. The attacker isn't guessing passwords; they're testing known passwords against different targets. The success rate is a direct function of password reuse prevalence. Several large-scale studies of credential stuffing campaigns have found success rates between 0.1% and 2% — low in percentage terms, but a meaningful absolute number when you're testing millions of credential pairs.
Password reuse is the mechanism that turns every third-party data breach into a threat to unrelated accounts. A password manager with unique passwords per service eliminates this attack vector completely. No other mitigation is as effective — credential stuffing simply doesn't work against accounts with unique passwords.
Services defend against credential stuffing with rate limiting, bot detection, and breached password detection (checking submitted passwords against known breach lists). These controls are imperfect. Sophisticated stuffing operations use residential proxy networks to distribute requests and avoid IP-based blocking, and they slow-walk submissions to evade rate limits. The only reliable user-side defense is unique passwords, managed with a password manager.
Adversary-in-the-Middle Phishing
This is the attack that defeats TOTP-based two-factor authentication (time-based one-time passwords, the codes from Google Authenticator or Authy). Understanding why requires understanding what TOTP actually protects against.
TOTP was designed to defend against replay attacks: an attacker who captures your password can't reuse it later because the second factor changes every 30 seconds. It was not designed to defend against real-time interception by an attacker who acts as a proxy between you and the legitimate service.
AiTM phishing works as follows: the attacker sets up a proxy server that mimics the legitimate service's login page. When you visit the phishing page and submit your username, password, and TOTP code, the proxy immediately relays those credentials to the real service and completes authentication on your behalf. The attacker receives a valid authenticated session cookie. The TOTP code is valid for 30 seconds — plenty of time for an automated proxy to use it.
Commercial AiTM phishing kits (Evilginx, Modlishka, Muraena) automate this entirely. The attacker buys or builds the kit, points a convincing domain at it, sends phishing emails, and collects session cookies from victims who complete the "login." From the victim's perspective, nothing looks wrong — the proxy forwards the real site's content faithfully.
TOTP provides meaningful security against credential database leaks and offline attacks. Against a live adversary operating a proxy, it provides essentially no protection. This isn't a flaw in TOTP specifically — it's a property of all shared-secret second factors.
What defeats AiTM: hardware security keys using the FIDO2/WebAuthn protocol. The authentication includes a cryptographic signature over the origin domain — the actual URL the browser connected to. A proxy at evil.example.com cannot produce a valid FIDO2 assertion for bank.example.com. The attacker's AiTM proxy receives an assertion that won't validate on the real service. See our analysis of hardware keys versus authenticator apps for a detailed comparison.
Session Hijacking
After authentication, most web services maintain state via a session cookie — a random token that proves "this browser recently authenticated." Session hijacking is obtaining that token and using it to make requests without re-authenticating.
The vectors for session theft have shifted over time. XSS (cross-site scripting) vulnerabilities that directly read document.cookie are less common on well-maintained sites, partly because HttpOnly cookies prevent JavaScript access. The newer, more prevalent vector is infostealer malware — malicious software installed on the victim's device that reads browser session storage directly from the disk.
Infostealers like Redline, Vidar, and Raccoon Stealer extract session cookies, saved passwords, and browser autofill data from all browsers installed on a machine. The exfiltrated sessions are sold on underground markets and used for ATO. This attack vector bypasses all authentication controls — the attacker has a valid, authenticated session without needing your password or second factor.
Defenses against session hijacking:
- Short session lifetimes — sessions that expire quickly limit the window of usefulness for stolen tokens
- Device binding — some services cryptographically bind sessions to a specific device and invalidate them when the device fingerprint changes
- Re-authentication for sensitive actions — requiring password re-entry for account changes, email updates, or fund transfers limits the damage from a stolen session
- Endpoint protection — preventing the infostealer infection in the first place, through careful software installation and not executing untrusted code
MFA Fatigue Attacks
Push-based MFA (where authentication sends a notification to your phone asking you to approve or deny) introduced a new social engineering vector: just send approval requests repeatedly until the user approves one.
The Uber breach in September 2022 is the canonical example. The attacker obtained Uber employee credentials, then bombarded the target with MFA push notifications late at night. After the employee ignored dozens of notifications, the attacker contacted them on WhatsApp claiming to be Uber IT, saying the notifications would stop if they approved one. The employee approved. This gave the attacker valid access to Uber's internal network.
The attack works by exploiting notification fatigue — users who receive repeated unexpected prompts often approve them to make them stop, especially when paired with social engineering that provides a plausible explanation.
Mitigations: number matching (the push notification shows a number that the user must type to approve, making automated approval impossible), additional context in the push (showing the location and device of the authentication attempt), and limits on how many push requests can be sent before the account is locked.
MFA Method Comparison
| MFA Method | Defeats Credential Stuffing | Defeats AiTM Phishing | Defeats MFA Fatigue | Usability |
|---|---|---|---|---|
| SMS OTP | ✓ | ✗ | ✗ | High |
| TOTP (Authenticator App) | ✓ | ✗ | ✓ | Medium |
| Push notification (basic) | ✓ | ✗ | ✗ | High |
| Push (number matching) | ✓ | ✗ | ✓ | Medium-High |
| FIDO2 / Hardware Key | ✓ | ✓ | ✓ | Medium |
| Passkeys (device-bound) | ✓ | ✓ | ✓ | High |
The Realistic Priority Order
For most accounts, the threat hierarchy runs: credential stuffing (highest volume, lowest sophistication) → TOTP-defeating AiTM phishing (moderate sophistication, automated at scale) → session hijacking via infostealer (requires compromised device) → MFA fatigue (targeted, requires prior credential access).
The corresponding defensive priorities:
- Unique passwords via a password manager — eliminates credential stuffing
- TOTP on any account where phishing risk is low or FIDO2 isn't available
- FIDO2 hardware key or device-bound passkey for high-value accounts (email, financial, work SSO)
- Keep devices clean — endpoint hygiene is the only defense against infostealer session theft
For high-risk individuals — journalists, executives, activists, lawyers with sensitive client data — the standard is FIDO2 everywhere it's supported. Accounts accessible only with a hardware key are resistant to the full range of remote ATO attacks. See our post on passkeys for where the technology is heading.