BEC Response

BEC Response

Overview

Business Email Compromise is the highest financial-impact incident class most MSPs handle, and it is also one of the easiest to miss early because the attacker's goal is to look exactly like the legitimate mailbox owner for as long as possible. There is rarely a malware payload to detect — the "malware" is a valid session token and a quietly added inbox rule. This skill covers how to detect BEC from the connected M365 tenant and any connected email security vendor, and the response sequence once it's confirmed or strongly suspected.

Anti-triggers

• A vendor's own case record — Abnormal tracks investigations as cases with their own remediation actions; use abnormal-security-cases when working inside one. It has no separate account-takeover case type — ATO is a threat classification, not an object, so an ATO investigation is an ordinary case.
• The inbound phishing message itself — quarantine, release, and message-level forensics are the email-security connector's surface; use avanan-quarantine, ironscales-incidents, proofpoint-forensics, or mimecast-message-tracking.
• The individual CIPP calls behind each step — session revocation, mailbox rules, and user state are cipp-users, cipp-mailboxes, and cipp-security; what this skill supplies is the order they must run in.

Step Zero: Confirm What's Connected

Call conduit__search_tools to confirm which of CIPP, the M365/Entra connector, and an email security vendor (Mimecast / Proofpoint / Abnormal / Ironscales / Avanan / SpamTitan) are actually connected for this client. CIPP is the primary source for this skill — it exposes M365 audit logs, mailbox rules, and BEC-specific checks directly. If CIPP is not connected, note that explicitly: the detection signs below still apply conceptually, but they must be checked through whatever admin console access is available instead. An email security vendor, if connected, adds inbound-side signal (the phishing message that led to the compromise) that CIPP alone won't show.

Detecting the Signs

Pull these signals — do not wait for all of them before acting on strong individual signals, but corroborate wherever possible:

Any one of these alone is enough to open an investigation. The combination of an anomalous sign-in plus a new inbox/forwarding rule in the same session is close to a confirmed BEC and should move straight to the response sequence below rather than waiting for further corroboration.

Immediate Response Sequence

Order matters — earlier steps stop later damage; doing them out of order leaves gaps:

1. Revoke active sessions. Invalidate all refresh tokens/sessions for the account immediately. This is the single highest-leverage first step — it ends the attacker's access to the mailbox in real time, before anything else is touched.
2. Audit and remove forwarding rules. Pull every inbox rule and forwarding configuration for the account. Document each one found (rule name, condition, action, creation timestamp) before deleting — this becomes part of the incident timeline and may be needed for a fraud claim. Remove any rule that forwards, hides, or deletes mail in a way the legitimate user didn't set up.
3. Clean up mailbox rules and delegate access. Beyond forwarding rules, check for new mailbox delegates, new mail-flow rules at the tenant level (if the attacker had elevated access), and any newly created mailbox on the tenant that could be used to continue impersonation.
4. Reset the password. Only after sessions are revoked — a password reset alone does not invalidate a live session token.
5. Force MFA re-enrollment. Invalidate any MFA method the attacker may have registered during the compromise window (a common BEC persistence technique is registering an attacker-controlled authenticator app or phone number as a second MFA method).
6. Check for lateral spread. Look for the same source IP/ASN or the same inbox-rule pattern against other mailboxes in the tenant — BEC actors frequently compromise one mailbox and use it to phish others internally.
7. Identify and notify affected recipients. Determine who received attacker-sent mail during the compromise window — especially anything referencing invoices, wire instructions, or payment changes — and get ahead of it with a direct warning before the attacker's message gets acted upon. This step has the highest financial-loss-prevention value of the entire sequence and should not be delayed until the technical cleanup is finished; run it in parallel once the compromise window is known.

Documenting the Incident Timeline

A BEC incident report needs a defensible, chronological record — clients frequently need this for a cyber-insurance claim or a bank fraud dispute. Capture, with timestamps for each:

• First anomalous sign-in (source, location if available)
• Each mailbox rule/forwarding rule created, with its exact configuration
• Each message sent or received during the compromise window that is relevant to the incident (especially anything with financial content)
• Containment actions taken, in the order taken, with timestamps
• Notification actions taken (who was told, when, by what channel)

For building the full client-facing report, hand this off to the Incident Timeline Builder agent or the /secops-pack:incident-report command — this skill covers detection and first response; the timeline builder assembles the complete chronological narrative across every connected system.

Related Skills

• Containment Playbooks — the general compromised-account playbook this skill specializes for BEC.
• Alert Severity Normalization — BEC indicators typically normalize to Critical or High; see the mapping reference for the reasoning.