Containing a fictional email takeover after a password reuse alert case

What to take away

This case is invented. It names no real person, provider, message, breach, or crime.

The alert

Elena gets a password-manager warning: a password she used on an old forum turned up in exposed data. The same password also opens her personal email. Ten minutes later a friend asks why Elena sent an invoice with a payment link nobody recognizes.

She does not assume the forum exposure caused it. Reuse is one plausible path. Phishing, malware, and recovery abuse are others, and the account itself has to say which.

Work from a different device

Elena's laptop was open when the invoice went out, so she stops typing secrets into it. From an updated tablet on her home network she types the provider's address by hand and opens the security page.

She saves several items:

Close the recovery chain

The recovery email comes first, then the password manager. Then the mobile carrier, because that number can receive reset codes. No port request or SIM change shows up, and calls and texts behave normally.

The FTC's personal-information protection guidance lists updates, unique passwords, two-factor authentication, careful handling of phishing messages, and official recovery routes. Elena treats those as a sequence to work through, not as proof of how the account was entered.

Take the account back

Elena can still sign in, so she changes the email password to a generated value used nowhere else. She ends all other sessions, turns on the strongest authentication her provider offers, and stores backup codes off the tablet.

Two things do not belong: an unfamiliar recovery address and a newly created app password. She removes both, plus a mail client she does not recognize, and writes each change into her log.

Then she compares the saved before-and-after settings. Her own recovery phone and security key are still there, the unwanted entries are gone, and the provider confirmed the sign-out. That documents visible account state. It does not prove every server copy or access record is gone.

Google's compromised-account instructions cover several topics:

The forwarding rule that hides the theft

The sent folder holds two invoices. A rule forwards any mail containing payment terms to an outside address, then marks it read. Elena keeps a copy of the rule and deletes it. She checks filters, delegates, blocked senders, and signatures. She also checks vacation replies and connected apps.

Nothing shows a full mailbox export. She also cannot show that no single message was read. The available history cannot answer that, and she writes it that way.

Warn the people who got the mail

Elena calls the two recipients on numbers already in her address book. She says invoice mail from her address during a specific three-hour window was not hers, asks them not to open the file or pay, and leaves a callback number they already know.

One recipient opened the document and entered nothing. Elena points that person to their own organization's device and phishing process. She does not tell them their device is infected, because she cannot know that.

Break the reuse

The password manager flags four more accounts on the old password. Elena changes them from the tablet. She starts with banking, cloud storage, and shopping. Then she reviews sessions, recovery methods, and saved payment details. She also reviews recent activity on each.

No unauthorized transaction appears. She still calls the bank through its official app, because the fake invoice asked for payment in her name and her mailbox holds old statements. The bank logs the report and gives her a case number.

Assess the laptop

Elena takes the laptop off sensitive work and lists installed extensions, recent downloads, and remote-access tools. A trusted scan finds nothing harmful. She drops an extension she no longer uses, updates the browser and operating system, and reviews browser sync.

A clean scan does not explain how the mailbox was entered. The reused password, the unfamiliar session, the changed recovery address, the app password, and the forwarding rule together support account takeover. They do not name a method or a person.

Monitor, then close

For a month Elena checks email security events, forwarding, recovery details, bank activity, and the five accounts that shared the password. Nothing new appears. She keeps the log and a narrow evidence set in an encrypted local record with a deletion date.

She closes the incident once every account has a unique password. Email persistence is gone. Contacts are warned. Devices are assessed. The bank case is filed. Follow-up checks are on the calendar. If a provider stalls on a deletion or access request, the routes and deadlines are set out in personal data incident response problems.

Common questions

Did the forum exposure prove how the mailbox was entered?

No. Password reuse made credential testing plausible, but nothing in the evidence established the method. Treat reuse as a lead and let the account records decide.

Why secure the recovery email before the mailbox?

An unprotected recovery account can reset the mailbox you just locked. Whoever holds the recovery address can undo your work in one request, so it closes first, then the phone number that receives codes.

Did the clean scan rule out the laptop?

No. It removed one concern. It did not show the device never exposed a credential or a live session, which is why the session list and recovery details matter more than the scan result.

Why keep a copy of the forwarding rule?

It is the clearest record of how mail was being diverted, and it supports provider, contact, and bank follow-up. Keep the rule details and the two invoice headers, not the whole mailbox.