After a removal: credentials, tokens, and the trust that does not come back by itself

Why this matters

The removal procedure ends with a clean machine, and a clean machine is only half the problem. Everything the infection could read while it was running — passwords typed, sessions open, tokens stored, cookies saved — may now be somewhere else, and none of it is affected by cleaning the disk.

This is the part most commonly missed, and it is where the real damage happens. Accounts are taken over days or weeks after the machine was cleaned, and by then nobody connects the two. The exam covers it under recovering from unauthorised access; in practice it is the tail of every serious infection, and knowing the order to do it in is what keeps the attacker from simply walking back in.

The lesson

Why a clean scan does not mean a clean account

A scan reports on files. It says nothing about what the infection did while it was running, and the two questions are entirely separate.

While it ran, with the user's rights, it could:

• Record keystrokes, including every password typed.
• Read the browser's saved passwords and its cookies — and a session cookie is a signed-in session, usable without the password and without triggering a second factor.
• Read any token stored by a desktop application: mail clients, chat, cloud storage, code tools.
• Read files, including the ones people keep passwords in.
• Watch the screen and the clipboard, which is where passwords go when they are pasted from a manager.

None of that is undone by removing the file that did it. The credential has left the machine and there is no recalling it.

So the rule is: treat every credential used on that machine while it was infected as compromised, and work back from the moment the symptoms started — or, when that is unknown, from the last point the machine was known good.

That is a big list, and prioritising it is the next section. The instinct to change "the important one" and stop is the mistake, because the important one is often reachable through a less important one.

Passwords, sessions and tokens, and the order to change them in

Order matters, because doing this in the wrong order lets the attacker keep what they have.

First, from a different, known-clean device. Changing a password from the infected machine before it is cleaned hands over the new one too.

1. The email account that receives password resets. This is the master key: whoever controls it can reset almost everything else. It goes first, whatever else is on the list.
2. The password manager's master password, if one is in use, followed by a check of its access log if it has one.
3. Accounts with money or authority — banking, payment, cloud administration, domain administration, the work account.
4. Anything sharing a password with the above, which is why the unique- password advice in this domain is not abstract.
5. Everything else, over the following days.

Then sign out everywhere. This is the step that is skipped and it is the one that matters most, because a stolen session cookie keeps working after a password change. Major services offer "sign out of all sessions" or a device list — use it, on every account you touched, immediately after changing the password. For an organisation's accounts, an administrator can revoke sessions centrally.

Then revoke tokens: application passwords, API keys, personal access tokens, and anything the user created for a script. These are long-lived and they are not affected by a password change at all.

Multifactor enrolments, recovery addresses and the backdoors an attacker leaves

Attackers who get into an account establish a way back in, and it survives the password change. This list is what you check, and it is short enough to do in ten minutes per account.

• Multifactor enrolments. Is there a second factor registered that the user does not recognise — an extra authenticator, a phone number, a security key? Remove it. An attacker who enrols their own factor can pass the check themselves.
• Recovery email and phone. Changed recovery contacts are the classic persistence: the attacker resets the password at leisure whenever they like. Verify every one.
• Trusted devices. Most services keep a list of devices that no longer need a second factor. Remove the ones the user does not recognise, and consider removing all of them.
• Backup and recovery codes. If the attacker generated or viewed them, they still work. Regenerate, which invalidates the old set.
• App passwords and legacy access. Older per-application passwords bypass multifactor by design. Revoke and recreate.
• Delegated access. Mailbox delegation, shared calendar permissions, "send on behalf of" — all grant continuing access with no password at all.

The order within an account is: change the password, sign out all sessions, then audit this list. Doing the audit first means the attacker, who may still be signed in, simply re-adds what you removed.

Checking mail rules, forwarding and OAuth grants, which survive a password change

These four survive a password change completely, and each has been used in real incidents to keep access long after everyone believed it was over.

Mail rules. A rule that moves messages from the bank, or from the finance team, to a folder nobody reads — or deletes them — is how invoice fraud stays invisible. Check the full rule list, including disabled ones and ones with innocuous names.

Forwarding. A forwarding address on the mailbox sends a copy of everything to the attacker indefinitely. Check both the account-level setting and any per-rule forwarding, and be aware that some platforms hide this in more than one place.

OAuth grants and connected applications. This is the one most often missed. A third-party application the user "signed in with" holds a token that grants continuing access — often to mail, files and contacts — and it is completely unaffected by a password change or by signing out sessions. Every major platform has a connected-applications list. Review it, and revoke anything unrecognised or unnecessary.

Sync and sharing. Folders shared with an external address, a synced device still enrolled, a repository deploy key.

The examinable point, and the one worth carrying: a password change does not revoke anything that was granted. Sessions, tokens, grants, rules and forwarding all persist, and each has to be dealt with explicitly. That is the whole reason this lesson exists as its own step rather than as a footnote to the removal procedure.

What to tell the user, their employer, and anyone whose data was on the machine

The technical work is only part of it, and the conversations are where a technician's judgement is visible.

The user. Tell them plainly what happened, what was potentially exposed, and what you have done. Give them their own list: which accounts to change that you could not, what to watch for, and what to report. Do not blame them — the social engineering lesson explains why that is both unfair and counterproductive. Do tell them that this may not be over, because account takeovers often follow weeks later, and a user who is expecting it will report it in hours rather than days.

Their employer, or whoever is responsible. The moment there is any sign that a work account, work data, or a work machine is involved, this stops being a technical decision. Most organisations have a reporting route and a requirement to use it, and a technician who quietly cleans a machine and says nothing has made that decision on the organisation's behalf. Report it, in writing, with what you observed and when.

Anyone whose data was on the machine. If the machine held other people's personal data, there may be a legal obligation to notify — and the assessment of that is emphatically not the technician's to make alone. The right action is to escalate with the facts.

Three habits that go with all of this: write down what you observed with times, keep it factual and free of speculation, and do not delete anything until whoever is responsible says you may. The chain of custody material in the operational procedures domain is the formal version of exactly this.