BEC Tabletop Exercise: The Supplier Bank-Detail Change

Business email compromise (BEC) is a fraud problem wearing a security costume. The attacker's goal is not your data; it is your money. They get into a mailbox (yours or a supplier's), watch conversations, and at the right moment ask for a payment to be sent to a new bank account. Losses are often large, and recovery depends on how fast finance, IT and the bank act together.

This scenario is an ideal first tabletop. It is short, needs no deep technical expertise and exposes gaps in payment controls, mailbox security and escalation between finance and IT. It works well for finance teams, accounts payable, IT and a senior finance leader.

Scenario at a glance

Exercise objectives

1. Verify that the procedure for changing supplier bank details requires independent verification, and that it is followed under time pressure.
2. Confirm that finance knows how to contact the bank's fraud team immediately, and which information the bank will need to attempt a recall.
3. Test the hand-off between finance and IT/security when fraud is suspected: who is told, how and how fast.
4. Validate that IT can investigate a mailbox compromise: sign-in logs, inbox rules, OAuth app consents and forwarding.
5. Identify notification and reporting obligations: law enforcement, insurer, the affected supplier and, if personal data was exposed, privacy obligations.

Starting situation

Read this aloud to players:

It is Tuesday, 10:15, the second-last working day before month-end payment run. Accounts payable is busy clearing invoices. Your largest raw-materials supplier, a long-standing partner, has an invoice for a significant amount due this week.

Your organisation uses cloud email with multi-factor authentication for all staff. Payment runs are prepared by accounts payable and released by treasury after approval by the finance director.

Injects timeline

Module 1 — The request (T+00:00 to T+00:40)

Inject 1. Accounts payable receives an email that appears to come from the supplier's account manager, replying in an existing thread: "We've moved our banking to a new provider. Please update our details and use them for invoice 4471 due this week. New details attached on our letterhead."

Inject 2. Fifteen minutes later: "Just checking you received our new details — our finance team says invoice 4471 is now overdue and it's blocking our next shipment. Can you confirm today?" The email correctly references the supply contract number.

Inject 3. The bank details are updated in the vendor master file and the payment goes out in Wednesday morning's run.

Discussion questions:

• What does your procedure require before changing a supplier's bank details? Is it documented?
• Would the AP clerk call the supplier to verify? Using which phone number: one in the email, or one already on file?
• Who approves a vendor-master change, and does that person see the evidence of verification?
• Does your email system flag external look-alike domains or replies from outside your organisation?
• If the procedure was followed, what would have stopped this payment?

Module 2 — Discovery and funds recovery (T+48:00 to T+48:20)

Inject 4. Two days later, the supplier's real account manager calls: "We still haven't received payment for 4471. And we never changed banks, why are you asking?"

Inject 5. Treasury calls the bank's fraud line. The bank (played by the controller) asks for the transaction reference, amount, beneficiary account, timestamps, whether you have filed a police report, and who is authorised to request a recall on your behalf.

Discussion questions:

• Who is the first person called when fraud is suspected? Is IT informed at the same time?
• Does treasury have the bank's fraud contact at hand, outside business hours as well?
• Who can formally request a recall, and what documentation will the bank require?
• Do you report to law enforcement? In the US, reporting quickly to the FBI's Internet Crime Complaint Center (IC3) is recommended for BEC; other countries have their own reporting channels. Who does it?
• When is the cyber insurer notified? Does your policy cover social-engineering fraud, and are there conditions (such as verification callbacks) that affect coverage?

Module 3 — Investigation and fallout (T+49:00 to T+52:00)

Inject 6. IT investigates and finds an inbox rule on an AP clerk's mailbox that moves any email containing "invoice", "bank" or "payment" from the supplier's domain to a folder called "RSS Archive" and marks it as read.

Inject 7. Sign-in logs show a successful sign-in three weeks ago from an unfamiliar location, satisfied by multi-factor authentication, followed by the user granting consent to a third-party application with mail read and send permissions.

Inject 8. A second supplier emails asking whether a recent invoice from your AP clerk's address, with new bank details for your organisation, is genuine.

Discussion questions:

• What does the inbox rule tell you about the attacker's access and intent?
• MFA was satisfied: how could that happen (for example, adversary-in-the-middle phishing that steals a session token)? What does containment involve: password reset, revoking sessions and refresh tokens, removing the OAuth grant, reviewing forwarding and other mailboxes?
• How do you determine what the attacker read or sent? Do you have the audit logs, and for how long are they retained?
• Which suppliers and customers must be warned, and by whom? Who approves that message?
• Did the attacker have access to personal data in the mailbox? Who assesses whether this is a notifiable breach?

Discussion questions

• Controls: Which single control, consistently applied, would have stopped the loss? Is it written down and audited?
• Speed: How long, in exercise time, did it take from the supplier's call to the bank recall request? What slowed it?
• Ownership: Is BEC a finance incident, a security incident or both? Does your IR plan say?
• Detection: Would anything in your current monitoring have alerted on the inbox rule or the OAuth consent?
• Third parties: How do you verify suppliers' requests, and how do you help suppliers verify yours?

Curveballs / optional injects

• The compromised mailbox belongs to the CFO, and the attacker has sent a payment instruction to treasury "from" the CFO.
• The supplier's mailbox, not yours, was compromised: your controls worked partly, but the fraud started outside your perimeter.
• The bank recovers part of the funds; who decides how to handle the supplier's unpaid invoice?

Facilitator notes

Expected decisions. A mature team treats any bank-detail change as high-risk, verifies it by calling a number already on file, and requires a second person to approve. On discovering fraud, finance calls the bank's fraud line immediately while IT starts containment in parallel; nobody waits for the investigation to finish before requesting a recall.

Common pitfalls.

• Verification is done by replying to the same email thread or calling the number in the email.
• Finance and IT work sequentially rather than in parallel, losing hours.
• Containment stops at a password reset, leaving active sessions, refresh tokens and the OAuth grant in place.
• Nobody thinks to warn other suppliers or customers who may receive fraudulent emails from the compromised account.

Adapting the audience. For a finance-only group, simplify Module 3 into a briefing from IT and focus on controls, bank recall and supplier communication. For a security team, extend Module 3 with log sources, retention, token revocation and hunting for the same OAuth app across the tenant.

Evaluating the exercise

Related

• Facilitating a tabletop exercise
• Data breach and regulatory notification scenario
• Scenario library
• Glossary: inject, playbook, out-of-band communications