What Is Account Takeover: The Full Attack Anatomy

Account takeover (ATO) is an outcome — the moment an attacker authenticates as someone else and the system cannot tell the difference. The path there is a chain of distinct operations, each with its own market, tooling, and failure modes. Most defensive advice collapses that chain into one instruction ("turn on MFA") and then fails in the field because it addressed one link while the attacker walked through another.

This is a working anatomy of how ATO is actually built and executed in 2025–2026, written for people who own the risk: how credentials are acquired, validated, and matured into access; how every common second factor is bypassed; what happens after authentication; and a defence model where each layer maps to a specific attack class rather than a generic checklist.

The kill chain: ATO as a pipeline

Treat ATO as five sequential stages. An attacker does not need to complete all five themselves — each stage has a market, and access can be bought and sold at any point along it.

1. Credential acquisition. Obtaining the raw material: usernames, passwords, session cookies, recovery data. This comes from breach dumps, infostealer logs, phishing, or social engineering.
2. Validation. Testing credentials at scale to find the small fraction that still work. Credential stuffing and account checking tools spray combo lists against login endpoints behind residential proxy networks to evade rate limits and IP reputation controls.
3. MFA bypass. Defeating the second factor on the accounts that validated. This is where the attack succeeds or stalls, and where the technique selected depends entirely on which factor the target uses.
4. Session and token abuse. Converting a successful authentication into durable access — replaying stolen session cookies, holding OAuth access and refresh tokens, registering trusted devices.
5. Exploitation and monetisation. Extracting value: fraud, business email compromise, data exfiltration, lateral movement, or simply reselling the access to someone who will.

The critical insight is that these stages are decoupled. The person who infects a host with an infostealer is rarely the person who commits the fraud. A specialised layer of brokers and markets sits between them. Understanding that supply chain is the difference between defending against ATO and reacting to it.

The credential supply chain

The single most consequential distinction in this space — and the one most articles skip — is between breach dumps and stealer logs.

Breach dumps are static snapshots from a compromised database. When a service is breached, its stored credentials leak — typically hashed, sometimes salted, occasionally in cleartext. A breach dump is a point-in-time record. By the time it circulates widely, a meaningful share of those passwords have been changed, the hashes may resist cracking, and the data ages into irrelevance. Breach dumps still fuel credential stuffing because password reuse is endemic, but they decay.

Stealer logs are different in kind, not degree. They are real-time exfiltrations from an infected host. When an infostealer runs on a victim's machine, it harvests the cleartext password the user is currently using, the live session cookies in the browser, autofill and form data, cryptocurrency wallet files, and a browser and device fingerprint. A stealer log is not a historical snapshot — it is a live capture of an active identity. It frequently contains the session cookies that let an attacker skip authentication entirely. This is why logs from active infostealer families command a premium and why we treat them as the more dangerous half of the supply chain. We unpack the mechanics in our breakdown of how infostealers steal data from infected hosts, and the broader exposure model in stealer logs versus breach dumps.

SpyCloud's 2025 Identity Exposure Report puts scale on this. Its recaptured dataset grew 22% in a year, from 43.7 billion to 53.3 billion distinct identity records. Roughly one in two corporate users were exposed through infostealer malware in the prior year via a personal or corporate device. The report recaptured 7 million stolen third-party application credentials (a 48% year-on-year rise), including 895,802 credentials for enterprise AI tools and 159,313 for password managers — the last category being particularly corrosive, because a compromised password manager unrolls every secret behind it. Around 80% of breaches involved stolen credentials, and 91% of organisations reported an identity-related incident.

Combo lists and enrichment

Raw credentials are refined before use. Operators assemble combo lists — deduplicated email:password pairs aggregated from many sources — then enrich them with open-source intelligence: which services an address is registered with, employer and job title, password patterns across leaks, and recovery phone numbers. Enrichment turns a generic list into a targeting instrument. An attacker who knows an address belongs to a finance director at a specific firm, reuses a recognisable password stem, and has a known carrier for SIM-swap groundwork is holding something far more valuable than a line in a dump. The same dynamic, viewed from the victim's side, is the subject of our analysis of how exposure turns a gamble into a calculation.

Initial Access Brokers

Between acquisition and exploitation sits the broker layer. Initial Access Brokers (IABs) specialise in obtaining and validating access, then selling it to whoever will monetise it — ransomware affiliates, fraud crews, espionage actors. Pricing tiers by what the access yields: a single consumer mailbox is cheap; validated Microsoft 365 access is worth more; domain or tenant administrator access, or access to a financial platform, commands the top of the market. This division of labour is why ransomware groups and large-scale data-extortion crews rarely phish their own way in — they buy. The breach-dump and IAB economy is visible in actor profiles such as ShinyHunters and the credential-theft operation behind the Coinbase Cartel.

Where the material trades

The infrastructure has shifted. Traditional dark-web markets (Russian Market and its peers) still sell stealer logs by the infected host, often bundling all cookies and credentials from one machine as a single "bot." Increasingly, distribution and advertising have moved to Telegram channels, where free samples seed paid subscriptions, and to public paste sites for low-value bulk dumps. Law enforcement pressure on centralised markets has pushed the trade toward this more fragmented, resilient model rather than eliminating it.

The infostealer families that matter

The 2025–2026 infostealer market was reshaped by takedowns and the scramble to absorb displaced demand. The headline figure: infostealer malware stole an estimated 1.8 billion credentials in 2025. Key families:

• LummaC2 — dominant through early 2025. Disrupted by law enforcement in May 2025 (around 2,500 domains seized, administrators later doxxed in August 2025), it recovered within weeks and remains at scale. Exfiltrates browser credentials, cookies, autofill, crypto wallets.
• Vidar — the displacement winner. After Rhadamanthys was taken down in November 2025, Vidar moved into the lead position on Russian Market. Vidar 2.0 (released October 2025) was rewritten from C++ to C for performance, and by January 2026 was the most widely used stealer among threat actors.
• StealC — a consistently active, modular stealer that absorbed share after the Lumma disruption.
• Acreed / ACRStealer — a fast-rising family that ranked among the top stealers by infected hosts in 2025.
• Redline, Raccoon, Meduza — established names that continue to circulate; Meduza is notable for aggressive browser and password-manager targeting.

One technical detail unites them. By mid-2025, StealC, Vidar, and LummaC2 had all implemented bypasses for Google Chrome's application-bound encryption (the control Google introduced to protect cookies and credentials on Windows). The defensive measure was neutralised within months — a recurring pattern worth internalising when assessing any single control.

MFA bypass: the mechanics

This is where generic prevention advice fails. "Turn on MFA" is correct and incomplete — every common second factor has a defeat, and the attacker chooses the technique to match the factor in use. Below are the bypass classes that matter operationally.

SIM swapping

The attacker convinces a mobile carrier to port the victim's number to a SIM they control, then receives the SMS one-time passwords. The prerequisite is reconnaissance: name, address, date of birth, account identifiers, the carrier itself — most of it harvested from people-search platforms and breach data before the attacker ever contacts the carrier. SIM swapping is a social-engineering attack on the carrier, enabled by the victim's prior data exposure. The crews that built reputations on this technique — covered in our profile of Scattered Spider — pair it with help-desk impersonation against the target organisation itself.

SS7 interception

SS7 is the legacy signalling protocol underpinning telephone networks. Actors with access to it — historically through compromised or complicit carriers — can intercept SMS and voice OTPs without ever touching the victim's SIM. It is less common than SIM swapping because it requires network-level access, but it defeats SMS-based MFA cleanly and silently where available.

Real-time phishing proxies (Adversary-in-the-Middle)

AiTM is the most important MFA bypass class against modern accounts because it defeats SMS, TOTP, and push approvals in a single flow. The attacker stands up a reverse proxy between the victim and the real login page. The victim sees a convincing replica, enters credentials and the OTP, and the proxy relays everything to the genuine service in real time. The service authenticates and issues a session cookie — which the proxy captures. The attacker replays that cookie and is inside, holding an authenticated session the second factor was supposed to protect.

Tooling has industrialised this. Open-source frameworks (Evilginx, Modlishka) gave way to phishing-as-a-service platforms. Tycoon 2FA — operated by the actor Microsoft tracks as Storm-1747 — became the leading kit, accounting for roughly 62% of phishing Microsoft blocked by mid-2025 and reaching over 500,000 organisations a month, sold for as little as $120 for ten days' panel access. LabHost was a comparable subscription phishing platform dismantled in 2024. Takedowns disrupt but do not end these operations: a coordinated Microsoft and Europol action against Tycoon 2FA in March 2026 seized around 330 domains, yet operators adapted within weeks, with former affiliates pivoting toward device-code phishing.

OAuth device code phishing

A fast-growing 2024–2026 vector that abuses a legitimate protocol feature. The OAuth 2.0 device authorization grant exists to let input-constrained devices (TVs, CLI tools) sign in: the device shows a short code, the user enters it on a normal browser page on Microsoft's or Google's genuine domain, and the device receives a token. Attackers weaponise this by initiating the device-code flow themselves, then sending the victim a legitimate-looking prompt to enter "their" code on the real, trusted verification page. The victim authenticates against the genuine provider — there is no fake site to detect — and the attacker's waiting application receives a valid access token, often with a long-lived refresh token attached.

Microsoft disclosed the Storm-2372 campaign using this technique in February 2025, attributing it to a Russia-aligned actor. Proofpoint tracked a surge from September 2025 across both financially motivated and state-aligned clusters, and a Cloud Security Alliance research note documented campaigns hitting 340-plus Microsoft 365 organisations. The technique's power is that it survives phishing-resistant credentials on the front end: the victim may authenticate with a passkey, but they are still handing the resulting token to the attacker's device. It defeats user awareness training because nothing about the page is fake.

Push bombing and OTP bots

Push bombing (MFA fatigue) floods the victim with approval prompts until one is accepted — out of confusion, annoyance, or the assumption that it must be legitimate. OTP bots automate the social-engineering call: an automated system phones the victim, impersonates the bank or service, and prompts them to read out the code that just arrived, which the bot relays to the attacker mid-login. Both convert the human into the bypass.

Browser-in-the-Browser and session cookie theft

Browser-in-the-Browser (BitB) renders a fake browser window — complete with a convincing address bar showing the real domain — inside the attacker's page, mimicking an OAuth popup. The victim sees what looks like a genuine "Sign in with Microsoft" window and authenticates into it.

Session cookie theft is the quiet workhorse. Infostealers export the entire browser cookie store; the authenticated session cookies inside let an attacker replay an active session and bypass MFA entirely, because the second factor was already satisfied when the cookie was minted. No login, no prompt, no fatigue attack — just a replayed session. This is the direct bridge from the stealer-log supply chain to ATO, and it is why session security is its own defensive layer.

What survives

One factor class resists nearly all of the above: FIDO2/WebAuthn hardware keys and passkeys. They are phishing-resistant by design because the cryptographic credential is bound to the legitimate site's origin. A passkey simply will not present to a proxy or look-alike domain — the origin does not match, so there is nothing for AiTM to relay. This closes the credential-and-OTP relay path that defeats every other factor. The limitations are real and worth stating plainly: passkeys do not stop a session cookie that has already been stolen from an authenticated browser, and — as device-code phishing shows — they do not stop a user from voluntarily authorising a malicious token grant. Phishing-resistant authentication is necessary, not sufficient.

Post-access exploitation

Authentication is the midpoint, not the finish. What an attacker does next — and how long the damage window stays open — determines the cost.

• Account resale. The simplest outcome: a validated account is sold to an IAB or directly to a buyer, priced by what it unlocks. The original intruder may never act on the access at all.
• Business email compromise. Access to an executive or finance mailbox enables fraudulent payment instructions, invoice redirection, and supplier impersonation — sent from a genuine internal account, which is why these attacks clear so many filters and so much suspicion.
• Lateral movement via OAuth grants. Rather than move host-to-host, cloud attackers consent malicious applications into the tenant and pivot through connected-app permissions. An OAuth grant for mail access can outlive a password reset, because it is a separate authorisation.
• Data exfiltration before reset. Attackers expecting a short window pull mailbox archives, files, and contact graphs immediately, before any detection or credential reset can close the door.
• Ransomware staging. Cloud storage and file-share access provides reconnaissance and a foothold for encryption or extortion — frequently the access an IAB sells to a ransomware affiliate.
• Consumer fraud. On personal accounts: stored-payment fraud, gift-card cash-out, loyalty-point theft, and resale of the credentials themselves.

The hardest problem is the sleeper. Sophisticated actors establish persistence before triggering anything visible — adding a mailbox forwarding rule, registering a trusted device, creating a new OAuth grant, enrolling their own MFA method. They then wait. The visible event (the fraudulent transfer, the data leak) can come weeks after the actual compromise, by which point the original entry point is invisible and the attacker holds multiple independent ways back in. This is why incident response that only resets the password almost always misses the real footholds.

Detection signals

ATO leaves traces — but what you can detect depends on where you are in the chain. The signals below split into what a target experiences directly, what to check actively in account settings, and what organisations can instrument. The split matters: sophisticated attackers disable notifications before acting, so an absence of alerts is not the same as absence of compromise.

What you will notice: personal signals

These are the indicators a victim encounters without any monitoring setup. Each warrants immediate investigation rather than dismissal as a system glitch.

• A login notification you did not trigger. An email or push alert saying "new sign-in on [device] from [location]" when you were not logging in. If the device or location is unfamiliar, treat it as an active compromise. The ASN or city in the alert matters: a sign-in from a residential proxy range or a data-centre IP in a jurisdiction you have no connection to is a near-certain ATO signal.
• An MFA prompt you did not initiate. A push notification, TOTP request, or SMS code arriving when you are not logging in means someone holds your correct password and is at the second-factor gate right now. A single prompt may be a mistake; repeated prompts in a short window is push bombing. Deny and immediately change your password and review active sessions.
• A password reset email you did not request. Someone is either at the "forgot my password" stage with your email address, or — more concerning — already inside and attempting to lock you out. Check for concurrent login notifications.
• A recovery method change notification. A message confirming your phone number, recovery email, or authenticator app has been changed is one of the highest-fidelity signals available: the attacker is establishing persistence and removing your recovery path. Respond in minutes, not hours.
• Your phone loses signal without explanation. An abrupt loss of mobile service — especially if followed shortly by MFA prompts arriving elsewhere — is a strong indicator of a SIM swap in progress. Contact your carrier immediately using a non-SMS channel.
• OTP codes arriving without you logging in. Receiving authentication codes you did not request means someone holds your password and is actively attempting to bypass your second factor. The codes confirm the attack is live at that moment.
• Emails in your Sent folder you did not write. The account has already been accessed. Check what was sent, to whom, and when — attackers typically probe immediately for pending invoices, payment conversations, or supplier threads.
• Contacts reporting unusual messages from your account. If people you know report strange emails, direct messages, or texts from your identity, your outgoing channel is being used — either via account access or a device compromise.
• Unexpected purchases, subscriptions, or transactions. Unauthorised charges on financial accounts connected to the compromised identity, gift-card purchases, loyalty-point redemptions. This is often the first event a victim notices, despite it being the final stage of a multi-step chain that started days earlier.
• You are locked out. The attacker changed your password to hold the account exclusively. This typically follows a period of quiet access during which they changed recovery methods first, making the lockout difficult to reverse.

A critical caveat: attackers who anticipate detection will disable or redirect notification emails before acting. If your notification settings have changed without your input, that change is itself the signal.

What to check in account settings

These require actively looking rather than waiting for a notification. Worth reviewing periodically on high-value accounts, and immediately on any account you suspect has been touched.

• Active sessions and connected devices. Most identity providers and consumer platforms show all live sessions — device type, approximate location, last active time. An unrecognised session, especially an active one, confirms access is or was live. Terminate all sessions if in doubt, not just the suspicious one.
• Email forwarding and filter rules. A forwarding rule silently copies all incoming mail to an external address. A filter rule can delete or archive security alerts before you see them. Both are standard sleeper-persistence moves. Check these even when everything appears normal.
• MFA methods and trusted devices. An unfamiliar authenticator app, phone number, or hardware key enrolled alongside your own gives the attacker a persistent re-entry path that survives a password reset. An unrecognised device in the trusted-devices list means they registered it during their session.
• OAuth-connected applications. Review which third-party apps hold authorised access, particularly any with mail-read or mail-send scopes. A newly authorised app you do not recognise is either a consent phishing result or lateral movement from the session. Revoke it and audit what it accessed.
• Recovery contact and phone number. Verify the recovery email address and phone number are still yours. Attackers target these specifically because controlling them means controlling the reset path back into the account.

Platform and organisational signals

These are available to anyone with SIEM, CASB, or identity-threat detection tooling, and natively in enterprise identity platforms such as Microsoft Entra ID and Okta.

• Impossible travel and velocity. Authentications from geographically incompatible locations within an impossible time window, or bursts of login attempts across many accounts simultaneously.
• New device or fingerprint authenticating and immediately acting. A device that successfully authenticates and then immediately performs a sensitive operation — mail export, file download, payment initiation — is a high-signal indicator. Legitimate new devices tend to explore or configure before acting.
• Mailbox forwarding rule creation. High-fidelity BEC and sleeper indicator. Alert on any creation, especially to external domains, regardless of the account it occurs on.
• New OAuth grant with sensitive scopes. Alert on any consent to mail-read, mail-send, or files-read scopes from an unmanaged or unfamiliar application.
• Credential leak alerts. Notifications from Have I Been Pwned, SpyCloud Monitor, or dark-web monitoring that an address or password has surfaced in a breach or stealer log — leading indicators that a credential is available before it is used.
• Infostealer infection indicators. EDR or AV alerts, browsers unexpectedly clearing saved credentials, or sessions terminating en masse are signs a host's secrets may already be in a stealer log and circulating.

Prevention: a layered model

A flat checklist fails because attackers route around individual controls. The model below is organised so each layer answers a specific attack class from the kill chain. The point is coverage across classes, not the count of measures.

Layer 1 — Credential hygiene (defeats breach-dump stuffing)

Unique passwords per service, generated and held in a password manager, so a single breach dump cannot be reused elsewhere. Check credentials against Have I Been Pwned at registration and login. Subscribe to breach-notification services so exposure is known, not assumed. This layer makes the validation stage uneconomic: stuffing a combo list against accounts with no reuse returns nothing.

Layer 2 — Authentication hardening (defeats credential-only attacks)

MFA, with the strength tiers stated explicitly. SMS and TOTP raise the bar against pure credential theft but are defeated by SIM swap, SS7, AiTM, push bombing, and OTP bots. FIDO2 hardware keys and passkeys are phishing-resistant because they bind to the site origin. "Any MFA is better than none" remains broadly true — it stops the high-volume, low-effort attacks that make up most of the threat — but it has a ceiling, and that ceiling is exactly where a targeted attacker operates. The adoption curve is moving fast: the 2025 HID and FIDO Alliance survey found 87% of enterprises deploying or piloting passkeys (up from 53% two years earlier), with around 5 billion passkeys in active use and nearly half of the top 100 consumer websites offering them. Prioritise passkeys on the highest-value accounts first.

Layer 3 — Session security (defeats post-auth token theft)

This layer answers the stealer-log and AiTM problem that authentication strength alone cannot. Keep session lifetimes short on sensitive applications. Deploy Continuous Access Evaluation (CAE) — the CAEP-based standard that lets the token issuer tell the relying party to stop honouring a token in near real time on a risk signal (password reset, account disablement, detected high risk), closing the window between an event and a token's natural expiry. Microsoft Entra's Universal CAE with Strict Enforcement goes further, blocking a Global Secure Access token if it is replayed from a different IP than the one it was issued to — directly countering stolen-cookie replay. Pair this with Conditional Access policies that require a compliant, managed device: a stolen cookie replayed from an unmanaged attacker machine fails the device check regardless of how valid the token is. Browser isolation for high-risk access removes the local cookie store from reach entirely.

Layer 4 — Exposure reduction (defeats SIM swap, OTP bots, social engineering)

Several MFA bypasses depend on reconnaissance gathered before the attack. Cut off the supply. Remove personal phone numbers and home addresses from people-search platforms, which feed SIM-swap and social-engineering prerequisites. Set a carrier port-freeze or SIM-lock so a number cannot be moved without a separate authorisation. Eliminate SMS and voice MFA on high-value accounts so an intercepted code is worthless. Separate the email identity used for financial and authentication recovery from the one used for daily correspondence, so a compromise of one does not cascade into account recovery on the other. The Lockdown engagement maps and closes exactly that exposure — the data that feeds SIM swap, OTP bots, and social-engineering calls.

Layer 5 — Monitoring and early detection (shortens the damage window)

Identity threat detection tooling to surface the signals in the previous section. Dark-web and stealer-log credential monitoring so a leaked credential or a freshly logged session cookie raises an alert before it is used. SIEM rules tuned to impossible travel, new OAuth grants, forwarding-rule creation, and MFA-method changes. The sleeper problem makes this decisive: the goal is to detect persistence establishment, not just the eventual fraudulent action.

When you are already compromised

If an account is taken over, the order of operations matters — reset the password first and a sophisticated attacker simply walks back in through the footholds you left behind. Work the sequence:

1. Terminate all active sessions before anything else, so existing stolen cookies and tokens die. A password reset alone does not always invalidate live sessions — revoke them explicitly.
2. Reset credentials on the compromised account and any account sharing that password or recovery path.
3. Audit OAuth grants and connected apps and revoke anything unrecognised, especially grants with mail scopes — these survive a password reset.
4. Check for persistence: mailbox forwarding and redirect rules, newly registered trusted devices, attacker-enrolled MFA methods, and new recovery contacts. Remove all of them.
5. Check for lateral movement into connected services, SSO-linked applications, and any account reachable via the compromised mailbox's recovery flows.
6. Notify downstream services that trusted the compromised identity, and assume any data the account could reach was exfiltrated.
7. Determine the entry point. If the cause was an infostealer infection, the host itself is compromised — resetting passwords from the same machine re-exposes them. Clean or rebuild the device before re-establishing trust.

Account takeover is a supply-chain problem wearing the mask of a login problem. The credential was acquired, refined, and brokered through stages most defences never see, and the bypass that defeated the second factor was chosen to match the factor in use. Defending against it means closing exposure across every link — from the data that seeds a SIM swap to the session cookie that needs no login at all. That is the work behind the Lockdown, and the throughline of our credential-leak research.