vendor email compromise wire-fraud phish failed to trigger bec rule

TL;DR

Vendor email compromise succeeds because the mail often comes from the real vendor account, taken over, so authentication passes and only content and process signals remain: a bank detail change, urgency, and a thread hijacked mid-conversation. The BEC rule needs those behavioural signals, but the decisive control is procedural: no bank change is actioned from email alone. Tune detection, then verify the live request out of band before any payment moves.

vendor email compromise wire-fraud phish failed to trigger bec rule

Use this when

• Finance received a bank-detail change or urgent payment request from a vendor address.
• A known vendor account was later confirmed compromised and its mail passed your filters.

Not for this skill when

• The request is a routine invoice on existing bank details. Normal AP handling applies.
• The vendor domain is a lookalike, not the real account. That is domain impersonation with different evidence.

Steps

1. Freeze any pending payment tied to the request until verification completes. Verify: finance confirms the hold in writing.
2. Inspect the message for BEC signals: reply-to mismatch, thread hijack position, new bank details and pressure language, and record which your rule should have caught. Verify: the missed signals are listed.
3. Verify the request by calling the vendor on a number from your records, not from the email. Verify: the vendor confirms or denies the change through the independent channel.
4. Tune the BEC and anti-phishing policy: enable vendor and finance impersonation protection and first-contact safety tips, and add a rule flagging bank-detail language from external senders to finance. Verify: the tuned settings are active for finance users.
5. Hunt for other mail from the vendor account in the compromise window and review each payment-adjacent thread. Verify: no other fraudulent instruction is pending.

Variant phrasings

vendor email compromise bank details change bec detection

The bank change variant.

bec rule missed wire fraud supplier impersonation tuning

The tuning variant.

Compatibility: Defender anti-phishing BEC signals, finance payment verification procedures.

Why it happens

Authentication proves the account, not the intent. A compromised vendor account passes SPF, DKIM and DMARC, so filters must score behaviour and content, which are weaker signals, and process controls carry the real weight.

Edge cases / pitfalls

• A callback procedure only works if the number predates the suspicious mail. Numbers in the message are attacker-controlled.
• Thread hijacking means the early messages are genuine. Judge the specific instruction, not the thread history.
• Report the compromise to the vendor through your independent contact; their other customers are targets too.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Y2ItMJljqlDNXPGbx31x2A