What should organisations do after a suspected spoofing or BEC event?

Why containment starts with the mailbox and the session, not just the message

After a suspected spoofing or BEC event, the first job is to stop the conversation path the attacker is using. That means containing the mailbox, looking for related messages and determining whether the sender identity, mailbox rules or session state has already been abused. If the compromise is still active, every new message becomes part of the same incident.

Containment also needs to account for what the attacker may have already done with valid access. A stolen session token can bypass password changes until it is revoked, and mailbox rules can silently divert replies or invoices even after the obvious phishing message is removed. Treat the incident as an access and workflow problem, not only an email hygiene problem.

How to confirm the blast radius after the first suspicious message

The practical question is not whether one message looked fake, but whether the same sender path, account or rule set was used elsewhere. Search for related messages, check whether the attacker tried other recipients and identify which staff received, replied to or forwarded the message. That gives you the blast radius before you decide how widely to notify or reset trust.

This is also the point to review sender-domain enforcement, because spoofing and BEC often succeed where authentication or policy enforcement is inconsistent. If a domain allowed impersonation once, the same gap can be reused for invoice fraud, reply-chain abuse or executive impersonation until the control gap is closed.

Why post-incident cleanup must include users, rules and sender controls

Post-incident cleanup should remove any persistence, then reduce the chance of repeat abuse. Review inbox rules, delegated access, forwarding settings, OAuth grants where relevant and any changes that would let an attacker keep observing or steering mail flow. Alert affected staff immediately so they can treat follow-on messages as untrusted, even if they appear to continue a known thread.

The most important follow-up action is to close the exact path that made the spoofing or BEC attempt viable. If the organisation only removes the visible message but leaves the mailbox state, session state or sender enforcement unchanged, the next attempt will likely look almost identical and succeed for the same reason.

Risk and Threat Considerations

Spoofing and BEC incidents are dangerous because they abuse trust that already exists in business communication. The main exposure is not just message deception, but transactional fraud, credential theft, mailbox persistence and silent redirection of business processes.

Failure mechanism: An attacker leverages trusted sender presentation, stolen session state or mailbox rules to remain inside the communication flow, then reuses that access to steer replies, approvals or payments.

Impact: Organisations can lose money, expose sensitive correspondence, miss follow-on compromise and keep trusting a poisoned thread long after the first message is found.

Practitioner Guidance

What to verify: Confirm whether the suspicious account still has active sessions, forwarding, delegated access or inbox rules that can continue the abuse. If any of those remain, the incident is not contained.

Decision rule: If the event involved a live mailbox or token, prioritise session revocation and mailbox-state review before broader hunting. If it was only a spoofed message with no access, focus on sender-domain enforcement and recipient notification.

Common mistake: Teams often delete the message and reset the password, then assume the incident is over. That misses the persistence mechanisms that make BEC effective.

Practitioner takeaway: The decisive question is whether the attacker only sent a message or actually gained a reusable foothold in mail flow, because only the latter requires full containment and revalidation of trust.

Related resources from NHI Mgmt Group

• Guide: Email Identity and BEC Guide
• What should organisations do after a silent poisoning event is suspected?
• Why do still-valid secrets matter after public disclosure?
• What makes Shai Hulud 2.0 different from a normal npm malware event?
• When should organisations reset KRBTGT after suspected compromise?