What we found
During live testing of post-capture attacker actions against a real Yahoo account, we discovered Yahoo silently runs step-up authentication on any request that mutates account configuration. A captured session cookie is sufficient to read the mailbox, but not sufficient to change settings.
This is undocumented by Yahoo as far as we can tell. It surfaced because our captured session worked fine for inbox access, then prompted for a fresh password the moment we tried to open Mail Settings.
The matrix of what's gated
With valid Y, T, PH cookies replayed, no further auth, these actions are accessible:
| Action | Surface | Gated? | |---|---|---| | Read inbox / sent / drafts / spam / trash | mail.yahoo.com | no | | Read individual messages including attachments | mail.yahoo.com | no | | Search the mailbox | mail.yahoo.com | no | | Export / read contacts | contacts.yahoo.com | no | | Compose and send outbound mail | mail.yahoo.com | no, this is the gap | | Reply to messages | mail.yahoo.com | no |
The same cookies do NOT grant the following without a fresh password challenge (and depending on the user's MFA enrollment, additional factors):
| Action | Surface | Gated? | |---|---|---| | Open Yahoo Mail Settings | mail.yahoo.com/d/settings | password | | Create / modify a filter (forwarding rule) | Settings → Filters | password | | Change account password | login.yahoo.com/account/security | password + MFA | | Change recovery email | login.yahoo.com/account/personalinfo | password + MFA | | Change recovery phone | login.yahoo.com/account/personalinfo | password + MFA | | Grant OAuth app access | login.yahoo.com/account/security/oauth-apps | password + MFA | | Add an account alias | Account → Personal Info | password + MFA | | View / revoke active sessions | login.yahoo.com/account/activity | password |
Why this matters
A captured Yahoo session is a read token, not a configuration token. The standard AiTM threat model assumes full account takeover, the attacker installs forwarding rules, grants OAuth apps, changes recovery info, and locks the user out. Against Yahoo specifically, none of that happens automatically from cookie capture alone. The attacker has to re-authenticate at login.yahoo.com to install persistence, and at that point the risk engine evaluates the request fresh and may challenge with MFA.
This is a meaningful but partial defense Yahoo provides without telling anyone.
It does not protect against:
- Data exfiltration. The mailbox contents and contact list are the primary loss. Step-up doesn't apply to read.
- Outbound mail composition. This is the gap. The attacker can send phishing or BEC from the legitimate victim address with no challenge, until the user notices.
- Password-reset emails for other services. The Yahoo inbox almost certainly contains password reset emails for non-Yahoo accounts. The attacker reads those, triggers fresh resets at the linked services, compromises those instead.
So the read-only blast radius is still very large. It just stops short of "instant durable persistence in the Yahoo account itself."
How this changes IR
The standard Yahoo-compromise IR playbook is something like:
- Sign out all sessions
- Change password
- Audit OAuth apps, forwarding rules, recovery info
- Re-enroll MFA / passkey
With step-up auth in the picture, that's still correct, but the priority order changes. The 1st-order risk is data exfiltration, and that happened in the first 5 minutes. Steps 1-4 limit future damage but don't undo past damage.
The actual priority should be:
- Inventory password-reset exposure for non-Yahoo services (highest 2nd-order risk)
- Audit the contact graph for BEC / spearphishing pivot risk
- Then the standard Yahoo-internal cleanup (sessions, password, OAuth, forwarding, recovery info)
- Then enroll passkey to prevent future capture
See the IR runbook in this bundle for the full sequence.
How to use this signal in detection
Two detection ideas come out of step-up auth:
Detection 1: unexpected step-up auth prompts. If a user reports "Yahoo asked me for my password while I was just sitting there, not signing in," that's an active intrusion. An attacker with valid captured cookies tried to access Settings / OAuth apps / recovery info, hit the step-up challenge, and either gave up or is trying to social-engineer the password. Out-of-band notification to the user before they re-enter the password is the right move.
Detection 2: re-auth event in the sign-in log within minutes of an unusual sign-in. When the attacker tries to install persistence, they re-authenticate at login.yahoo.com. That re-auth shows up as a separate sign-in event in login.yahoo.com/account/activity. Look for two sign-in events from the same anomalous IP within 5-30 minutes, the first is the AiTM capture, the second is the persistence-escalation attempt.
What Yahoo could improve
The step-up model is good but incomplete. Three product-side improvements would meaningfully tighten the defense:
Extend step-up to outbound message composition. Currently an attacker with a session can send mail from the victim's address with no challenge. A "first message from new IP / new browser fingerprint" challenge would catch BEC pivots before they leave the account.
Extend step-up to bulk read patterns. Rapid full-mailbox pagination plus contacts page access from an anomalous IP is a high-signal exfiltration pattern. A "pause and re-auth after N rapid pageloads" challenge would limit yield.
Surface step-up failures to the user out-of-band. Step-up prompts currently render on the attacker's screen, silently. If the user got a push notification or email saying "someone tried to change your recovery info, was that you?", they'd catch the attacker mid-escalation. Microsoft does this for high-risk sign-ins. Yahoo could do the same.
Caveats
Step-up behavior may vary by account state. Accounts with elevated risk flags may have stricter step-up. Accounts that authenticated recently may have looser step-up (a "session freshness window" of unknown duration during which Settings doesn't re-prompt).
This is based on our test against one account, not a population study. We'd welcome reports from other researchers who can confirm or contradict on their own test accounts.
Yahoo could change this behavior in any release. The mitigation is a side effect of UI architecture, not a contracted security guarantee.
What this is NOT
Step-up authentication is not a substitute for passkey enrollment. Passkeys break AiTM at the protocol level, the cookie capture cannot happen at all. Step-up auth only limits what the attacker does after a successful capture. If you have to choose between explaining step-up to your users and getting them to enroll passkeys, enroll the passkeys.
But step-up is what protects users who haven't enrolled passkeys, from going from "their mailbox got read" to "their account got pivoted into a permanent BEC base." That's a meaningful gap to defend.