What Is Account Takeover (ATO)?

Last verified on Nov 8, 2026.

Account takeover (ATO) is when an attacker gains unauthorized control of a legitimate account. The FBI's IC3 describes it as criminals deliberately gaining unauthorized access to a victim's online account, with the goal of stealing money or information. OWASP adds that once in, attackers exploit the account for identity theft, financial fraud, or other illicit activity.

It differs from a data breach in one respect that matters to logs: the attacker's actions look like the user's. The account, the password, and often the session are all real.

How Accounts Get Taken Over

IC3 lists the common routes: brute forcing weak passwords where there is no multi-factor authentication, phishing emails, phishing websites, social engineering, credentials from past data breaches, and malware on the victim's device.

Two of those are worth separating for defenders:

• Reused credentials. Credential stuffing tests breach data against your login. OWASP lists "account takeover" among its other names.
• Stolen sessions. ATT&CK's Steal Web Session Cookie (T1539) describes taking a session cookie and using it to access a web app as an authenticated user without credentials. Session cookies can bypass some MFA protocols, because the user has already authenticated.

IC3 also notes criminals may socially engineer the one-time passcode when MFA is required, for example by impersonating support staff.

What Takeover Looks Like in Logs

Takeover leaves a sequence, not a single event. A typical one, as illustrative application audit events:

{"ts":"2026-11-08T02:14:11Z","event":"login","outcome":"success","user":"p.nguyen","ip":"203.0.113.50","country":"RO","device":"new"}
{"ts":"2026-11-08T02:15:02Z","event":"mfa_device_added","user":"p.nguyen","ip":"203.0.113.50"}
{"ts":"2026-11-08T02:15:40Z","event":"email_forward_set","user":"p.nguyen","to":"x@example.net"}
{"ts":"2026-11-08T02:16:20Z","event":"password_changed","user":"p.nguyen","ip":"203.0.113.50"}
{"ts":"2026-11-08T02:17:05Z","event":"data_export","user":"p.nguyen","rows":48211}

Read it as a chain: a login from a new country and device, then immediately changes that lock the owner out or keep access, then the action the attacker came for.

The middle events are the ones to watch. ATT&CK's Account Manipulation lists what attackers add to keep access: additional cloud credentials, email delegate permissions, SSH authorized keys, registered devices, and additional cloud roles. A sensitive account change shortly after a login from an unfamiliar place is a stronger signal than the login itself.

Useful fields to log: user, source IP, device or user agent, auth method, outcome, and every credential or contact change. Then ask:

1. Did a success follow a burst of failures from the same source?
2. Is this device, network, or country new for this user?
3. Did credentials, MFA devices, forwarding rules, or keys change within minutes of the login?
4. Did the same session cookie appear from two networks?

The login-side queries are in authentication anomalies, and fraud outcomes such as card testing and promo abuse are in abuse and fraud. For the access pattern after takeover, see access anomalies. Once you suspect one account, follow investigating an account takeover.

Prevention and Containment

OWASP names multi-factor authentication by far the best defense against most password-related attacks, and describes combining it with other techniques so a second factor is requested only in suspicious cases, such as a new device, an unusual location, or an address that has tried several accounts. It also suggests step-up authentication before high-risk actions such as privileged configuration changes.

OWASP's account takeover guidance also lists strong, unique passwords and awareness of phishing. Pair these with controls for the cases MFA does not cover: short session lifetimes, re-authentication before changing credentials, and alerts to the user when a new device or forwarding rule appears.

To contain a taken-over account, end its sessions first, then reset its credentials, then look for the persistence items above. Resetting the password alone leaves an added key or device in place. If privileges changed, treat it as privilege escalation, and if the account touched other systems, check for lateral movement. If data left, see data exfiltration.

Logs in Sazabi

Sazabi, an AI-native observability and security platform, can receive the Okta System Log, which covers sign-ins, MFA changes, and admin actions, so those events can be searched alongside your other logs.