A supplier emails new bank details for a real, unpaid invoice - what attack is this and why doesn't patching help?
answer
- nothing executes anywhere
- the invoice is real and really owed
- changes where, not how much
- process control, not endpoint control
- verify on a number you already had
basics
~10 sPayment diversion: the operator changes where a genuine, already-owed payment lands. No link, attachment or malware appears anywhere in the chain, so patching, attachment scanning and endpoint controls have nothing to act on.
solid answer
~50 sThis is payment diversion, the invoice-fraud form of business email compromise. The operator has learned that a real invoice is outstanding and asks, in plain prose, for the remittance account to be updated. Nothing executes: no attachment, no link, no credential prompt, no software on any host. Every system in the chain - mail, the finance application, the banking portal - behaves exactly as designed, and the payment is authorised by a person with the standing right to authorise it. That is why a patched estate, an up-to-date endpoint product class and a mail gateway tuned for payloads all miss it: none of them is looking at whether a *business fact* changed on someone's say-so. The controls that bite are process controls - verifying a banking change out of band on a number you already held, and separating whoever edits supplier bank details from whoever releases the payment.
go deeper
Be ready to name the attack and say plainly that nothing executes: no link, no attachment, no code. Then name one process control that would have stopped it, such as calling the supplier back on a number from the contract.
Explain why each technical control class never engages, and identify the one dependency the attack cannot substitute: a banking detail changeable on the strength of an inbound message.
Show you can separate the lookalike-domain variant from the compromised-supplier-mailbox variant and demonstrate that both are answered by the same out-of-band step, because message properties are all forgeable or borrowable.
Own the argument that this loss category is a finance-process risk with a finance owner, and that budget spent on payload inspection buys nothing here while a verification step in accounts payable buys almost all of it.
## What the attack is Payment diversion (often filed under *business email compromise* or *invoice fraud*) redirects a payment the victim already intends to make. The operator does not manufacture a debt; they attach themselves to a real one. A supplier has genuinely delivered, a genuine invoice is genuinely due, and the only thing the operator changes is the destination account. The chain is short and entirely social: 1. **Learn the relationship.** Who supplies you, roughly what you owe, and when you pay. 2. **Reach the accounts-payable inbox** as that supplier - from a lookalike domain the operator registered, or from the supplier's own mailbox if it has been taken over. 3. **Ask for one change**: "we have moved banks, please update remittance details for invoice INV-40118." 4. **Wait for the payment run.** The clerk updates the vendor master, an approver releases the payment, the money lands in an account the operator controls. 5. **Draw the money down** before anyone notices, usually onward through further accounts. Discovery is almost always external: the real supplier chases an unpaid invoice weeks later. ## Why the technical defences miss it entirely Strike out every technical control in a normal estate and ask what it would have acted on: | Control class | What it inspects | What this attack presents | |---|---|---| | Patching / vulnerability management | Exploitable software flaws | No software is exploited | | Attachment sandboxing | Files that execute | A plain-text request, or an ordinary PDF invoice | | Link rewriting and web filtering | URLs the user may click | No URL is needed | | Endpoint controls | Code running on a host | No code runs | | Multi-factor authentication | Logins to your systems | Nobody logs into your systems | The operator's entire technique budget is prose. That is also its economics: it is cheap, it needs no exploit and no infrastructure beyond a domain and a mailbox, and a single success can be worth six figures. Cheapness is why it is one of the highest-loss categories reported year after year while producing no interesting artefacts at all. ## Where it *does* touch The attack has exactly one dependency it cannot substitute: **a banking detail must be changeable on the strength of an inbound message.** Everything else is negotiable - the domain, the wording, the invoice number, the urgency, even a phone that answers if you call the number in the signature block. So the countermeasures are the ones that attack that dependency: - **Out-of-band verification** of any change to supplier bank details, using a contact route you already held from onboarding or the signed contract - never a number, address or portal supplied in or alongside the request itself. - **Segregation of duties**: the person who edits the vendor master is not the person who releases the payment against it. - **A second approver above a value line** - useful, but note it governs *how much* leaves, not *where it goes*; on its own it can be sized around. - **Standing supplier expectation**: tell suppliers at onboarding that you will never action a bank change by email alone, so a genuine change follows the verified path. ## Two variants worth separating - **Lookalike sender.** The operator registers a domain that reads like the supplier's and controls it completely. Sender authentication on that domain passes, because it is genuinely their domain. - **Compromised supplier mailbox.** The mail is genuinely from the supplier's real domain and real mailbox; the compromise is in *their* estate, not yours. Nothing you can inspect about the message separates it from legitimate correspondence. Both land the same request, and both are answered by the same out-of-band step. This is the reason experienced people refuse to argue about the message and argue about the *process*: any property of the message can be forged or borrowed, but a phone number you wrote down before the relationship went hostile cannot. ## What a strong answer sounds like Name the attack, state that it carries no payload, say which defensive classes therefore never engage, and finish on the single dependency and the control class that removes it. Weak answers call it "phishing" and stop at the mail gateway; that is the wrong shelf, because there is nothing for a gateway to catch.
- The supplier's own mailbox really was taken over - does that change your answer?Not the classification and not the countermeasure. It is still payment diversion, and now the mail is genuinely from the supplier's real domain, so anything you could inspect about the message looks perfect. The out-of-band callback on a number you held from onboarding still separates the request from the change, because it reaches a human who never sent it.
- Does MFA on the finance team's mailboxes prevent this?No. Nobody authenticates to anything of yours. MFA protects your accounts from being used by someone else; here your staff use their own accounts, correctly, to do a job they are authorised to do. It only helps against the separate case where your own mailbox is the one taken over.
- At what point does the money become unrecoverable?Once the receiving account is drawn down or the funds are pushed onward, which is usually the point of the exercise and happens fast. Recall depends on the beneficiary bank still holding the balance and being willing to freeze it, so the practical window is hours to a couple of days, not weeks.
It is a change-of-address form filed at the post office in someone else's name. The postal system works flawlessly and delivers every letter exactly as instructed - to the wrong door.
saying these in an interview costs you the question
- Calls it phishing and stops at the mail gateway
- Assumes malware or a malicious link must be in there somewhere
- Believes MFA on finance mailboxes prevents it
- Treats it as an IT problem rather than a payment-process one
- Assumes the invoice itself must be fake