What to do when you click something bad

You clicked. Maybe you typed your password. Maybe you approved a prompt. This lesson is the one to act on, and the most important thing in it is the first sentence:

Report it immediately. Nobody is going to be angry with you.

Everything else in this lesson is faster and easier if the report happens in minutes rather than after a weekend of hoping it was nothing. The delay is what turns a contained incident into a breach — not the click.

First ten minutes, in order

1. Disconnect only if something ran. If you opened a file, enabled content, or ran an installer, take the device off the network — Wi-Fi off, cable out. Don’t power it off: memory contains evidence, and a running-but-isolated machine is more useful to responders than a wiped one.

If you only entered a password on a web page, skip this. The problem is the credential, not the machine.

2. Change the password — from a different device. If the machine might be compromised, a password typed on it may go straight to the attacker too. Use your phone or another computer.

Change it anywhere you reused it. This is the moment reuse turns one mistake into several.

3. Revoke active sessions. This is the step almost everyone misses, and it is the one that matters most against modern phishing kits.

Changing a password does not automatically log an attacker out. If they proxied your login and captured the session cookie, they hold a valid session that survives the password change. Every major provider has a “sign out of all sessions” or “revoke active devices” control. Use it.

4. Report to whoever handles this. Security team, IT, or your manager. Include:

• The time you clicked, as precisely as you can
• What you entered, if anything
• The sender address and the link, if you still have them
• Whether you approved any MFA prompts

Forward the original message rather than a screenshot where possible — the headers are the useful part.

5. Watch for the follow-up. Attackers often phone shortly after, posing as IT “helping with the security alert.” The purpose of that call is to collect the MFA code that your password alone can’t produce. Treat any unsolicited call about the incident as part of the incident.

What not to do

Don’t delete the email. It’s evidence. Responders need the headers to find who else received it.

Don’t test the link again “to check.” You’ll add noise to the logs and possibly a second compromise.

Don’t quietly handle it alone. Even if you’re confident it was blocked. The same campaign almost certainly went to colleagues, and your report is what warns them.

Don’t wait for certainty. “I think it might have been fine” is a report worth making. False alarms cost a few minutes; unreported compromises cost weeks.

If you approved an MFA prompt

Treat this as more serious than a password alone, and say so explicitly when you report it. An approved prompt often means the attacker completed a login. Revoke sessions first, then change the password, then report — in that order, because the live session is the immediate problem.

If it was a payment or data request

If you changed bank details, sent a file, or approved a transfer: contact your finance team immediately, and separately contact the bank. Payment recall has a window measured in hours. This is the one scenario where speed translates directly into recovered money.

The culture point

Organisations that punish clicking have staff who hide clicks. Staff who hide clicks give attackers days of undisturbed access.

If you take one thing from this course: the click is a normal, expected event that good defences plan for. The only genuinely damaging mistake is silence.

---

That’s the course. If something here was unclear, or you have a scenario that doesn’t fit these steps, ask in the comments below.