Identity Threats and Account Takeover

What it is

Identity threats are attacks that target how a user proves who they are and how a system maintains that proof over time. The category includes anything aimed at credentials, MFA, sessions, OAuth grants, federation, or the identity infrastructure itself.

The umbrella term most security teams use is account takeover (ATO), but the techniques underneath have multiplied substantially in recent years. The ones that matter today:

Credential stuffing. Automated login attempts using usernames and passwords from past breaches. The 30 billion-plus records in public breach databases feed continuous stuffing campaigns against every major online service. Even a one-percent success rate produces hundreds of thousands of compromised accounts.

Password spraying. A variant of stuffing that uses a small set of common passwords (Welcome2024, Password123, Spring2025) tried across many usernames. Designed to evade account lockout policies that trigger on multiple failed attempts against a single user.

Session hijacking. Stealing a valid session cookie and replaying it from the attacker's browser. The attacker is logged in without ever entering credentials or completing MFA. Stealer malware has made this attack vector enormous.

MFA bypass through SIM swapping. Convincing the mobile carrier to transfer the victim's phone number to an attacker-controlled SIM. SMS-based MFA codes then arrive at the attacker. Several major incidents (including a series of crypto exchange compromises) have hinged on SIM swaps.

Push fatigue and prompt bombing. Sending repeated MFA push notifications to the victim's phone in the hope that the user eventually approves one to make the prompts stop. The 2022 Uber breach used this technique successfully against a contractor.

AitM phishing. A reverse proxy between the victim and the legitimate login page captures both credentials and session cookies. Push, TOTP, and SMS-based MFA all fall to this. Tools like evilginx, Modlishka, and the Tycoon and EvilProxy phishing-as-a-service kits have made AitM attacks routine.

OAuth consent grant attacks. A phishing email asks the user to grant access to a malicious OAuth application. The user clicks "allow", and the attacker now has API-level access to the user's data without ever knowing the password. The malicious app often has names that mimic legitimate ones ("Microsoft Office Update", "Google Drive Backup").

Downgrade to legacy auth. If the environment still allows legacy authentication protocols (IMAP, POP3, basic-auth Exchange, older SAML profiles), an attacker with a stolen password can authenticate without ever touching MFA. Several breaches have started here.

Federation and token forgery. Compromising a SAML signing key, an OAuth token signing key, or a federation trust lets the attacker forge tokens for any user. The 2023 Storm-0558 incident, where a Chinese state-aligned actor used a stolen Microsoft signing key to forge tokens for any tenant, was the most dramatic recent example.

Adversary-controlled MFA enrollment. An attacker who briefly controls an account enrolls their own MFA device, then uses it for persistent access even after the user changes their password. A common post-phish persistence move.

Why it matters

The shift from network-perimeter attacks to identity-perimeter attacks is the dominant story of the past five years. Several forces drove it.

The network perimeter dissolved. Cloud, SaaS, remote work, and mobile devices made the corporate network a much smaller fraction of where work happens. A firewall does not protect a user logging into Salesforce from a coffee shop.

Authentication became the gate. The login is now the meaningful boundary between the legitimate user and the attacker. Compromise the login, and the firewall is moot.

Stealer malware made session theft cheap. A stealer log purchased for thirty dollars provides credentials, cookies, and session tokens for every service the victim uses. Sessions bypass MFA by design, since the user already authenticated.

Phishing kits commoditised AitM. Tycoon, EvilProxy, Caffeine, and others sell working AitM phishing infrastructure for a few hundred dollars per month. The technical bar for defeating push-based MFA collapsed.

The numbers reflect the shift. The 2024 Verizon DBIR put credential-related causes at the top of breach causes for the seventh consecutive year. The Microsoft Digital Defense Report tracked over a thousand identity-based attacks per second across its tenants. The IBM Cost of a Data Breach study found that breaches involving stolen credentials took on average 292 days to detect and contain, the longest of any cause.

Concrete cases tell the story:

• Snowflake-related breaches (2024). Stealer log credentials, used against Snowflake customer accounts that lacked MFA enforcement, gave attackers access to data at Ticketmaster (560 million customer records), AT&T (110 million), Santander, Advance Auto Parts, and dozens more. The pattern was identical: credentials in stealer logs, no MFA, direct API access.
• Uber (2022). Push fatigue against a contractor, followed by a WhatsApp message claiming to be IT support and asking the contractor to approve the prompt. Hours later, the attacker had control of internal admin tools and had posted screenshots to public channels.
• Microsoft Storm-0558 (2023). A stolen consumer signing key was used to forge enterprise-grade tokens for any tenant. The attackers accessed mailboxes of multiple US government agencies. Microsoft's investigation took months to fully scope.
• Caesars and MGM (2023). Vishing attacks against IT help desks resulted in MFA resets on privileged accounts, leading to ransomware deployment. MGM's losses exceeded $100 million.
• Twitter (July 2020). Vishing of internal employees produced credentials and MFA approvals that gave the attackers access to admin tools controlling every account on the platform.

In each case, no zero-day exploit was needed. The identity layer was the breach.

How attackers exploit it

A typical identity attack chain in 2026 looks like this.

1. Acquire credentials. Either from a breach database, a stealer log, a credential stuffing operation, or a phishing campaign. Stealer logs have become the most common source because they are fresh and include sessions.
2. Validate credentials. Combolists get tested against major services to identify which ones still work. Validated credentials sell at higher prices than unvalidated ones.
3. Bypass MFA. AitM phishing, push fatigue, SIM swapping, or session cookie reuse, depending on the target's MFA configuration. Sessions from stealer logs often skip this step entirely because the user already completed MFA.
4. Establish persistence. Enroll attacker-controlled MFA devices, add forwarding rules to mailboxes, grant OAuth scopes to attacker apps, create new accounts. Persistence often outlasts the initial password change.
5. Move laterally. Target email, then move to SSO, cloud platforms, source code, finance systems, and customer data. The attacker often has weeks before detection.
6. Achieve objective. Data exfiltration, BEC fraud, ransomware deployment, espionage, or sale of access to the next operator in the chain.

Each step has its own tradecraft, its own tools, and its own evasion patterns. The defender's job is to catch the chain at any link, ideally early.

How to detect identity threats

Identity-based detection has matured significantly in the past three years, although coverage remains uneven.

User and Entity Behaviour Analytics (UEBA). Baseline what normal looks like for each user (login locations, devices, hours, applications), then alert on meaningful deviations. The signal is much stronger than rule-based detection but requires months of baselining to tune well.

Impossible travel. A login from London at 9 AM and from Singapore at 9:15 AM cannot be the same person. Modern identity providers ship this detection out of the box. Attackers respond by routing through residential proxies in the victim's country, which reduces effectiveness over time.

Device fingerprinting. A login from a device that has never been seen before, on an account that always uses the same handful of devices, is a high-fidelity signal. Browser fingerprinting, TLS fingerprinting (JA3, JA4), and behavioural biometrics all contribute.

MFA prompt anomalies. A user receiving MFA prompts they did not initiate is one of the most reliable signals that someone has their password. Some MFA platforms now suppress repeated rapid prompts as anti-fatigue logic.

Session token monitoring. Tokens being used from new IP addresses, new browsers, or unusual locations indicate session theft. Continuous validation that re-evaluates session integrity beyond the initial login catches a category of attacks that traditional auth logs miss.

OAuth consent grant monitoring. New OAuth applications granted access by users are reviewable. Suspicious applications (unfamiliar publishers, recent registrations, unusual scopes) warrant investigation.

Stealer log and breach monitoring on the outside. External threat intelligence catches credentials and sessions for the organisation's users in dark web markets, often hours before they are weaponised.

Authentication anomaly correlation. A SIEM or identity threat detection platform that aggregates authentication events from the IdP, every SaaS app, the VPN, and the cloud detects patterns that no single source surfaces.

The challenge with identity detection is that the volume of authentication events is enormous, and the noise floor is high. False positives erode response capacity quickly. Investing in tuning, and in the contextual signals that distinguish real anomalies from benign ones, is what separates effective programmes from alert factories.

How to remediate

When an identity compromise is confirmed:

1. Reset credentials. Force a password change, ideally to a strong unique password, with the previous password added to a deny list to prevent reuse.
2. Invalidate all sessions. A reset that does not also invalidate sessions leaves the attacker logged in. Most identity providers support session revocation across all integrated services.
3. Audit and revoke MFA enrollments. An attacker who briefly controlled the account may have enrolled their own MFA device. Re-enroll the legitimate user from scratch.
4. Audit OAuth grants. Revoke any OAuth applications the user does not recognise.
5. Audit mailbox rules. Forwarding rules, auto-delete rules, and inbox redirection are common attacker persistence mechanisms.
6. Check for created accounts and federation changes. A privileged account compromise often comes with new accounts created or federation modifications. Each is a separate persistence vector that needs cleanup.
7. Investigate the scope. What did the attacker access? What did they exfiltrate? Which other systems are affected?
8. Notify legal, compliance, and affected parties. Disclosure obligations under GDPR, CCPA, and sector-specific regulations have tight timelines (often 72 hours).

For high-value account compromises, the response can extend to rebuilding portions of the environment. Recovery time scales with how much access the account had and how long the attacker had it.

Best practices

• Phishing-resistant MFA on every account that supports it. FIDO2 keys, passkeys, certificate-based authentication. Push-based MFA, TOTP, and SMS all fall to AitM proxies. The cost of upgrading is small compared to the cost of one successful AitM phish.
• Block legacy authentication protocols. IMAP, POP3, basic-auth Exchange, and older SAML profiles bypass MFA entirely. Disable them at the tenant level.
• Enforce conditional access. Login policy that depends on device state, location, and risk score. A login from an unmanaged device should require higher assurance than one from a managed device.
• Limit session lifetimes for sensitive applications. Cloud admin consoles, financial systems, source code repositories should expire sessions in hours, not weeks. Sessions that survive credential rotation are a known problem.
• Continuous validation rather than one-time login. Re-evaluate session integrity on context changes. A session that was valid in a corporate office should not silently continue when the user's IP shifts to a new country.
• Monitor for credentials and sessions externally. Dark web monitoring catches stolen identities before they are used internally.
• Inventory and harden machine identities. Service accounts, API keys, and workload identities outnumber human identities and often have weaker controls. Each one needs an owner, a rotation schedule, and monitoring.
• Restrict OAuth consent. Limit which applications users can grant access to without admin review.
• Train help desks on identity proofing. A help desk that resets MFA based on a phone call is the gap Scattered Spider and similar groups exploit. Identity proofing has to be unspoofable.
• Plan for identity provider compromise. If your IdP gets compromised, what is your recovery plan? Most organisations have not thought this through, and the answers tend to be uncomfortable.

The shift to identity-perimeter security

The implication of all of this is a different model of where defence happens. Network-perimeter security worked when work happened inside a defined network. Identity-perimeter security recognises that the boundary now is the login, the session, and the authorisation decision.

This is not a slogan. It is a practical shift in budget allocation, tooling, and team focus. Organisations that have made the shift are catching attacks faster and remediating them with less impact. Organisations that have not are seeing breaches that traditional controls were never going to stop.

The honest version of the message: identity is where attackers operate now. Defence has to operate there too.