What exactly did the employee do?
This is the first question, and the answer changes everything else. Ask it without looking for someone to blame: a person who reports quickly is your best sensor, and if they fear punishment, the next one won't report. Ask for the approximate time, the original email (without forwarding it to anyone else) and what they saw on screen after clicking.
| What happened | Risk | First actions |
|---|---|---|
| Opened the email and did nothing else | Low | Report it and remove it from all mailboxes |
| Clicked, but didn't type anything | Low to medium | Check downloads and EDR alerts, block the domain |
| Entered their username and password | High | Change the password, revoke sessions, review MFA and mailbox rules |
| Approved an MFA prompt or read out a code | High | Revoke sessions immediately and review what was done with the account |
| Opened an attachment or ran a file | High | Isolate the device and treat it as a possible infection |
| Replied with data or made a payment | High | Call the bank and check whether it is CEO fraud or BEC |
What should you do if they only clicked the link?
Many phishing links lead to a page that imitates the sign-in page of Microsoft 365, Google or a bank. Clicking without typing anything usually has little impact, but you can't rule out a download. Check three things:
- Whether any file was downloaded (ZIP, ISO, HTML, LNK, JS or MSI) and whether it was opened.
- Whether the EDR or antivirus logged any alert on that device since the time of the click.
- Whether the employee typed anything, even just their email address. Sometimes they don't remember clearly: browser history and proxy logs help.
Block the domain and the URL in your email filter, proxy or DNS so nobody else reaches the page.
What should you do if they entered their password on the fake page?
Assume the attacker has the account, and probably an open session too. Microsoft documented adversary-in-the-middle (AiTM) phishing campaigns in which the fake page captured both the password and the session cookie, which let attackers sign in even when the account had MFA. In some cases, payment fraud began just five minutes after the theft. Changing only the password is not enough.
- Change the password from a device you know is clean, and don't send the new one by email.
- Revoke all sessions and tokens for the account in your identity platform.
- Review the registered MFA methods and remove any the employee doesn't recognize.
- Review inbox rules, forwarding, apps with permissions and app passwords.
- Review sign-ins since the time of the click: IP address, country, device and app.
- If the employee used that password on other services, change it there too.
If you find sign-ins by the attacker or new rules, switch to the compromised account procedure, which adds mailbox cleanup and an investigation of what the attacker did.
What should you do if they opened an attachment or ran a file?
Treat it as a possible infection. A phishing attachment can install a loader that downloads more malware, or an infostealer that steals saved passwords and session cookies from the browser.
- Isolate the device from the network with your EDR, or by unplugging the network cable and turning off Wi-Fi. Don't shut it down: its memory contains evidence.
- From another device, change the employee's corporate password and any passwords saved in their browser.
- Revoke their open sessions. With a stolen cookie, the attacker can sign in without a password or MFA until the session expires or is revoked.
- Analyze the device: processes, outbound connections and persistence mechanisms. Search the rest of your devices for the attachment's hash and the domains it contacted.
- If the infection is confirmed, rebuild the device after collecting the evidence. Cleaning it by hand leaves doubts.
What if they approved an MFA notification or gave out a code?
If someone approves a prompt they didn't request, or reads out a code over the phone, the attacker most likely already had the password and now has a valid session. Act without waiting: temporarily block sign-in if you can, change the password, revoke all sessions and review the MFA methods, because the attacker may have registered their own. In the medium term, Microsoft recommends phishing-resistant MFA (FIDO2 or certificate-based authentication) and Conditional Access policies that require compliant devices or trusted IP addresses.
How do you know if other employees received the same email?
Many phishing campaigns reach several people at once. From the original email, extract the sender, subject, URLs and attachment hash, and search for them in your email platform (message trace in Microsoft 365 or Email Log Search in Google Workspace). Remove the message from every mailbox, check your proxy or DNS logs to see who visited the domain, and block the indicators. To warn your staff, send a screenshot of the email, never the original.
What not to do after a phishing incident
- Punish or single out the employee who reported it.
- Change only the password and close the case without revoking sessions.
- Forward the malicious email to the whole company as a warning.
- Open the link or the attachment from a corporate device to see what it was.
- Delete the email before extracting the headers, URLs and attachment: they are the indicators you need to find it in other mailboxes.
How Ciberia helps with phishing
A click in an email, an odd sign-in an hour later and a new forwarding rule can be the same incident, even if each signal fires in a different tool. Ciberia MDR monitors the email, identity and endpoint telemetry you already have 24/7, and each alert is analyzed in context before a decision is made. The AI automates about 90% of triage, an analyst validates decisions with impact, and the response is orchestrated on your own tools. The SLA is 15 minutes from critical alert to initial containment.
Ciberia Intel adds context on campaigns and IOCs, and Ciberia CTM watches for leaked credentials belonging to your employees and sends alerts with the recommended action.
