Account security incident examples: one composite scenario

This account security incident example follows one composite scenario from the first warning sign to the final report. It is built from common patterns, not a record of any real person, company, or event. The account holder is the manager of a small shop's business page, and one attacker works through several routes over four days.

The timeline at a glance

Day minus 7: how the attacker got the password

The attack starts before anything looks wrong. An email says the page broke a copyright rule and links to a form. The form looks like the platform's own sign-in screen, but the address is slightly off. The manager enters the page password. A password manager would have declined to fill it there, and a passkey could not have been used on that site.

Nothing happens for a week. The attacker holds a correct password and waits. This gap is why people often miss the first step: by the time the signs appear, the cause is already old. Check the destination of any sign-in page before typing, as described in how phishing messages work.

Day 0, morning: the unrequested code

At 9:10 a.m. the manager gets a text with a six-digit login code. At 9:14 a message arrives from a "platform support" account saying the code was sent by mistake and asking for it to be read back. The manager does not reply.

The code is genuine. It exists because someone has already typed the correct password and the platform is asking for the second factor. A request to read it back is an attempt to finish the login. So the right response is to treat the password as compromised.

Day 0, afternoon: password, sessions and recovery details

The manager opens the platform from its official app, not from a message link, and changes the password. Then comes the step people skip: signing out every other session. Many services keep an existing session active until it is signed out, so a new password alone does not remove an attacker who is already in.

Next the manager checks the recovery options. The page still lists an old work email from a previous job. A reset route attached to an inbox you no longer control is a way back in for anyone who can reach that inbox. The manager removes it and adds a current address, reviewing other accounts for stale contacts, as in lessons from shared logins and staff departures.

Day 1: a post nobody wrote

The next morning the page publishes a promotion nobody on the team wrote. The staff all use strong passwords and a second factor, so the cause is not a password. A scheduling tool was authorized two years ago for a finished campaign by someone who has left. Connected access of this kind can bypass the team's login.

The manager revokes the integration, reviews every other connected app and page role, and sets a date to repeat the check. The social media account security audit gives a repeatable list for this.

Day 3: the phone goes dead

On day three the manager's phone shows no service. Texts stop arriving. The attacker, who has the manager's public details, has asked the carrier to move the number to a new SIM, known as a SIM swap. Any account that sends reset codes by text is now exposed.

The manager calls the carrier from another line and gets the number returned. Then the manager turns on the carrier's protection. The names differ: AT&T calls its feature Wireless Account Lock, Verizon offers SIM Protection and Number Lock, and T-Mobile offers SIM Protection and Port-Out Protection. Menu paths change, so check the carrier's current app.

Next the manager moves the most important accounts away from text codes to an authenticator app or passkeys, using the account security tools guidance. The attacker may also contact a platform support desk using public details such as a birthday, hometown or old handle. Share less publicly and keep stronger ownership proof than an attacker can assemble; the public material involved is described in impersonation scams.

Day 4: recover, then report

By day four the page is clean. The manager runs the platform's hacked-account recovery check to confirm nothing else changed, reviews forwarding rules, connected apps, sessions and anything financial, and tells contacts to ignore messages sent in the past few days.

Then the incident is reported. In the US, the main places are:

The FTC's guidance on recovering a hacked account covers further steps. Report even if nothing was lost, because reports help investigators spot patterns.

Rules that remain after recovery

Restored access is not the end of the response. The timeline points to four durable rules: contain the attempt, close live access, remove unnecessary permissions, and keep recovery options and proof of ownership ready.

Act on an unexplained sign-in alert, mail that stops arriving, contacts reporting a strange message from you, or settings that differ from what you left. The account security risks page lists six warning signs. Any one of them is enough to begin checking the account and its recovery routes.