Why this playbook exists
The standard IR runbook focuses on stopping the attacker. By the time IR engages, the attacker has typically already exfiltrated everything they're going to exfiltrate. The full-mailbox dump completes in 2-5 minutes, IR engagement usually takes hours or days.
This playbook covers the other half of the response: scoping what the attacker certainly took, who's downstream-exposed, and what cascading compromises to prepare for.
What an attacker extracts (yield per capture)
A single 5-minute scrape against a captured Yahoo account in our research produced:
- 45 inbox messages with subject, sender, date, snippet
- Full sent-mail history
- 63 unique correspondent email addresses
- All contact records (name, email, phone where stored)
- All draft messages
- All attachments referenced in messages
- Mailbox metadata (folder labels, filter configuration)
- Calendar events (if enabled)
The attacker does not need to act quickly. Captured Y / T / PH cookies remain valid for months to a year. The exfiltration window is long, but most operators do the full dump in the first few minutes after capture anyway, before the user has any chance to notice.
Step 1: Determine the capture timeline
login.yahoo.com/account/activity
Find the first sign-in event from an IP or location the user doesn't recognize. That's the capture timestamp. Assume everything in the mailbox between account creation and the capture timestamp is in the attacker's hands.
Yahoo Mail retains forever by default. There is no "older than X months wasn't taken" assumption you can make, assume the full archive.
Step 2: Inventory password-reset exposure (highest priority)
The most damaging 2nd-order risk: the captured inbox contains password-reset emails from every other service where this Yahoo account is the recovery channel. The attacker can use those reset links directly (if still valid) or trigger fresh resets at the same services (and intercept the reset emails in real-time during the capture window).
Method A: search the inbox
While the user still has access, search for:
from:noreply OR from:no-reply OR from:account OR from:securitychr(10)subject:"reset" OR subject:"password" OR subject:"verify" OR subject:"confirm"Each unique sender represents a service where this Yahoo account is a password-recovery channel.
Method B: walk the user's password manager
If the user uses a password manager, cross-reference every entry:
- Where the username is this Yahoo address → directly affected
- Where the recovery email is this Yahoo address → directly affected
- Where the username is similar to the user's pattern → likely also affected if they reuse passwords
Method C: use the contacts list as a discovery hint
The 63-address case study we looked at showed banks, government services, ag-tech SaaS, and marketing systems all in the contact list. Each noreply@, notifications@, support@ entry in contacts is a service the user transacts with. Audit each for the same recovery-email exposure.
Required actions per exposed service
For every service identified:
- Change the password (use a new strong one)
- Change the recovery email AWAY from the compromised Yahoo address
- Enable MFA on the service if not already
- Review the service's own activity log for unauthorized access in the capture window
Step 3: Audit the contact graph for BEC / spearphishing risk
The captured contact list is the attacker's target list for lateral phishing. They will:
- Send phishing to contacts FROM the compromised account (high deliverability because of prior-correspondence reputation)
- Send phishing from lookalike domains TO the same contacts
- Use specific message threads as pretexting material (thread-aware spearphishing)
Classify contacts by risk
| Contact type | Lateral risk | Required action | |---|---|---| | Family / personal friends | Low (social phishing) | Notify, brief on the situation | | Business counterparties (Google Workspace / Microsoft 365) | High (BEC) | Notify their security / IT team | | Banks / financial institutions | Critical (direct loss) | Notify fraud line, monitor for fraudulent transactions | | Government / legal | Critical (identity theft) | Notify, file freeze if applicable | | Marketing / mailing lists | Low (spam) | No action needed |
Provider distribution as risk signal
Run an MX-record sweep of the contact list domains. Heavy presence of Google Workspace and Microsoft 365 counterparties means meaningful BEC pivot value. Heavy presence of shared hosting and generic mailservers means lower pivot value, but possibly higher fraud-target value (small businesses get hit by wire fraud more often than enterprise targets).
In the case study: 22 of 63 contacts were on Google or Microsoft 365. That's a substantial BEC pivot surface from a single Yahoo capture.
Step 4: Reconstruct the attacker's read pattern (best-effort)
Yahoo's sign-in activity log shows authentication events but not what the attacker accessed after authenticating. To reconstruct:
- Check the "read" state of messages. If the user has unread messages from before the capture, the attacker likely did not read those. If messages from before the capture appear as read and the user doesn't recall reading them, those are attacker-read.
- Check for sent messages the user did not send (Sent folder audit, see IR runbook)
- Check for any Drafts the user did not create
The reconstruction is approximate. Assume the attacker read everything unless evidence shows otherwise.
Step 5: Quantify the data-disclosure scope
For regulatory and disclosure purposes:
| Question | How to answer | |---|---| | How many distinct correspondents? | Count unique From addresses across all folders | | Date range of compromised email? | Earliest message in the mailbox → capture timestamp | | Sensitive content categories? | Search for medical, financial, legal, HR terms | | PII volume (SSN, DoB, account numbers)? | Pattern-match against PII regexes | | Attachments with sensitive content? | Audit attachments, especially PDFs and spreadsheets |
For business accounts, this scope drives breach-notification obligations.
Step 6: Notify downstream parties
Template, high-value business counterparty
t; Hi [Name],
>
t; On [DATE], my Yahoo account was compromised in a phishing incident. The attacker had access to my email between [START] and [END]. Our recent correspondence may have been read, and the attacker now has your contact information.
>
t; Out of caution: if you receive any unusual email purporting to be from me, especially anything requesting payment, wire transfer, login credentials, or urgent action, please verify by phone before acting. If you've already received and acted on any such message in this window, please contact me immediately.
>
t; I've reset the account password, revoked all sessions, enrolled passkey authentication, and notified Yahoo. I'm sharing this so you can flag your security team if needed.
Template, financial institution
t; [Bank Name] Fraud Department,
>
t; My Yahoo email account, registered with your service as my contact / recovery address, was compromised between [START] and [END]. Please flag my account for elevated review during this period and confirm there have been no unauthorized changes to recovery information, transfer limits, or account configuration.
Template, service where Yahoo was the recovery address
t; Account ID: [...]
t; My recovery email was compromised during the period [START] - [END]. Please verify no password reset, account modification, or login from an unusual location occurred during this window. I'd also like to change the recovery email on file to [new address].
Checklist, what to confirm before closing the incident
- [ ] Yahoo password changed
- [ ] All other sessions signed out
- [ ] Recovery email and phone confirmed (or changed) to current values
- [ ] OAuth apps audited and unknown apps revoked
- [ ] Inbox forwarding / filter rules audited and unknowns removed
- [ ] Sent folder audited for outbound phishing
- [ ] Passkey enrolled
- [ ] Password-reset exposure inventory complete (Step 2)
- [ ] Contact-graph audit complete (Step 3)
- [ ] Downstream notifications sent (Step 6)
- [ ] Regulatory / disclosure obligations assessed (Step 5)
- [ ] Sign-in activity monitored for 30 days post-incident for re-compromise
What this playbook does NOT cover
- Forensic acquisition of the captured session for criminal investigation, requires law enforcement involvement and Yahoo cooperation
- Recovering the phishing lure server for attribution, requires hosting-provider cooperation and ideally a takedown
- Cross-tenant breach impact for business / enterprise accounts, escalate to corporate security
- Legal hold on the mailbox if the breach is subject to litigation, coordinate with counsel
These are out-of-scope here, this playbook is the scoping layer between immediate containment and broader IR coordination.