For two decades, security teams drew the map the same way: firewalls at the edge, VPNs guarding the tunnel, and a soft interior you protected by keeping outsiders out. That map is obsolete. When your email, code, files, and finance systems live in someone else’s cloud, there is no edge to defend — there is a login page. The credential is the perimeter, and it is under relentless attack.

The numbers make the shift concrete. Verizon’s 2025 Data Breach Investigations Report, drawn from a dataset of 22,052 security incidents and 12,195 confirmed breaches, found that the use of stolen or compromised credentials was the initial access vector in 22% of breaches, phishing was the entry point in 16%, and roughly 60% of breaches involved a human element. Look specifically at web-facing applications and the picture sharpens: 88% of attacks against basic web applications involved stolen credentials. Microsoft, which sits atop a huge slice of the world’s identity traffic, reports blocking identity attacks at massive scale — on the order of hundreds of millions per day.

This is a SOC guide to account takeover (ATO) in that reality. We will walk the attacker’s toolkit and map each technique to MITRE ATT&CK, learn to read the sign-in logs that betray them, hunt the post-compromise signals that turn a stolen session into fraud, and build a response playbook that actually closes the door — because, as you will see, resetting the password often does not.

The ATO Attack Toolkit

Account takeover is not one technique; it is a family. MITRE ATT&CK frames most of it under Valid Accounts (T1078) — adversaries obtaining and abusing existing account credentials to gain initial access, persistence, and privilege while sailing past controls on VPNs and other external services. Here is how they get those credentials.

Credential stuffing (T1110.004)

Attackers replay username/password pairs harvested from prior breaches, betting on password reuse. The bet pays off constantly. The 2025 DBIR’s infostealer analysis found that in the median case only 49% of a user’s passwords across different services were distinct — meaning over half were reused. The same report’s analysis of SSO logs found credential stuffing made up a median 19% of daily authentication attempts. The log signature is a burst of failed logins spread across many accounts from a single IP or ASN, followed by the occasional success.

Password spraying (T1110.003)

The inverse of stuffing: a few very common passwords tried against many usernames, staying under per-account lockout thresholds. The canonical case is Russia’s Midnight Blizzard (NOBELIUM/APT29), which breached Microsoft’s corporate email starting in late November 2023. The technique was deliberately “low and slow” — a password spray against a legacy, non-production test tenant with no MFA, launched from distributed residential proxy infrastructure to evade volume-based detection. Microsoft did not detect it until January 12, 2024. The log signature is one password tried against many usernames from a source, with a high failure rate.

Phishing and adversary-in-the-middle (AiTM)

This is the defining ATO development of the current era, and the one most defenders still get wrong. AiTM proxy kits — open-source Evilginx and commercial phishing-as-a-service kits like Tycoon 2FA, EvilProxy, and Sneaky 2FA — sit as a reverse proxy between the victim and the real identity provider. The victim reaches a pixel-perfect login page, enters their password, and completes MFA (OTP, push, or SMS). Every step succeeds against the real IdP. The proxy simply relays the traffic and pockets the resulting session cookie or token.

The crucial nuance for accuracy: AiTM does not crack or defeat MFA. It lets MFA succeed and steals the proof of authentication afterward. That is why ordinary, non-phishing-resistant MFA is bypassed — and why the fix is structural, not just “turn on MFA.”

This is a mature, industrialized market. Sekoia’s threat research team identified 11 distinct AiTM phishing kits in active commercial operation between January and April 2025, with Tycoon 2FA leading the pack. The scale of the response — Microsoft blocks millions of Tycoon 2FA-linked emails per month — tells you how common this has become.

MFA fatigue / push bombing

When an attacker already has the password but the account requires push approval, they simply spam the victim with approval prompts until, out of annoyance or confusion, the victim taps “Accept.” CISA documents this as “push bombing” or “push fatigue.” The marquee actor is Scattered Spider (UNC3944). The CISA/FBI joint advisory AA23-320A, updated July 29, 2025, documents their combination of push bombing, SIM swapping, and social engineering of IT and help-desk staff to reset passwords and register attacker-controlled MFA devices — then pivoting to compromise the identity provider itself by modifying federation trusts and Conditional Access policies and creating new admin accounts.

OAuth consent phishing (illicit consent grant)

Instead of stealing a password, the attacker registers a malicious application and tricks the user into granting it OAuth permissions — Mail.Read, offline_access, and the like. The consent hands the app persistent, token-backed access to mail, files, and Teams. The detail that matters for response: that access survives a password reset. Midnight Blizzard, after its initial foothold, abused a legacy OAuth application with elevated Exchange access and created new malicious OAuth apps with full_access_as_app to persist inside Microsoft’s environment.

Session and token hijacking (T1550.001)

Stolen session cookies or refresh tokens — from an AiTM kit or an infostealer — are replayed directly to access the account with no authentication event at all. No password prompt, no MFA challenge. MITRE ATT&CK’s Use Alternate Authentication Material: Application Access Token (T1550.001) covers this: adversaries use stolen tokens to bypass the normal authentication process entirely. This is why non-interactive sign-ins with unfamiliar properties deserve special scrutiny.

Proof That Identity Is the Perimeter

The 2024 Snowflake campaign is the cleanest illustration ever produced. Mandiant attributed the theft of data from roughly 165 Snowflake customer tenants — including AT&T, Ticketmaster/Live Nation, Santander, Advance Auto Parts, and Neiman Marcus — to the actor tracked as UNC5537. The root cause combined every theme in this article. The credentials were stolen by infostealer malware (including VIDAR, RISEPRO, REDLINE, RACOON STEALER, LUMMA, and METASTEALER), some dating as far back as 2020. The affected accounts had no MFA configured. So a valid username and password — nothing more — granted access to enormous volumes of customer data. No firewall was breached. No exploit was burned. The identity was the perimeter, and it was undefended. (Suspect Connor Moucka was arrested on October 30, 2024.)

Bookend that cybercrime case with the nation-state example above (Midnight Blizzard: spraying plus legacy auth plus OAuth persistence) and the social-engineering example (Scattered Spider: help-desk manipulation plus push bombing), and you have the full spectrum of adversaries converging on the same target: the login.

The business impact is measured in billions. The FBI’s IC3 2024 Internet Crime Report recorded $16.6 billion in total losses across 859,532 complaints — up 33% from 2023 — with Business Email Compromise (BEC) alone producing roughly $2.77 billion in reported losses. BEC is the downstream monetization of exactly the account takeovers described here.

Reading the Sign-In Logs

Detection lives in the authentication logs — Entra ID sign-in and Identity Protection logs, the Okta System Log, Google Workspace login audit. The good news is that the major platforms have already named most of the detections you need. Your job is to know which named signal maps to which attack, so you can pivot straight to a query.

Microsoft Entra ID Protection exposes risk detections through riskEventType values you can filter and hunt on directly:

Okta’s ThreatInsight provides parallel coverage, detecting and blocking high-volume credential attacks (spraying, stuffing, brute force) against Okta endpoints. A password-spray event is logged when one IP uses the same password across many distinct usernames with attempts failing; the System Log’s outcome.result field records whether ThreatInsight responded with a block or allowed the attempt through. Google Workspace’s login audit exposes the same raw ingredients — IP, geo, device, protocol, success/failure — for you to build equivalent rules.

One structural signal deserves its own line, because it is both a detection surface and the single highest-leverage prevention lever: legacy authentication protocols. Microsoft’s own analysis states that more than 97% of credential stuffing attacks and more than 99% of password spray attacks use legacy authentication (POP, IMAP, SMTP AUTH, older Office clients) — precisely because those protocols cannot prompt for MFA. Any sign-in over legacy auth is both a red flag to alert on and a channel to close.

Post-Compromise and BEC Signals to Hunt

Detecting the login is only half the job. Once an attacker is inside a mailbox, they act to hide, persist, and monetize — and those actions are loud if you are listening.

Inbox rule creation and modification. Monitor Microsoft 365 Exchange audit logs for the New-InboxRule and Set-InboxRule operations, especially rules that auto-delete or forward mail matching keywords like invoice, payment, or security. These rules let an attacker intercept a payment-redirection thread while hiding the security-alert emails that would tip off the victim. Entra/Defender surface related detections as suspiciousInboxForwarding and mcasSuspiciousInboxManipulationRules.

MFA-method registration changes. An attacker who resets access will frequently register their own authenticator so they can return at will. A new MFA method registered from an unfamiliar location, shortly after a risky sign-in, is a strong compromise indicator.

The highest-fidelity chain is an anomalous login (odd geography plus a suspicious token) immediately followed by an inbox-rule creation. Either signal alone can be noisy; the two in sequence is almost always a real compromise. Build your correlation rules around that pairing.

Detection Logic You Can Adapt

Below is platform-agnostic pseudocode for the three volume-and-velocity detections every SOC should run against normalized sign-in logs. Treat thresholds as starting points to tune against your own baseline, and read the caveats afterward.

# Normalized event fields assumed:
#   ts, user, src_ip, src_asn, geo(lat,lon), result (SUCCESS|FAILURE),
#   auth_protocol (modern|legacy), is_known_vpn_egress

# ---------- (A) IMPOSSIBLE TRAVEL ----------
# Two SUCCESSFUL sign-ins for one user whose required travel
# velocity exceeds a plausible ceiling (e.g. 900 km/h ~ commercial flight).
for user in successful_signins.group_by(user):
    for (a, b) in consecutive_pairs(user.events, order_by=ts):
        if a.is_known_vpn_egress or b.is_known_vpn_egress:
            continue                       # suppress corporate VPN false positives
        km   = haversine(a.geo, b.geo)
        hrs  = (b.ts - a.ts) / 3600.0
        if hrs > 0 and (km / hrs) > 900:
            alert("IMPOSSIBLE_TRAVEL", user, a, b, velocity=km/hrs)

# ---------- (B) PASSWORD SPRAY ----------
# One source IP attempting MANY distinct users with a high failure ratio
# inside a rolling window. Sprays stay low PER user but wide ACROSS users.
WINDOW = 60 * 60          # 1 hour
for ip in signins.group_by(src_ip).window(WINDOW):
    distinct_users = count_distinct(ip.events.user)
    fail_ratio     = ip.failures / max(ip.total, 1)
    if distinct_users >= 20 and fail_ratio >= 0.80:
        alert("PASSWORD_SPRAY", src_ip=ip, users=distinct_users,
              fail_ratio=fail_ratio)

# ---------- (C) CREDENTIAL STUFFING / BRUTE FORCE ----------
# N consecutive FAILURES then a SUCCESS for the SAME account from one source.
for (user, ip) in signins.group_by(user, src_ip):
    seq = user_ip.events.order_by(ts)
    fails = 0
    for e in seq:
        if e.result == "FAILURE":
            fails += 1
        elif e.result == "SUCCESS":
            if fails >= 10:
                alert("STUFFING_SUCCESS_AFTER_FAILURES",
                      user=user, src_ip=ip, prior_failures=fails)
            fails = 0

# ---------- Cross-cutting enrichment (raises severity on any hit) ----------
#   auth_protocol == "legacy"            -> +severity (can't do MFA)
#   src_asn in HOSTING_PROVIDER_ASNS     -> +severity (datacenter, not residential)
#   src_ip in ANONYMIZER_LIST            -> +severity (Tor/VPN/proxy)

Tuning caveats. Impossible-travel is the noisiest rule in practice — corporate VPN egress, mobile-carrier CGNAT, and cloud-app connectors routinely trip it, so maintain an allowlist of known egress ranges (the is_known_vpn_egress guard above). Spray thresholds must reflect tenant size; 20 distinct users in an hour is aggressive for a small org and trivially normal for a large one. Give any new baseline a learning-mode period before it pages anyone. And remember that the native platform detections (Entra’s passwordSpray, Okta ThreatInsight) may require specific licensing tiers — your own log-based rules are the portable backstop.

Response and Hardening Playbook

Here is the single most important correction for anyone still running a legacy ATO runbook: a password reset is not enough. Because AiTM/token theft and OAuth consent grants both survive a password change, the attacker’s stolen session or granted app keeps working long after the victim picks a new password. Effective response has a specific order.

  1. Revoke sessions and refresh tokens — first. In Entra, use “Revoke sessions” in the admin center or Revoke-MgUserSignInSession. Enable Continuous Access Evaluation (CAE) so revocation propagates in near real time rather than waiting for token lifetimes to expire — CAE exists specifically to close the gap between a security event and token invalidation.
  2. Revoke malicious OAuth consents. If the intrusion involved an illicit consent grant, remove the app’s consent; otherwise it retains persistent access regardless of password state.
  3. Then reset the password and re-establish clean MFA registration, verifying no attacker-controlled authenticator remains.
  4. Hunt for persistence — inbox rules, forwarding, new app registrations, federation-trust changes — before you close the case.

With the fire out, harden the structure:

Screen Credentials Against Breach Corpora

Prevention closes the loop back to the password itself. NIST SP 800-63B Rev 4 turns breach screening into a hard requirement: verifiers SHALL compare a prospective password against a blocklist of commonly-used, expected, or compromised values — including breach corpuses. The same guideline modernizes the rest of password policy: it forbids composition rules (no more “one uppercase, one symbol”), forbids periodic rotation except on evidence of compromise, mandates rate-limiting of failed attempts, and sets a 15-character minimum for password-only authentication (8 characters when the password is one factor within MFA).

The canonical free corpus is Have I Been Pwned’s Pwned Passwords, and its design is a masterclass in doing this safely. The client hashes the candidate password locally (SHA-1 or NTLM) and sends only the first five hex characters of that hash to the range API. The API returns the suffixes of every known-breached hash sharing that prefix — typically around 800 of them — along with each one’s occurrence count. The client then compares the remaining suffix locally. The plaintext password and its full hash never leave the machine. This k-anonymity model is free, requires no API key, and has no rate limit — which is exactly why it is the right engine for a client-side password checker.

// try it live

Check any password against billions of breached credentials using the same client-side k-anonymity flow described above — the plaintext never leaves your browser.

PASSWORD CHECKER →

Key Takeaways

References

  1. Verizon 2025 Data Breach Investigations Report (PDF)
  2. Additional 2025 DBIR research on credential stuffing — Verizon
  3. Midnight Blizzard: Guidance for responders on nation-state attack — Microsoft
  4. Microsoft Actions Following Attack by Nation State Actor Midnight Blizzard — MSRC
  5. UNC5537 Targets Snowflake Customer Instances for Data Theft and Extortion — Google Cloud/Mandiant
  6. Canadian Suspect Arrested Over Snowflake Customer Breach — The Hacker News
  7. Global analysis of Adversary-in-the-Middle phishing threats — Sekoia
  8. FBI Releases Annual Internet Crime Report (2024 IC3)
  9. 2024 IC3 Annual Report (PDF)
  10. Scattered Spider — CISA/FBI Advisory AA23-320A (updated July 29, 2025)
  11. What are risk detections? — Microsoft Entra ID Protection
  12. Risk detection types and levels — Microsoft Entra ID Protection
  13. Use Alternate Authentication Material: Application Access Token (T1550.001) — MITRE ATT&CK
  14. Block legacy authentication with Conditional Access — Microsoft Entra
  15. Basic Authentication in Exchange Online gone — Microsoft 365 Blog
  16. Updated Exchange Online SMTP AUTH Basic Authentication Deprecation Timeline — Microsoft
  17. NIST SP 800-63B-4 Digital Identity Guidelines (PDF)
  18. Implementing Phishing-Resistant MFA — CISA Fact Sheet (PDF)
  19. Have I Been Pwned: Pwned Passwords / API Documentation
  20. One simple action you can take to prevent 99.9 percent of attacks — Microsoft
« Detection Engineering 101: Writing Detections… The First Hour: A Practical… »