Account Takeover Fraud: How Attacks Actually Work — and the Defence Stack That Stops Them

For a bank, fintech, exchange, e-commerce platform or gaming operator, the account is the product — and to an attacker, it is the target. Account takeover (ATO) has become the preferred play in online fraud for one simple reason: a stolen session inherits every ounce of trust your customer has earned. This guide walks through how takeovers actually happen, what attackers do once they are inside, and the layered defence stack — from credential hygiene through to recovery-flow discipline — that stops them without punishing every genuine customer with friction.

Why account takeover is the attacker's favourite

Most fraud controls are built around a simple question: is this person who they claim to be? Account takeover sidesteps the question entirely. Once an attacker is logged in as your customer, they are your customer as far as most of your systems are concerned. The session carries the customer's transaction history, their verified identity, their saved payment methods, their standing limits and their accumulated goodwill. Controls that would challenge a stranger wave through an authenticated session.

That inherited trust is the whole economics of ATO. A fraudster opening a new account faces onboarding checks, identity verification, deposit holds and low starting limits. A fraudster inside a five-year-old account with a clean history faces almost none of that. The account has already done the hard work of looking legitimate — the attacker just harvests it.

ATO also scales. Credential attacks are automated, cheap to run, and indifferent to what sits behind the login: a transaction account, a crypto wallet, a loyalty balance, a stored card at a retailer, a gaming wallet full of withdrawable winnings. Anywhere value or data sits behind a password, the same playbook applies. That is why ATO defence cannot be a single control at the login page — it has to be a stack that assumes some attackers will get through each layer.

The attack chain: how attackers get in

Takeovers rarely begin on your platform. They begin with credentials, and attackers acquire them through a handful of well-worn routes. Understanding each route matters because different routes defeat different controls.

Breach corpuses and credential stuffing

Passwords leak — not usually from you, but from the thousands of other services where your customers reuse the same email-and-password pair. Leaked credentials are compiled into enormous corpuses and traded, then replayed against login pages at scale in automated credential-stuffing attacks. The attacker does not need a high hit rate; when the attempts number in the millions, even a tiny fraction of reused passwords yields a steady stream of valid accounts. From your side, stuffing looks like a wave of failed logins across many unrelated accounts, often from distributed infrastructure designed to evade simple IP blocking.

Infostealer malware

Malware on a customer's own device changes the picture again. Infostealers quietly export whatever the browser holds — saved passwords, autofill data, cookies and session tokens. A stolen session token is especially dangerous because it can allow an attacker to resume an already-authenticated session, bypassing the password and sometimes the multi-factor challenge altogether. Credentials harvested this way are fresh, valid and paired with information about the victim's device, which helps the attacker look more like the real customer.

Real-time phishing and OTP capture

Modern phishing has moved well past crude fake pages. Contemporary kits sit between the victim and your genuine site as a reverse proxy: the victim sees your real pages, enters their real credentials, and receives a real one-time code — all of which pass through the attacker's infrastructure in real time. The attacker completes the login on the genuine site within the code's validity window. This is the crucial point for control design: a one-time code that a human can read and retype is a one-time code that can be phished. Only authentication that is cryptographically bound to the genuine site resists this class of attack.

SIM swap and SMS interception

Where SMS is the second factor, the phone number becomes the target. In a SIM-swap attack, the fraudster convinces or corrupts a telco process into porting the victim's number to a SIM the attacker controls. From that moment, every SMS code and every account-recovery text goes to the attacker. SIM swap is more targeted and higher effort than stuffing, so it is typically reserved for accounts worth the trouble — which is exactly the profile of a bank, exchange or high-balance wallet customer.

Social engineering of the contact centre

Not every takeover comes through the login page. Contact centres exist to help customers who have lost access, and attackers exploit precisely that helpfulness — calling with a plausible story and enough harvested personal detail to pass knowledge-based checks, then having the agent reset credentials, change contact details or lift a block. The stronger your online authentication becomes, the more attractive the human channel gets. Your contact centre is part of your authentication perimeter whether you designed it that way or not.

What attackers do once they are inside

Getting in is only the first half of the play. What happens next follows a recognisable sequence, and each step is a detection opportunity.

• Locking out the owner. Many attackers begin by changing the password, email address or phone number — cutting off the alerts and recovery paths the genuine customer would use to fight back. A contact-detail change immediately after a new-device login is one of the highest-value signals a platform can watch.
• Payee and beneficiary changes. On banking and payment platforms, the attacker adds a new payee or changes an existing beneficiary's details, staging the account for outbound transfers.
• Draining value. The cash-out itself: payments to new payees, withdrawals to new wallet addresses on an exchange, purchases of easily resold goods on e-commerce accounts, or gift-card and stored-value redemption. Speed is typical — attackers know the window between takeover and detection is their whole margin.
• Loyalty and bonus abuse. Points, credits, vouchers and gaming balances are money by another name, often guarded by weaker controls than payments. Loyalty theft is frequently the first sign that a retail or travel platform has an ATO problem.
• Mule staging. Some accounts are more valuable held than drained. A taken-over account with a clean history makes an excellent money mule — a pass-through point for laundering proceeds of other crimes, lending its good reputation to dirty funds.
• Data harvesting. Even an account with nothing to steal contains identity data — name, address, date of birth, partial payment details, transaction history — that feeds the next round of social engineering against the same victim elsewhere.

The lesson for defenders is that the login is not the last line — it is the first. Every action in that post-takeover sequence is visible to you, and most of them are rare in genuine customer behaviour. A platform that only defends the front door forfeits every one of those later chances to catch the intrusion.

The defence stack, layer by layer

Effective ATO defence is a stack of imperfect layers that fail differently. Here is how we structure it when we design account-security programs for banks, fintechs, exchanges and platforms.

Layer 1 — Credential hygiene

Start where the attacks start. Breached-password screening checks new and existing passwords against known-compromised corpuses, at registration, at password change and periodically in between — closing off the reused passwords that credential stuffing feeds on. Rate limiting and progressive slowdowns blunt automated guessing, and bot management distinguishes scripted login traffic from human traffic using network, protocol and behavioural signals. None of this stops a targeted attacker with a valid credential, but it prices the mass-market attack out of your platform — and most ATO is mass-market.

Layer 2 — Authentication design

Be honest about the hierarchy. A password alone is not a defence. SMS one-time codes are better than nothing but are the weakest form of MFA in serious use: real-time phishing relays them, and SIM swap intercepts them. App-based authenticators remove the telco from the loop and are a genuine step up, though codes a human retypes remain phishable. At the top sit phishing-resistant methods — passkeys and hardware security keys — where the credential is cryptographically bound to your genuine domain, so a proxy site simply cannot complete the ceremony. The pragmatic strategy for most platforms is migration, not a cliff: offer passkeys, default new customers onto them, progressively move high-risk and high-value customers up the hierarchy, and apply risk-based step-up so extra verification lands only when the session's risk warrants it.

Layer 3 — Device intelligence and behavioural biometrics

Authentication asks a question at one moment; device and behavioural signals answer it continuously. Device intelligence recognises the devices a customer habitually uses, so a first-time device attempting a login — or, worse, one device touching many accounts — stands out immediately. Behavioural biometrics look at how the user interacts: typing rhythm, navigation habits, the way a form is filled. A fraudster working from a script, a remote-access session or an unfamiliar interface behaves measurably differently from the account's owner, even with perfect credentials. These signals are passive — they add no friction for genuine customers — which makes them the workhorse of low-friction ATO defence.

Layer 4 — Session security

If tokens can be stolen, sessions must not be bearer instruments. Token binding ties a session to attributes of the device and context that issued it, so a cookie exfiltrated by an infostealer fails when replayed from the attacker's machine. Sessions should have sensible lifetimes, and — critically — sensitive actions should demand re-authentication: adding a payee, changing contact details, raising limits, registering a new device. A live session should never be a blank cheque; it should be a licence for routine activity only, with the dangerous actions gated behind a fresh, phishing-resistant challenge.

Detection signals after login

Post-login monitoring is where the stack catches what authentication missed. Individually, the signals are weak; in combination, they are damning. The classic sequence — new device, then new payee, then a transfer at unusual velocity — is rare in genuine behaviour and near-universal in successful takeovers. Other high-value combinations include a login from an unfamiliar network followed by a contact-detail change, password-reset activity followed by immediate value movement, and dormant accounts abruptly waking to transact.

The design principle is to score sequences and combinations, not events. A new device alone is a customer with a new phone. A new payee alone is a customer paying a new tradesperson. Both within an hour of each other, followed by a maximum-value transfer at three in the morning, is something else. Detection logic that reasons over the session — and over the account's own behavioural baseline — outperforms any static rule on a single event, and produces far fewer false alarms for genuine customers.

Recovery flows: the soft underbelly

Here is the uncomfortable symmetry every platform must face: your account-recovery flow is an alternative login that skips the password. Attackers know it, and they routinely attack the recovery path rather than the front door — because the recovery path was designed by a customer-experience team optimising for locked-out customers, not by a security team thinking about adversaries.

Hardening it means accepting some deliberate discipline. Recovery should require evidence of comparable strength to the authentication it replaces — not knowledge-based questions whose answers were harvested in last year's breaches or scraped from social media. Contact-detail changes made through recovery should trigger notification to the old contact points and a delay before the new details can authorise anything sensitive. And the contact centre needs the same rigour: scripted verification that agents cannot be talked out of, no matter how distressed or plausible the caller, escalation paths for requests that touch credentials or contact details, and monitoring for the telltale patterns of social-engineering campaigns — repeated calls about the same account, callers who fail verification and retry, requests that arrive suspiciously soon after a phishing wave. An organisation that spends heavily on passkeys while its call centre resets accounts on a date of birth and an address has not raised its security; it has merely redirected the attackers to the cheaper door.

Customer-facing controls

Customers are not the weak link; unassisted customers are. Equipped properly, they become a detection layer you do not have to build. Real-time alerts for logins from new devices, contact-detail changes and new payees give the genuine owner the chance to raise the alarm inside the attacker's cash-out window. Cooling-off periods for new payees — a deliberate delay, or a reduced limit, before a newly added beneficiary can receive large transfers — directly attack the economics of the drain-and-run sequence. And a kill switch — a prominent, always-available control letting a customer instantly freeze their own account from any channel — turns a suspicious alert into an immediate containment action, without waiting for your operations queue.

These controls carry a friction cost, and the honest way to manage it is transparency and choice: explain what the delay is for, let lower-risk customers tune thresholds within bounds, and never let a fraudster's convenience argument — "remove the delay, I need to pay urgently" — override a protection through an unauthenticated channel.

Building the ATO detection model

Rules catch the patterns you already know; a model finds the ones you do not. A workable ATO detection model draws its features from every layer of the stack: device familiarity and device-to-account relationships, network and location context, behavioural-biometric similarity to the account's own baseline, session actions and their ordering, velocity of value movement, and recovery or contact-change activity. The labels come from confirmed cases — takeovers verified through customer contact, investigations and reimbursement decisions — and label quality matters more than model sophistication; a model trained on unverified suspicions learns your analysts' guesses, not the truth.

The component most programs neglect is the feedback loop. Every confirmed takeover, every false alarm and every customer-reported incident should flow back into training data, feature ideas and rule retirement. Attackers adapt to your controls within weeks; a model retrained on last year's attacks quietly decays into a false sense of security. Build the loop — case outcomes back to the model, model performance back to the fraud team, fraud-team insight back to control design — before you build the second model. This is also where engagement scope matters: a detection model is not a deliverable you accept once, it is an operation you run.

When a takeover succeeds anyway

Some takeovers will succeed. The measure of a mature program is how little a successful takeover is worth to the attacker. The response sequence is:

1. Freeze first. Suspend outbound value movement on the affected account the moment takeover is credibly suspected. A frozen account can be apologised to; drained funds may never come back.
2. Revoke every session and credential. Kill all active sessions and tokens — not just the suspicious one — and force re-enrolment of authentication. Attackers plant persistence: secondary devices, altered contact details, freshly registered authenticators. Sweep them all.
3. Restore the genuine owner through a hardened path. Re-verify the customer through your strongest recovery process, restore their contact details, and walk back every change the attacker made — payees, limits, linked devices.
4. Trace the root cause. Phished? Infected device? SIM swap? Recovery-flow abuse? The answer determines both the advice you give the customer and the control you fix. A takeover with no root cause identified is a takeover that will repeat.
5. Notify and report as required. Where money moved, rapid contact with receiving institutions matters enormously — recovery prospects decay by the hour. Assess privacy and regulatory notification obligations, and feed the case into your confirmed-label set so the detection model learns from it.

Then close the loop at portfolio level: one confirmed takeover usually means others from the same campaign. Hunt for the shared fingerprints — devices, networks, payees, timing — across the rest of your accounts before the campaign finishes its run.

This is the work we do with banks, fintechs, exchanges and platforms: assessing where your account lifecycle is actually exposed, designing the layered defence stack, standing up the detection and response operation, and building the custom account-security software where off-the-shelf tools fall short. See our services and pricing, or talk to a specialist about where your accounts are exposed today.

ATO controls at a glance

The table below summarises the core controls, the attack each one addresses, its main trade-off, and how we typically prioritise it when building or uplifting an account-security program.

Priority is a starting point, not a prescription. The right sequence depends on where your takeovers actually originate, your customer base and channels, and the value sitting behind each account — which is exactly the diagnosis an account-security review is for.