Incident response
A phishing campaign just hit your Microsoft 365 tenant. The first hour.
Gociux · June 2026 · 6 min read
Phishing response is a race: the attacker needs one click and a few minutes; you need to find every copy of the message, every recipient, and every click — across a tenant — before credentials get used. Microsoft 365 gives you the tools for all of it, but the first time you learn them should not be during the incident. This is the first hour, in order.
Minute 0–10: scope it
One reported message is never one message. Take the sample (headers included) and establish the campaign's shape:
- Message trace in Exchange Online — search by sender, sender domain, and subject pattern over the last 48 hours. Campaigns rotate senders; trace by the infrastructure (sending IP ranges, return-path domain), not just the display name.
- Threat Explorer (with Defender for Office 365) — pivots from one sample to all related deliveries, and shows verdicts: delivered, junked, quarantined.
Output of this step: a recipient list, the malicious URL or attachment indicators, and a time window. Everything else builds on it.
Minute 10–25: stop the bleeding
- Block the indicators. Add the sender domains, URLs, and file hashes to the Tenant Allow/Block List. This kills the next wave at the door.
- Purge what was delivered. From Threat Explorer, select the campaign messages and trigger soft delete to pull them from mailboxes tenant-wide. Zero-hour auto purge may have already moved some — verify, don't assume.
- Mail flow rule as a backstop for pattern variants the block list doesn't catch yet — match on the campaign's distinctive subject or body markers and quarantine. Crude, temporary, effective.
Minute 25–45: find who clicked
Delivered ≠ compromised. Clicked is the line that matters:
- Safe Links click data (URL click events in Defender / Advanced Hunting) shows exactly which users followed the campaign URL and when — including clicks that happened after your block, which Safe Links will have stopped.
- Entra ID sign-in logs for those users: new locations, unfamiliar devices, impossible travel, and — critically — successful sign-ins close in time to a click. A credential-harvesting page is usually replayed within minutes to hours.
Minute 45–60: contain the compromised
For every account where click + suspicious sign-in line up:
- Revoke sessions (revoke sign-in sessions / refresh tokens) — a password change alone does not end an attacker's existing token.
- Reset credentials and require reauthentication with MFA.
- Check persistence: new inbox rules (forwarders to external addresses are the classic), newly registered MFA methods or devices, OAuth app consents granted around the incident window. Attackers plant these precisely because teams skip this step.
- Open the comms track: notify the affected users, and if cardholder or personal data may be involved, start the clock on your regulatory assessment — under GDPR, a notifiable breach has a 72-hour window to the supervisory authority.
What separates a one-hour incident from a one-week one is rarely the tooling — the tenant already has it. It's whether the hunting queries are written, the block-list procedure is documented, and somebody has rehearsed the sequence before the real thing. Runbooks are cheap; learning Threat Explorer live during a campaign is not.
After the hour
The same incident is your tuning data: which detection should have fired earlier, which users need targeted awareness follow-up, whether your anti-phishing policies — impersonation protection, DMARC enforcement on inbound — would have stopped delivery entirely. Every campaign you respond to should make the next one shorter.
Want this runbook tested against your tenant?
We harden Microsoft 365 tenants and build the response playbooks before the campaign arrives — mail-flow defenses, hunting queries, and containment procedures your team can run at 02:00.
Book a free assessment call
GOCIUX<<INSIGHTS<<<<<<<<<<<<<<<<<<EU<<SIBIU<RO<<<<<<<<<<<<