Employee Clicked a Phishing Link: Immediate Containment Runbook

TL;DR — If an employee clicked a phishing link last week, treat it as a possible account compromise until you prove otherwise. The most likely fix is to immediately reset the employee's password, revoke all active sessions, review sign-in logs for unusual access, and remove any malicious email forwarding or multi-factor authentication changes. Reading time: ~6 min

The scenario

It is Tuesday afternoon and someone on your team Slacks: "I think I clicked a weird Microsoft 365 login link last week. I entered my password but the page looked off." They have still been working normally, but now you are wondering whether their email, shared docs, or admin accounts have been exposed for days. You do not need a deep forensic (evidence-gathering) lab to take the right first steps, but you do need to move in the right order so you do not leave an attacker signed in.

Symptoms

• The employee reports clicking a login link in email, chat, SMS, or a document and entering credentials.
• The employee saw a fake sign-in page, an unexpected file download, or a prompt to approve multi-factor authentication (MFA, a second sign-in check).
• Sign-in history shows logins from unusual locations, devices, or times.
• The mailbox contains rules the user did not create, such as auto-forwarding or moving invoices/security emails.
• The account has new MFA methods, recovery email addresses, or app passwords the user does not recognize.
• Coworkers or customers report strange emails sent from the employee's address.
• Cloud app audit logs show consent granted to an unknown app or OAuth app (an app allowed to access email/files without the password).
• Endpoint security shows a browser download, new process, or malware alert around the time of the click.

Likely causes

Step-by-step diagnosis

1. Contain the account first: reset password and revoke sessions. In your identity provider dashboard, open the user account and use the built-in actions for password reset and sign out everywhere. Common paths are your provider's admin dashboard → Users → select user → Reset password, then Revoke sessions / Sign out of all sessions.

   • This is your problem if: the user entered credentials on the phishing page, approved an MFA prompt they did not expect, or sign-in logs show unknown access.
   • Jump to: Fixes → ### Stolen password with active session still valid

2. Review recent sign-ins for suspicious access. In your provider's dashboard, open the same user and check Sign-in logs / Login history for the last 7-14 days.

   • This is your problem if: you see impossible travel, unknown countries, unfamiliar browsers, legacy authentication, or successful logins after the phishing event.
   • Jump to: Fixes → ### Stolen password with active session still valid and then continue to steps 3-5.

3. Check mailbox forwarding and inbox rules. In your mail admin portal or the user's mailbox settings, inspect forwarding, delegated access, and rules. If you have command-line access in Microsoft 365 Exchange Online, you can confirm with:

Get-InboxRule -Mailbox user@example.com
Get-Mailbox -Identity user@example.com | Select-Object ForwardingAddress,ForwardingSmtpAddress,DeliverToMailboxAndForward

• This is your problem if: you find rules that move security emails, hide replies, forward mail externally, or mark messages as read.
• Jump to: Fixes → ### Mailbox rules or forwarding added after compromise

1. Check authentication methods and recovery changes. In your identity provider dashboard, open the user and review Authentication methods, recovery email, phone, app passwords, and registered devices.

   • This is your problem if: there is a phone number, authenticator app, hardware key, or recovery address the employee does not recognize.
   • Jump to: Fixes → ### MFA method changed or attacker enrolled a new factor

2. Check for malicious app consent. In your provider's admin area, review connected apps, enterprise applications, or third-party access granted by the user.

   • This is your problem if: an app the employee does not recognize has mail/file access scopes such as read mail, send mail, or offline access.
   • Jump to: Fixes → ### OAuth app consent granted to a malicious app

3. Check the device used to click the link. In your endpoint security console, search the user's laptop by hostname and review detections, downloads, and browser activity around the reported date. If you only have local access on Windows, open Windows Security → Virus & threat protection → Protection history.

   • This is your problem if: there was a downloaded executable, browser extension install, malware alert, or suspicious process started from Downloads or Temp.
   • Jump to: Fixes → ### Malware installed from the phishing page or download

4. Review browser artifacts last. On the employee's device, inspect recent downloads, extensions, and saved passwords in the browser they used.

   • This is your problem if: the browser saved the password on a fake site, installed a new extension, or shows a suspicious download at the click time.
   • Jump to: Fixes → ### Browser saved credentials or session cookies exposed

[Employee] ---- 1. clicked link ----> [Phishing Page]
     |                                  |
     | 2. entered password              | 3. steals creds/session
     v                                  v
[Identity Provider] <---- 4. attacker signs in ---- [Attacker]
     |
     | 5. adds rules / MFA / app consent
     v
[Mailbox and Cloud Apps]

Fixes

Stolen password with active session still valid

Do these actions in this order:

1. Reset the password in your identity provider admin dashboard.
2. Revoke all active sessions / sign out everywhere.
3. If the account is privileged, remove admin roles until review is complete.
4. Require the user to sign in again and re-register MFA if needed.

If you use Microsoft 365/Entra and have PowerShell access:

Revoke-EntraUserAllRefreshToken -UserId user@example.com

For Google Workspace, use Admin console → Directory → Users → select user → Security → Reset password, then Sign out user.

Verify it worked: the next sign-in should require the new password, and old sessions should stop working on other devices.

Mailbox rules or forwarding added after compromise

Remove any unknown inbox rules, forwarding addresses, delegated mailbox access, and send-as permissions.

Exchange Online examples:

Get-InboxRule -Mailbox user@example.com
Remove-InboxRule -Mailbox user@example.com -Identity "RSS Feeds"
Set-Mailbox -Identity user@example.com -ForwardingSmtpAddress $null -DeliverToMailboxAndForward $false

Also review mailbox delegates in your mail admin portal and remove anything unfamiliar.

Verify it worked: send a test email to the user and confirm it stays in the inbox, is not auto-forwarded, and no hidden rule reappears.

MFA method changed or attacker enrolled a new factor

Delete unrecognized MFA methods, app passwords, recovery addresses, and trusted devices. Then force the employee to register MFA again using a known-good device.

Typical dashboard path: Admin dashboard → Users → select user → Authentication methods / Security info → Remove unknown entries.

If your provider supports it, require re-registration at next sign-in.

Verify it worked: the user sees only their own phone/app/security key listed, and a fresh sign-in prompts for the expected MFA method.

OAuth app consent granted to a malicious app

Revoke the app's access and remove the enterprise/connected app assignment for that user. Then rotate the user's password and revoke sessions even if you already did so, because the app may have offline tokens.

Typical dashboard path: Admin dashboard → Enterprise apps / Connected apps → open suspicious app → Revoke user consent / Delete app access.

If your provider exposes scopes, remove apps with permissions like Mail.Read, Mail.Send, Files.ReadWrite, or offline_access unless you can confirm the business need.

Verify it worked: the suspicious app no longer appears under the user's connected apps, and audit logs stop showing token use by that app.

Malware installed from the phishing page or download

⚠️ If you isolate or wipe the device, the employee may lose unsaved local work and the device may be unavailable for hours. If the device belongs to a regulated environment, preserve evidence before reimaging.

First isolate the device in your endpoint security tool if malware is detected. Then run a full scan. If detections include credential stealers, remote access tools, or persistence (software that survives reboot), reimage the device instead of trusting cleanup.

Windows local path: Windows Security → Virus & threat protection → Scan options → Full scan.

If your security tool supports isolation, use that control in the console, then coordinate IT to rebuild the laptop from a clean image.

Verify it worked: the endpoint console shows no active detections, the device is either rebuilt or clean after a full scan, and the user signs in only after password reset and session revocation.

Browser saved credentials or session cookies exposed

On the affected browser, remove suspicious extensions, clear saved passwords for the fake site, and sign out of the browser profile if it syncs passwords.

Common browser paths:

• Chrome/Edge: Menu → Extensions → Manage extensions
• Chrome/Edge: Settings → Password Manager
• Chrome/Edge: Settings → Privacy → Clear browsing data
• Firefox: Menu → Add-ons and themes; Settings → Privacy & Security

If the browser was signed into a synced profile, change that profile password too.

Verify it worked: the suspicious extension is gone, the fake-site credential is removed, and the browser no longer auto-fills that password.

Prevention

• Block external auto-forwarding unless explicitly approved. In your mail admin settings, disable automatic forwarding to external domains or create an allowlist-only policy.
• Alert on risky sign-ins and impossible travel. In your identity provider, enable alerts for new country login, impossible travel, MFA method changes, and mass session revocation events.
• Require phishing-resistant MFA for admins. Prefer hardware security keys or passkeys for privileged accounts; do not leave admin accounts on SMS-only MFA.
• Turn off user app consent by default. In your identity provider, restrict users from granting third-party apps mail/file access without admin approval.
• Add mailbox rule auditing to your weekly checks. Export inbox rules and forwarding settings for high-risk users and compare changes.
• Run a short post-incident checklist. After every phishing click, document: who clicked, what was entered, what device was used, what was reset, what logs were reviewed, and whether customers or legal/compliance need notice.

A simple internal checklist can look like this:

{
  "user": "user@example.com",
  "clicked_at": "2026-10-23T14:10:00Z",
  "entered_password": true,
  "approved_mfa": false,
  "password_reset": true,
  "sessions_revoked": true,
  "mailbox_rules_checked": true,
  "mfa_methods_checked": true,
  "oauth_apps_checked": true,
  "device_scanned": true,
  "customer_notification_required": false
}

If you find confirmed attacker activity in email, shared files, finance systems, or customer data, escalate from containment to a full incident response process the same day.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.