How Account Takeover Attacks Work and How to Stop Them

A caller asks a service desk to reset a password and transfer multi-factor authentication (MFA) to a new phone number. Once the desk approves the request, the caller operates as one of your people through a session your own controls approved. That session appears authorized (opens in new tab) to downstream systems, which is what makes the takeover hard to catch.

Every social-engineering (opens in new tab) route into an account gets assembled somewhere you do not operate, and two of those surfaces cannot function without announcing themselves. A lookalike name has to resolve through a new registration (opens in new tab), and a scam support number has to be reachable through the fake sites and profiles (opens in new tab) that promote it.

External providers add a third point of exposure when they issue or restore access on your behalf, and third-party involvement in breaches (opens in new tab) keeps climbing.

This article covers what an account takeover is worth, how one unfolds across five stages, what three recent cases came in through, why login-side defense arrives late, and the four moves that shrink the surface.

Key takeaways

• Prioritize accounts by what they can reach, approve, and reset after an outsider gains a legitimate login.
• Focus controls on the Engagement stage, where attackers manipulate an employee or identity provider during a live exchange.
• Apply your verification standards to the third parties that issue or restore access on your behalf.
• Combine stronger factor recovery, external-surface detection, post-login session review, and rehearsed reset decisions.

An account takeover is measured by what the account can reach

An account takeover (opens in new tab) is an attacker authenticating as one of your people and inheriting that account's permissions, so what follows looks like work. This article follows the takeovers that run through the people and infrastructure around your brand, so credential theft by malware on a managed device and abuse by someone who already holds access (opens in new tab) reach the same outcome by a different route.

What the account can reach decides the price of the compromise.

Approval rights and reset rights decide the severity

A mailbox with no approval rights is a nuisance. Finance approval rights can move money, and IT administrative rights include granting access. A support agent who can reset other people's credentials can create new takeovers.

Each of these accounts is itself an authentication authority, even though the entry usually ran through ordinary credential harvesting (opens in new tab). Severity is a property of the role, so rank a compromised approver above a compromised mailbox.

The takeover outlives the password that started it

A password reset does not touch active sessions or consented applications. A live session can persist (opens in new tab) after a password change, and a consented application can retain access (opens in new tab) after normal password or MFA remediation.

The attacker keeps operating through an artifact the reset did not revoke, and from there the access travels into connected SaaS through island hopping (opens in new tab).

How an account takeover attack unfolds

An account takeover runs the same five stages as any other social engineering campaign. Doppel maps them as the social engineering attack chain (opens in new tab), and the stages below are where attackers build the pieces.

1. Setup: Attackers assemble the pieces off your estate: registrations and certificates that read as your sign-in or your support desk, a number and a profile that answer as your brand, and credentials surfacing from another company's breach (opens in new tab).
2. Launch: The lure goes out across whichever channel reaches your person, whether email, SMS, a search advertisement (opens in new tab), a QR code (opens in new tab), or a call.
3. Contact: The lure arrives somewhere your person will act on it, and the credential capture (opens in new tab) happens on a page built to look like the sign-in they use every day.
4. Engagement: For every path that runs through a person, this is where the takeover is won. A reverse proxy (opens in new tab) relays the one-time code while it is still valid, a support call (opens in new tab) talks a reset through, or a user approves a prompt under push-bombing pressure (opens in new tab). Attackers who replay a credential set (opens in new tab) skip this stage.
5. Compromise: They hold the account and turn it into what they came for: a wire, a data pull, a refund or payout, or a foothold in your next system, often carried on a stolen session token (opens in new tab).

What three recent account takeovers came in through

Three recent cases point the same way: in each, the step that decided the outcome ran through someone you would not operate.

1. Clorox alleges (opens in new tab) in a lawsuit filed July 22, 2025 that on August 11, 2023 an attacker repeatedly called the service desk (opens in new tab) operated by Cognizant, and that the agent reset passwords and MFA for two employees without verifying who was calling (opens in new tab). Clorox claims roughly $380 million in damages, and Cognizant disputes the claims.
2. AdaptHealth told the SEC (opens in new tab) it determined on June 27, 2026 that an incident was material and "was the result of a successful social engineering attack that compromised a user session associated with a third-party contractor."
3. An automated attack (opens in new tab) against Chick-fil-A's website and app between June 17 and June 19, 2026 reused "account credentials (e.g., email addresses and passwords) obtained from a third-party source," exposing the stored credit balance (opens in new tab) on affected accounts among other data. Chick-fil-A notified customers on July 20 and published no global victim total. The login estate was its own; the credentials came from elsewhere.

Third parties do not always secure their own access: fewer than a quarter have fully remediated (opens in new tab) missing or improperly secured MFA on their own cloud accounts.

Why account takeover defense that starts at the login starts late

Your identity platform is doing its job when it checks the factors presented and flags anomalous tokens (opens in new tab). Defense still arrives late for two reasons that sit outside it: sequence and ownership.

Your record of the takeover opens at authentication

Your own first record of the takeover begins at the moment someone signs in. Your mail gateway may log the lure in transit, but everything else in the buildup ran on infrastructure you do not operate.

Two of those pieces still surface on their own: a name has to resolve before anyone can visit it, and the certificate issued to that name gets published to a public log (opens in new tab) where anyone can watch it appear.

Your identity platform does raise those detections for anomalous sessions and stolen session cookies, and they fire at sign-in.

The verification step is often run by someone else

The verification step attackers aim at is frequently run by someone whose policies you do not write. A service desk you contract completes the reset, a contractor holds the session, and a carrier holds the number that receives the code.

Designing that step (opens in new tab) is its own discipline.

Hardening the sign-in moves their target onto enrollment and recovery

Harden the sign-in and attackers move to the paths that transfer or reset a factor. Phishing-resistant authentication (opens in new tab) takes away the relay's credential-capture path, so enrollment and recovery become the target instead.

Device-bound session protections (opens in new tab) cover specific client scenarios today, so check what your own stack covers for browser sessions.

The four moves that shrink your account takeover surface

These four moves strengthen factor recovery, expose lookalike infrastructure, identify post-login abuse, and test reset decisions. Together they reduce how often a takeover succeeds and shorten how long an attacker keeps access, without ending the category.

1. Harden the paths that issue and restore a factor

Enrollment and recovery are where a strong factor gets swapped for a weak one, through MFA re-enrollment, a recovery email or phone standing in as a second factor, or self-service reset. Treat any change to an authentication method as a high-risk action that needs a second, stronger verification before it goes through.

Weigh device-swap indicators (opens in new tab) such as SIM changes or number porting before a one-time code goes to a phone number at all. Password reset fraud (opens in new tab) runs through exactly these paths.

2. Watch the surfaces that give themselves away

Two of these surfaces cannot operate without showing themselves. A lookalike name has to resolve, and its certificate gets logged as it is issued, the signal behind lookalike domain monitoring (opens in new tab): what you act on is the moment a permutation goes active.

A spoofed support number (opens in new tab) has to be reachable to work, so any number that starts answering in your name is part of your authentication path. Exposed credentials are the exception. They do not announce themselves; they get traded, so you watch for the moment a set surfaces outside your walls.

3. Check what a session did after it authenticated

Three post-login signals point to a live compromise: a new authentication method (opens in new tab) added, an unrecognized third-party application granted consent (opens in new tab), and one session identifier showing up from a second address.

When you see them, revoke the active session (opens in new tab) as well as resetting the password, because a relayed session (opens in new tab) keeps working after the credential changes.

4. Rehearse the reset decision with everyone who can approve one

The people who approve a reset or return a callback are making an authentication decision. The rehearsal has to apply the same multi-channel pressure (opens in new tab) a real attempt applies, including the pivot to email or SMS when the first pretext stalls.

Help desk vishing exercises (opens in new tab) recreate that pressure, whoever answers the phone.

How Doppel detects and dismantles account takeover infrastructure

Doppel is the AI-native Social Engineering Defense (opens in new tab) (SED) platform, unifying Digital Risk Protection (opens in new tab) (DRP) with Human Risk Management (opens in new tab). Against account takeover, it works the stage that runs before your identity platform has anything to authenticate.

The Doppel Threat Graph (opens in new tab) correlates one lookalike sign-in page or one spoofed support number into the operator's whole infrastructure (opens in new tab), and agentic takedown acts on that estate while analysts take the complex escalations. Brand Protection (opens in new tab) detects and dismantles it at campaign scale (opens in new tab).

Two populations decide how the human paths hold. Executive Protection (opens in new tab) detects credential and personal-data exposure for prominent individuals, whose approval and reset rights make a takeover worth the most, and extends to the family and data-broker exposure (opens in new tab) attackers build pretexts from.

Simulation (opens in new tab) rehearses the reset decision with everyone who can approve one, including outsourced desks and contractors, through its Helpdesk Mode, so the person a real attacker calls has already taken that call.

Ask who is watching the surfaces an account takeover gets built on

The login is where an account takeover becomes your problem, and the pieces that produced it were assembled on surfaces that had to announce themselves to work. Ask who is watching the registrations and certificates standing up against your brand, and whether that coverage reaches the numbers answering in your name.

Reaching that part of the sequence while it is still being built shortens the next campaign's window before it gets to your login. Request a demo (opens in new tab) to see the infrastructure already mapped in the Doppel Threat Graph.