DEV Community

Hive80-lab
Hive80-lab

Posted on Originally published at hive80-lab.github.io

A real-looking invoice, a friendly email, and the one callback rule that stops almost all of it

A real-looking invoice, a friendly email, and the one callback rule that stops almost all of it

The email that arrives before a wire fraud doesn't look like an attack. It looks like Tuesday: a supplier you've paid for two years, a short note, a new account number, a "kindly update your records" at the bottom. No link. No attachment. Grammar clean. And because it's accounting-shaped, it skips the part of everyone's brain that flags weird emails — that's the entire trick.

Business email compromise works because it wears the costume of routine. The four plays all look like work:

  1. The boss's "urgent, confidential payment" (secrecy is the tell, not urgency)
  2. The vendor whose "bank details changed" — plausible reason included
  3. The fake invoice from a vendor you actually use (sometimes their real, stolen mailbox)
  4. The reply inside a real invoice thread with new payment details — no forged domain anywhere

And here's the uncomfortable part: a good attacker clears every tell people usually teach. Display-name mismatches, lookalike domains, urgency-plus-secrecy — all worth training, none sufficient.

The one rule that beats all four plays

Bank details change by voice, never by email. When payment details change, call the vendor back on the number you already have — from your vendor ledger, not the email signature, and not the invoice. Attackers control the whole paper trail: letterhead, signature block, even the "call us to confirm" number. The only channel they don't control is the phone number your ledger recorded last year.

If the ledger number goes to voicemail, the payment waits. "We couldn't reach them on the recorded number" is a complete sentence. Nobody legitimate objects to the callback — vendors live with banks asking the same question.

Around it, make payments boring: two-person approval above a threshold you actually enforce, a three-way match (invoice ↔ contract ↔ ledger) before paying, and no urgent bypass — the exception process for urgency is a faster version of the normal process, never a skipped one. And watch for invoices that arrive just under your approval limit; that's a probe, not a coincidence.

If the payment already went out

Speed, not analysis: call your bank and say "fraudulent transfer" — those two words route you to recall, not to "user error." Ask your bank to freeze the funds at the receiving bank while they're still in the account. File with IC3 (US) the same day — that paper trail is also what your cyber insurer will ask for. And treat the mailbox as compromised until you've rotated credentials and killed any forwarding rules; if a thread was hijacked, the attacker is still reading it.

Then tell the team the boring truth. Silence guarantees a repeat — the same play works twice on the same target.

Then drill it

Once a quarter, send yourselves the fake bank-change email and see whether anyone calls the ledger number or starts typing a transfer. Fifteen minutes, quarterly. It's cheaper than any wire.

The full checklist — the four fraud plays, the callback script, the two-person rule, mailbox hardening, the first-hour recall sequence, and the quarterly drill — is on our ops notes site: Invoice Fraud & Business Email Compromise Prevention Checklist.

If you want the incident-response muscle around it, the Ops Starter Kit gives you the fillable plan, severity matrix, and comms templates in about 20 minutes — and the free First 30 Minutes one-pager is the quick-start version. The Automation Starter Pack covers the pick-first workflows (vendor ledger reviews, payment calendars, rotation). Launch week: 30% off any paid kit with code HIVE-LAUNCH30.

Be honest: if a supplier emailed you right now with "updated bank details," would anyone in your payables process make them prove it by voice?

Top comments (0)