Home Security Yahoo / AOL AiTM Defense
Research bundle

Yahoo / AOL AiTM Defense

AiTM phishing against Yahoo and AOL Mail. What the attack actually captures (less than you think), what Yahoo silently does right (more than you think), and how to catch the replay when it happens.

5 artifacts Updated May 15, 2026

What this bundle covers

Yahoo and AOL get treated as "old" providers in security writing, the assumption being everyone moved to Google or Microsoft a decade ago. They didn't. Yahoo Mail still has hundreds of millions of monthly active users, and AOL is bundled into the same identity backend. If you do incident response for small businesses, family-run companies, anyone over fifty, anyone in agriculture, real estate, trades, you will see Yahoo accounts in your scope.

This bundle is the result of running the full AiTM attack against Yahoo end-to-end in a controlled research engagement, then walking back through it from the defender side to figure out what's actually worth detecting, what's actually worth mitigating, and what's overstated in the threat models that exist.

Three things surprised us:

  • The replay vector that everyone documents (JavaScript document.cookie injection) does not work. Yahoo's session cookies are mostly httpOnly. The vector that actually works is a browser extension. Detection rules written against the wrong vector miss the attack.
  • Yahoo silently runs step-up authentication on configuration changes. Captured session cookies grant read-only mailbox access. Changing recovery email, creating forwarding rules, granting OAuth apps, all of that requires re-authenticating at login.yahoo.com. The risk engine evaluates the request fresh. This is a partial defense Yahoo doesn't document.
  • Cloudflare in front of an AiTM proxy bypasses Yahoo's own anti-AiTM defense. Yahoo serves React Server Components streamed HTML to real browsers, which breaks naive evilginx-style proxies that buffer responses. CDN-fronted proxies (which is almost all of them, in practice) restore enough streaming semantics that the form renders fine.

The first finding changes how detection rules should be written. The second changes how IR should be scoped (data exfil incident, not ATO incident, in most cases). The third tells you the defense you might have been counting on isn't load-bearing.

Who this is for

  • IR teams who occasionally pull a Yahoo or AOL account into scope and want a current threat model
  • SOC analysts writing detections for session-replay patterns against webmail providers
  • Small-business IT staff whose users still use Yahoo as their primary email
  • Researchers extending the threat model

What's in here

  • Threat model with the three novel findings explained
  • The step-up authentication mitigation analysis
  • Session replay detection patterns (Sigma + Splunk SPL)
  • IR runbook tuned for Yahoo (different from M365 because the controls are different)
  • Post-capture intelligence scoping playbook (because the mailbox dump is almost always done by the time you engage)

Detection rules and the IR runbook are MIT-licensed. The prose is CC-BY-4.0. Adapt freely.

Need help deploying any of this?

Tuning these detections to your tenant, rolling out the Conditional Access policies, designing the IR runbook for your team. We do that work.

Talk to us about an engagement