/bec-response

name: "BEC Response"
description: >
  Business Email Compromise detection and first response: the signals that
  reveal it in CIPP/M365 audit logs, mailbox and forwarding rules, and
  connected email security vendor alerts; the order-dependent response
  sequence (session revocation, forwarding-rule audit, mailbox rule and
  delegate cleanup, password reset, MFA re-enrollment, lateral-spread check,
  recipient notification); and what a defensible incident timeline must
  capture for insurance or bank-fraud claims.
when_to_use: >-
  When Business Email Compromise is suspected or confirmed, or when signs of
  it need to be checked for proactively. Use when: BEC, business email
  compromise, invoice fraud, wire fraud email, suspicious forwarding rule,
  mailbox compromised, executive email compromised, phishing led to account
  takeover, someone is impersonating our client's email.

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:

| Signal | Where to look | What it looks like | |--------|---------------|---------------------| | Anomalous sign-in | CIPP / Entra audit logs | Impossible travel, sign-in from an unfamiliar ASN/country, sign-in immediately followed by mailbox configuration changes | | New or modified inbox rule | CIPP mailbox rule listing | A rule that forwards, deletes, or moves messages matching finance/invoice/wire-related keywords — especially rules that move matching mail straight to an obscure folder or delete it, hiding replies from the real recipient | | External forwarding rule | CIPP mailbox rule / forwarding configuration | Auto-forward to an external domain the organization doesn't use, often silently enabled without a visible rule in the client UI | | BEC-pattern indicators | CIPP's BEC-focused check (e.g. `cipp__bec_check`-style tooling — confirm the exact tool name via `conduit__search_tools`) | Correlated signals CIPP flags specifically as BEC-shaped: new inbox rule plus anomalous sign-in plus external forwarding in the same session | | Inbound phishing / impersonation alert | Connected email security vendor | A message that impersonates a vendor, executive, or the client's own domain, especially one referencing an invoice, wire transfer, or payment change | | Reported anomaly from the client | PSA ticket / direct report | "This doesn't look like an email I sent," a client asking to confirm a wire change, or a vendor asking whether a payment-details email was legitimate |

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 afte