The detection problem
Most published AiTM detection rules look for one of these patterns:
- JavaScript console paste activity in browser process telemetry
document.cookie =patterns in browser sessions- DevTools open events correlated with session start
- Specific JS strings (Cookie-Editor's signature strings, evilginx's prefill JS)
For Yahoo, most of those miss the actual attack because Yahoo's session cookies are httpOnly. The attacker can't replay them via document.cookie even if they wanted to. The vector that works is a browser extension (Cookie-Editor and equivalents), which uses chrome.cookies.set under the extension API and bypasses the httpOnly JS-context protection entirely.
That means there's no JavaScript trace, no DevTools open, no console paste. The cookies just appear in the browser's cookie store, and the next request to mail.yahoo.com is authenticated.
The detections below are written around server-side indicators (what Yahoo's auth log shows or doesn't show) and session-behavior indicators (what the post-capture session does, since that's the same regardless of how the cookies got there).
Detection 1: cookie present without sign-in event
The cleanest signal: the user's browser hits mail.yahoo.com with valid session cookies, but Yahoo's sign-in activity log shows no corresponding interactive auth event in the last 24h.
If you have direct access to Yahoo's auth log (enterprise, or you can tail the per-user activity page), this is high-fidelity. The replayed session shows up as "authenticated session activity" but the matching "sign-in event" row is missing.
For consumer accounts, the user can audit this themselves at login.yahoo.com/account/activity after the fact. For organizations with Yahoo enterprise tenancy, your SIEM connector should be flagging this automatically.
# Splunk SPL — Yahoo session activity without matching sign-inchr(10)index=yahoo_activity sourcetype=yahoo:sessionchr(10)| stats earliest(_time) as session_start by user, session_id, src_ipchr(10)| join type=left user, session_id [chr(10)search index=yahoo_activity sourcetype=yahoo:signinchr(10)| stats earliest(_time) as signin_time by user, session_idchr(10)]chr(10)| where isnull(signin_time) OR signin_time > session_startchr(10)| eval anomaly="session_active_no_signin"Detection 2: SUSPICIOUS_WITH_IP_PROXY in the sign-in event
Yahoo's risk engine populates secondChallengeReason = SUSPICIOUS_WITH_IP_PROXY on the challenge-selector page when the originating IP looks like a proxy / VPS / unusual ASN. If you can ingest this field from Yahoo's auth telemetry, any sign-in event where it fired is high-confidence AiTM indicator, the attacker's proxy IP triggered it.
Sigma-style detection rule:
title: Yahoo AiTM sign-in anomaly (risk engine flagged)chr(10)id: 7a1b2c3d-4e5f-6789-abcd-ef0123456789chr(10)status: stablechr(10)description: |chr(10)Detects Yahoo / AOL sign-in events where the risk engine populatedchr(10)SUSPICIOUS_WITH_IP_PROXY, indicating the originating IP looks likechr(10)a proxy or VPS. This is a high-confidence AiTM indicator.chr(10)author: LexLab Securitychr(10)date: 2026-05-14chr(10)references:chr(10)- https://lexlabtools.com/security/yahoo-aitm-defense/chr(10)tags:chr(10)- attack.initial_accesschr(10)- attack.t1566.002chr(10)- attack.t1539chr(10)logsource:chr(10)product: yahoochr(10)service: account-activitychr(10)detection:chr(10)selection:chr(10)challenge_reason: 'SUSPICIOUS_WITH_IP_PROXY'chr(10)condition: selectionchr(10)falsepositives:chr(10)- Legitimate users connecting via privacy VPNchr(10)- Users traveling to regions Yahoo's risk engine flagschr(10)level: highFalse positive rate is non-trivial. Users on commercial VPN services trip this regularly. Tune by cross-referencing with the user's typical sign-in geo / ASN history before alerting.
Detection 3: bulk inbox pagination + contacts harvest
Post-capture, the attacker's first action is almost always to scrape the inbox and contact list as fast as possible (the mailbox dump completes in 2-5 minutes). The traffic pattern is distinctive:
- New session opens mail.yahoo.com
- Within 30 seconds, rapid pagination through inbox (
PageDownx 8-15) - Within 60 seconds, navigation to contacts.yahoo.com
- Within 90 seconds, contacts page paginated similarly
- Session may then close, or may pivot to outbound mail composition
If you have visibility into the per-request timing of a user's Yahoo session (corporate proxy logs where Yahoo is allowed, or browser-extension telemetry on managed endpoints), this is a strong signal.
# Splunk SPL — rapid pagination + contacts access in same sessionchr(10)index=proxy host="*.yahoo.com" user=*chr(10)| eval is_contacts=if(match(uri_path, "contacts\.yahoo\.com"), 1, 0)chr(10)| eval is_mail=if(match(uri_path, "mail\.yahoo\.com"), 1, 0)chr(10)| stats min(_time) as session_start max(_time) as session_endchr(10)sum(is_contacts) as contacts_hitschr(10)sum(is_mail) as mail_hitschr(10)dc(uri_path) as unique_pathschr(10)by user, src_ipchr(10)| eval session_duration_seconds=session_end - session_startchr(10)| where contacts_hits > 0 AND mail_hits > 30 AND session_duration_seconds < 300chr(10)| eval anomaly="post_capture_exfiltration_pattern"Tune the mail_hits > 30 threshold to your environment.
Detection 4: step-up re-auth within minutes of unusual sign-in
When the attacker tries to install persistence (forwarding rule, OAuth grant, recovery info change), they hit Yahoo's step-up authentication and have to re-authenticate at login.yahoo.com. That re-auth shows up as a fresh sign-in event in the activity log. Two sign-in events from the same anomalous IP, within 5-30 minutes of each other, is the persistence-escalation pattern.
# Splunk SPL — second sign-in event from same IP within 30 minchr(10)index=yahoo_activity sourcetype=yahoo:signinchr(10)| sort _timechr(10)| streamstats current=f last(_time) as prev_signin_timechr(10)last(src_ip) as prev_src_ipchr(10)by userchr(10)| eval seconds_since_last=_time - prev_signin_timechr(10)| where src_ip == prev_src_ip AND seconds_since_last > 60 AND seconds_since_last < 1800chr(10)| eval anomaly="step_up_escalation_attempt"If the IP also tripped SUSPICIOUS_WITH_IP_PROXY on either event, escalate priority.
Detection 5: outbound mail from unusual IP
Step-up auth does NOT gate outbound mail composition (this is the gap in Yahoo's defense). If the attacker pivots to BEC, the first signal is outbound mail sent from the victim's account but from an IP / browser fingerprint that doesn't match the user's history.
This requires Yahoo Mail outbound-event telemetry, which most defenders don't have direct access to. The proxies for this are:
- The user's own Sent folder, audited after the fact (shows you what was sent)
- Recipient bounce-back patterns (mass-send to address list yields bounces)
- Recipient reports ("did you send me this weird email?")
The post-incident audit of the Sent folder is the most reliable signal. Anything in Sent from the capture window that the user doesn't recognize composing was sent by the attacker.
Implementation notes
These detections work best in layered combination, not as standalone rules:
- Detection 2 (SUSPICIOUS_WITH_IP_PROXY) catches the sign-in
- Detection 3 (bulk pagination) catches the exfiltration
- Detection 4 (step-up re-auth) catches the persistence attempt
- Detection 1 (cookie without sign-in) catches replay from a third location
- Detection 5 (outbound mail audit) catches the BEC pivot
A single capture-and-exfiltrate-only operator may only trip Detection 2 and 3. A persistent operator pivoting to BEC will trip 4 and 5 as well.
Tune the false positive rate down by cross-referencing each detection with the user's historical pattern. Yahoo doesn't ship perfect telemetry for any of these, you may need to instrument the user's endpoint (corporate proxy log, browser extension, or DEM tool) rather than relying on Yahoo's own logging.
For consumer accounts, none of this is automated, the user has to know to check login.yahoo.com/account/activity and audit their Sent folder. That's a user-awareness problem more than a detection-engineering problem.