Vendor Fraud BEC Alert

BEC is a money problem before it is an email problem. Put the funds first — freeze, recall,
verify by callback — then work the forensics. In order:

1. Capture the facts: what payment or banking change was requested, the amount, the claimed
   sender (vendor, executive), the channel, and — the fork in the road — whether any payment
   has already been sent.
2. If money already moved, this outranks investigation: advise the client to contact their
   bank immediately to attempt a recall or freeze of the transfer (recovery odds fall by the
   hour), and to file the applicable fraud report for their policy and jurisdiction — in the
   US, IC3; elsewhere, the national cybercrime channel. Timestamp that guidance in the note.
3. Freeze regardless: have the client hold all pending payments to the affected vendor, and
   any payment initiated from the suspect thread, until verification completes.
4. Run the callback verification ladder — the wire-fraud-verification-protocol standard:
   verify with the vendor by phone on a number already on file, from prior invoices, the
   contract or documentation — never a number, email address or link from the suspicious
   message. No number on file → reach a previously known contact at the vendor, or the
   vendor's publicly listed main line, and ask for that contact. Log who verified what, when,
   on which number.
5. Investigate the message: run email-header-analysis, and check for a lookalike domain (typosquat-domain-alert) versus the harder case — a compromised REAL
   vendor mailbox, where the thread history is genuine and only the banking details changed.
   Reply-to divergence and fresh banking details in an old thread are the tells. A
   genuine-looking thread never clears the request — verify the details, not the tone. If the
   compromised side might be the client's own mailbox, branch to account-takeover-runbook.
6. Blast radius: search related tickets and ask the client who else received the request and
   whether anyone began acting on it. Every recipient gets the warning; anyone who processed
   anything takes the step 2 path.
7. Notify with the vendor-fraud template from the soc-client-email-pack, and document the
   decision, not just the action: the request, the verification outcome, the money status,
   and the reasoning behind the verdict. Classify per soc-classification-tree.

Never confirm, request or transmit wire or banking details by email — not to the client, not
to the vendor, not "just to compare." Payment details are verified by voice to a number on
file, and the client guidance states the same rule. Write defensively about the vendor
(defensive-writing-standard): "a fraudulent payment request appearing to come from <vendor>",
never that the vendor was breached — their mailbox status is unconfirmed and the claim
carries legal weight. When in doubt, escalate and hold the payment.