When to use this runbook
Trigger conditions:
- User reports an unfamiliar sign-in in their Yahoo activity log
- User received an MFA code they didn't request
- Detection rule fires (see the detection post in this bundle)
- User notices unexpected emails sent from their account, or unexpected configuration changes
- Yahoo step-up auth prompt arrived when the user was not actively signing in (active escalation attempt by an attacker with cookies)
If you're not sure whether this is AiTM versus a password reuse compromise, this runbook still works, the difference matters for the post-mortem but not for the immediate containment.
Phase 1: Confirm
1.1 Check Yahoo sign-in activity
login.yahoo.com/account/activity
Look for:
- Recent sign-in from an IP or country the user doesn't recognize
- Multiple sign-in events within minutes of each other from the same anomalous IP (sign-in + step-up re-auth attempt)
- "Sign-in events" that fired the high-risk-user trap
Note the timestamp of the first anomalous sign-in. That's T0. Everything that happens after is within the attacker's window.
1.2 Quick sanity checks
Open the user's Yahoo Mail. Check:
- Is there a forwarding rule the user didn't create? (Settings → Filters)
- Has the recovery email or phone changed? (Account → Personal Info)
- Are there OAuth app grants the user doesn't recognize? (Account Security → Apps)
If any of these are altered, the attacker successfully escalated past step-up auth, treat it as full ATO. If none are altered, the attacker may have been limited to read-only access (still a serious incident, but different scoping).
1.3 Sent folder audit
Check Sent for messages from T0 onward that the user doesn't recognize composing. The Yahoo step-up auth model leaves outbound composition ungated, so this is where the attacker's BEC pivot would show up. If there's outbound mail in the window:
- Note the recipients (you'll need to notify them)
- Read the messages (they're often wire-instruction-change requests, vendor-invoice-redirects, or password-reset-help asks)
- Treat each recipient as a potential downstream victim
Phase 2: Contain
2.1 Sign out of all sessions
login.yahoo.com/account/security → "Manage sessions" → sign out of all other sessions.
This server-side invalidates the captured Y / T / PH cookies the attacker is using. It is not sufficient to just change the password, because the persistent-session cookies (PH) have a ~1 year expiry and need explicit server-side revocation.
If you skip this step, the attacker keeps access via the existing session even after the password changes.
2.2 Change password
Use a new, strong password (16+ chars, password manager, not reused). This is a separate step from session revocation.
If MFA is enabled, you'll be prompted for it during the password change. If MFA is NOT enabled, do this step first then enroll passkey immediately after (see Phase 4).
2.3 Pull recovery info back if changed
If the attacker changed the recovery email or phone (rare due to step-up auth, but possible), change them back to addresses the user controls.
If the user is locked out because the attacker changed both password AND recovery info, go to Yahoo account recovery: login.yahoo.com/forgot. If self-recovery fails, Yahoo support: 1-800-318-0612 (US). You'll need to verify identity with proof of account ownership.
2.4 Revoke OAuth grants
login.yahoo.com/account/security/oauth-apps
Revoke anything the user doesn't recognize. OAuth grants survive password changes, so if you skip this step the attacker maintains access via the granted app.
2.5 Delete any new forwarding / filter rules
Yahoo Mail → Settings → Filters. Delete anything created in the attacker's window.
Phase 3: Scope (this is where step-up auth changes the playbook)
The standard "Yahoo got compromised" mental model is full account takeover. With step-up auth in the picture, the more accurate model is data exfiltration with a chance of escalation. The mailbox contents are almost certainly gone, the configuration changes may or may not have happened.
This means the scoping priority is:
3.1 Inventory password-reset exposure for OTHER services (highest 2nd-order risk)
The captured Yahoo inbox contained password-reset emails from every service where this account is the recovery channel. The attacker can use those, or trigger fresh resets at the same services, to compromise those accounts.
For each service identified:
- Change the password to a new strong one
- Change the recovery email AWAY from this Yahoo address (use a different secured address)
- Enable MFA on the service if not already
- Review the service's own activity log for unauthorized access in the window
Search the Yahoo inbox for sender patterns like noreply@, security@, account@, with subjects containing reset, password, verify, confirm. Each unique sender represents a service where this Yahoo account is a recovery channel.
3.2 Audit the contact graph for BEC pivot risk
The captured contact list is the attacker's lateral-phishing target list. For high-value counterparties (business contacts on Google Workspace / Microsoft 365, banks, government, legal), reach out and warn them:
- They may receive phishing from the legitimate Yahoo address, or from a lookalike of it
- Specifically warn about wire-transfer-change requests, invoice-redirects, urgent-action emails
- If they've already acted on anything suspicious in the window, they need to engage their own IR
See the post-capture intelligence scoping playbook in this bundle for notification templates.
3.3 Yahoo-internal scope (after the above)
- Confirm no OAuth apps remain that the user doesn't recognize
- Confirm no forwarding / filter rules survived deletion
- Confirm recovery info matches what the user expects
- Confirm sign-in activity since cleanup shows only the user's expected sessions
Phase 4: Prevent (this should not be the same user next month)
4.1 Enroll a passkey
login.yahoo.com/account/security → "Passkey" or "Yahoo Account Key" → enroll.
Passkeys are the only protocol-level fix for AiTM against Yahoo. Once enrolled, a phishing proxy cannot complete the authentication because the authenticator binds to the real Yahoo origin domain, not the lookalike.
Enroll on the user's primary device (phone or laptop). Make sure they have a backup authenticator too (second phone, security key) in case the primary is lost.
4.2 Audit MFA enrollment
If passkey enrollment isn't possible right now (some devices don't support it, or the user can't manage the UX), at minimum confirm MFA is enabled with at least one channel.
Channel quality, best to worst:
- Passkey / WebAuthn (best, protocol-level AiTM-resistant)
- TOTP app (vulnerable to AiTM relay but better than nothing)
- WhatsApp code (vulnerable to AiTM, same as TOTP)
- Email code (vulnerable, and if the attacker has the inbox, useless)
- SMS code (vulnerable AND SIM-swappable)
4.3 Educate the user
The user is not at fault, the auth system has known weaknesses. But it's worth a non-blaming walkthrough:
- What they saw (the lookalike domain, the real-looking form)
- Why their MFA still worked for the attacker
- Why passkey will prevent this in the future
- Why they should be skeptical of urgent-action emails even from familiar senders, for the next 60 days while the attacker may be pivoting
Phase 5: Document
For your internal post-mortem:
- T0 (first anomalous sign-in)
- T-revoke (when sessions were signed out)
- T-password (when password was changed)
- T-passkey (when passkey was enrolled)
- T-notify (when downstream notifications went out)
For any regulated data:
- What was in the mailbox during the window
- Whether any sensitive content was likely read (assume yes if you can't prove no)
- Notification obligations under GDPR / CCPA / HIPAA / GLBA / state law / contractual obligations
For the downstream-notification list:
- Every service where Yahoo was the recovery email
- Every contact who received outbound mail from the account in the window
- Every business counterparty in the captured contact list (high-value subset)
A note on the "is my Yahoo safe now" question
The user will ask this. The honest answer:
t; Your Yahoo account is now secured: the attacker's session is revoked, the password is new, the recovery info is yours, and after passkey enrollment, no AiTM can capture your future sessions. But for the next several weeks, watch for:
t; - Unusual emails or password reset attempts at other services where your Yahoo address was the recovery channel
t; - People in your contacts receiving phishing that looks like it came from you, or from a lookalike of your address
t; - Bank or financial alerts you don't recognize triggering
>
t; The Yahoo account is fine. The downstream blast radius is the part to keep an eye on.
Tooling
This runbook doesn't depend on any tooling beyond Yahoo's own account-management pages, the user's email client, and the user's password manager. There's no Yahoo equivalent of PowerShell-Graph or Sentinel-SOAR, so the runbook stays human-in-the-loop.
If you're running this at scale (many compromises, e.g. an MSP responding to several user reports), the scope-and-notify phase (Step 3) is the most automatable, scripting an inbox-search for password-reset senders, plus a contacts export, plus templated notification email generation, will save the most time.
The containment phase (Step 2) doesn't usefully automate, the user has to be in the loop for password change and passkey enrollment.