Responding to phishing and compromised email accounts
In short: Phishing response has two parts: dealing with the malicious email across the organisation, and handling any account that was compromised. Resetting a password is not enough; you must revoke sessions, check MFA methods, rules, forwarding and app consents, and work out what the attacker accessed.
Handling a reported phishing email
Phishing is still one of the most common ways attackers get in. Users who report suspicious emails are one of your best sensors, so make reporting easy and thank people who do it. For background on spotting phishing, see phishing basics.
Analyse the email safely: check the real sender and reply-to addresses, the authentication results for SPF, DKIM and DMARC in the headers, and where links really point. Open attachments only in a sandbox. Then search all mailboxes for the same sender, subject or URL, remove every copy, and block the sender and domains. The key question is who clicked, entered credentials or opened the attachment? Proxy, DNS and EDR logs answer that more reliably than asking users.
When an account is compromised
If someone entered their password on a fake login page, assume the attacker has it, and possibly a stolen session token too. Some phishing kits act as a proxy between the user and the real sign-in page, capturing the session cookie after MFA. This is why a password reset alone often fails.
- Revoke all active sessions and refresh tokens.
- Reset the password and review registered MFA methods, removing any the user does not recognise.
- Remove malicious inbox rules, external forwarding and delegated permissions.
- Review and remove suspicious OAuth application consents.
- Check sign-in and audit logs to see what the attacker accessed, sent, downloaded or changed.
- Look for related compromise: other users who received internal phishing from this account.
In Microsoft 365, administrators can use Exchange Online PowerShell and Microsoft Graph PowerShell for some of these steps, for example:
Get-InboxRule -Mailbox user@example.com | Format-List Name,Enabled,ForwardTo,DeleteMessage,MoveToFolder
Get-Mailbox user@example.com | Format-List ForwardingSmtpAddress,DeliverToMailboxAndForward
Revoke-MgUserSignInSession -UserId user@example.com
Search-UnifiedAuditLog -StartDate 2026-10-01 -EndDate 2026-10-08 -UserIds user@example.comBusiness email compromise and scope
Business email compromise (BEC) is when an attacker uses a real or look-alike mailbox to trick staff into paying fake invoices or changing bank details. Attackers often create rules that hide replies from the real user while they negotiate with finance. If payments may have been redirected, contact the bank immediately; speed matters for recovering funds.
| Scoping question | Where to look |
|---|---|
| What did the attacker read or download? | Mailbox audit logs, file access logs |
| Who did they email? | Sent items, message trace |
| Did they reach other systems via SSO? | Identity provider sign-in logs |
| Is personal data involved? | Content of accessed mail and files |
Supporting users and preventing repeats
Treat the user kindly. People who feel blamed stop reporting. Explain what happened, what they should watch for, and thank them for reporting quickly. Then improve controls: phishing-resistant MFA such as passkeys or FIDO2 security keys, conditional access, blocking legacy authentication, restricting automatic external forwarding, and limiting which apps users can consent to.
Tip: practise header and link analysis safely in the phishing analysis lab.
Practice
Why is resetting the password not enough after credential phishing?
Which logs best show who clicked a phishing link?
Why do BEC attackers create inbox rules?
Key takeaways
- Make reporting easy and thank users who report.
- Find and remove every copy, then check who interacted.
- For compromised accounts: revoke sessions, reset password, review MFA, rules, forwarding and consents.
- Scope what the attacker accessed and whether personal data is involved.
- Move towards phishing-resistant MFA and restrict forwarding and app consent.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.