Recovering an account after unauthorised access, in the order that works

Why this matters

Account takeover is now a more common support problem than malware, and it is the one users are least equipped for. There is no machine to fix, the attacker may still be signed in while you work, and the order of operations decides whether you get control back or hand it over again.

This lesson is the domain's capstone because it uses everything in it: the method, the credential work from the security domain, the compromise symptoms, and — at the end — the conversation, which is the part that is hardest to do well and is entirely within a technician's control.

The lesson

Regaining control first: password, then sessions, then recovery methods

Three steps, in this order, and the order is not negotiable.

One: change the password, from a clean device. Not the device that may be compromised. If the user cannot sign in because the attacker changed the password, this becomes the service's account recovery process, which needs the recovery email or phone — and those may also have been changed, which is why recovery is the hardest case and why it is worth attempting immediately rather than after other steps.

Two: sign out every session. This is the step that is skipped and it is the one that matters most. A password change does not end existing sessions on most services, and a stolen session cookie keeps working indefinitely. Nearly every major service offers "sign out everywhere" or a device list; use it, and use it immediately after the password change rather than before, or the attacker's session simply continues.

Three: fix the recovery methods. Recovery email, recovery phone, security questions, backup codes. An attacker who changed any of these can reset the password again whenever they like, which is how accounts are "recovered" three times in a week. Regenerate backup codes, because viewed codes still work.

Then add or verify a second factor, and prefer an authenticator application or a hardware key over SMS for the reasons the security domain gave.

If any step cannot be completed — recovery details already changed, no access at all — go to the service's formal account recovery process early. It is slow, and starting it late makes it slower.

Finding what the attacker changed: rules, forwarding, grants and devices

Once control is back, find what was left behind. These are the places, and none of them is affected by a password change.

• Mail rules. Rules that move, delete or forward messages — especially from banks, finance teams or the service's own security notifications. A rule that deletes security alerts is how a takeover stays invisible.
• Forwarding. Account-level forwarding sends a copy of everything onward indefinitely. Check the account setting and any per-rule forwarding, and check both, because platforms keep them in different places.
• Connected applications and OAuth grants. A third-party application holding a token has continuing access to mail, files or contacts, and neither a password change nor signing out sessions revokes it. Review and revoke.
• Devices and trusted devices. Remove anything unrecognised, and consider removing all of them so every device has to re-authenticate.
• App passwords and legacy access, which bypass multifactor by design.
• Delegation and sharing. Mailbox delegates, shared folders with external addresses, calendar permissions.
• Profile details. A changed display name, signature or reply-to address is used for fraud against the user's own contacts.
• Filters on the recovery mailbox, if it is a different account, for the same reasons.

The sign-in history is the other half: most services show recent activity with times, addresses and rough locations. It tells you when it started, which sets the boundary for everything else — every credential used since, every message sent, every file accessed.

Restoring what was deleted, and the window each service gives you

Deleted data is often recoverable and the windows are shorter than people assume, which makes this urgent rather than optional.

Typical windows:

• Mail — a deleted items folder, then a recoverable items area for a further period, typically around thirty days. Administrators of a business account usually have a longer route.
• Cloud storage — a recycle bin, commonly thirty days, and version history on individual files that allows rolling back an overwrite. Version history is the one people do not know exists and it is frequently the answer.
• Photos — a recently-deleted album, usually thirty to sixty days.
• Business accounts — retention and litigation hold features can preserve far more, and only an administrator can use them.

Act on the shortest window first. If mail was deleted, that is the one with a clock running.

Two specific cases worth knowing:

• A ransom or extortion demand about deleted data is frequently answered entirely by version history and recycle bins, at no cost.
• An attacker who deleted the security alert emails left them in recoverable items, and retrieving them reconstructs the timeline.

And the caution: if this incident might be investigated — a business account, money moved, another organisation's data — do not start deleting or reorganising to tidy up. Preserve first, restore second, and say what you have done. That is the chain-of-custody principle, and this is exactly the situation it exists for.

Working out what was reachable from that account, which is usually more than expected

The last technical step is establishing blast radius, and it is almost always larger than the user's first answer.

Ask what the account could reach:

• Password resets for every other service registered to that address. This is the big one: an email account is a master key, and the list of what it can reset is the list of what is exposed.
• Stored payment methods and any service that can spend money.
• Files, including anything shared with the user by someone else — their data is exposed too, and they may need telling.
• Contacts, which become targets for fraud sent from a real address.
• Single sign-on, where signing in with this account grants access to others.
• Work systems, if the account is a work account or is used for work.
• Historical mail, which is frequently the most sensitive thing of all and is never considered. Years of correspondence, documents, and password reset emails from services the user has forgotten.

The practical method: search the mailbox for "welcome", "verify your email", "your account", and "reset your password", and the results are an inventory of everything registered to that address. It is a sobering exercise and it is the only way to produce a real list.

Then prioritise: money, work, and anything that can reset something else. The rest over the following days.

Telling the user honestly what happened without either alarming or minimising

The conversation determines whether the user reports the next one in an hour or in a fortnight, and it is worth getting right.

What to do:

• Thank them for telling you, first, and mean it. Time is the variable that decides how bad this gets.
• Be factual. "Someone signed in from another country on Tuesday, read your mail, and set up a rule to forward it. I have stopped that and here is what is still to do." Specific, calm, no speculation about who.
• Separate what is known from what is possible. "They could have read anything in the mailbox" is honest. "They definitely have your bank details" is not, unless it is.
• Give them a short list of their own actions, in priority order, written down.
• Tell them what to expect, because follow-on attempts are normal and a user expecting them reports quickly.
• Tell them where to report, and whether you have already escalated.

What not to do:

• Do not blame. They were phished by something professionally made, or their password was in a breach of a company they had no control over.
• Do not minimise. "It is probably nothing" is not reassurance; it is a reason not to do the remaining steps.
• Do not speculate about the attacker, particularly where somebody known to the user might be involved.
• Do not promise it is over. It is over when nothing further happens for a while.

And escalate where the rules require it — a work account, regulated data, money moved, or anyone else's data involved. That is the operational procedures domain's subject, and it is where this course goes next.