Because legitimacy in the thread does not prove legitimacy in the authority. Attackers can use a compromised mailbox, copied correspondence, or a lookalike domain to preserve the story while changing the bank account. The risk comes from trusting conversation continuity as evidence of authorisation, which it is not.
Why legitimacy in the thread is not the same as legitimacy of authority
invoice fraud succeeds because people often check whether the message chain feels consistent, not whether the payment instruction is independently authorised. A believable reply history can be manufactured, replayed, or hijacked, so the email itself becomes weak evidence. What matters is whether the bank details were validated through a separate trust path, not whether the wording looks familiar.
A compromised mailbox is especially effective because it preserves tone, timing, and context. A copied thread can make a fraudulent invoice look like a routine continuation of an existing relationship, which lowers suspicion at the exact moment the attacker changes the account destination.
Legitimate-looking email also survives simple inbox scrutiny when a lookalike domain, display-name spoofing, or forwarded correspondence is used. Those signals can fool a quick review, but they do not prove the sender controls the account, the invoice origin, or the payment authority behind it.
What actually breaks in a business email compromise invoice flow
The failure is usually an authority verification failure, not a content verification failure. The organisation accepts the message as proof because it appears to continue an existing conversation, then treats the new bank details as if they were part of the same trusted workflow. That is the control gap attackers exploit in business email compromise and invoice redirection.
This is why the problem persists across well-written messages, familiar signatures, and realistic attachments. The attack does not need to make the email look obviously fake, only plausible enough to get the recipient to skip an out-of-band confirmation step. Once the payment path is changed, the fraud can complete before anyone notices the mismatch.
For a practical defensive view, Email Identity and BEC Guide covers the email-authentication and payment-verification controls that matter when invoice fraud is trying to piggyback on a trusted thread.
Why the attacker wants continuity, not novelty
Continuity is the main advantage. A fake invoice that arrives in a familiar thread, from a familiar-looking sender, or from an account that already has trust history is more likely to be processed quickly. The attacker is not trying to invent a new story, but to alter one detail inside a story the recipient already believes.
That is why copied correspondence and mailbox takeover are so effective. They reduce the number of cues that would normally trigger review, and they let the attacker reuse established norms such as monthly billing cycles, vendor names, or prior approvals. The fraud is successful when the recipient mistakes familiarity for verification.
Phishing Guide is useful here because invoice fraud often rides on the same impersonation and lookalike-domain techniques used in broader phishing campaigns, even when the message appears to be part of a normal commercial exchange.
Risk and Threat Considerations
The risk is not just mistaken payment, it is the collapse of the organisation’s trust boundary between conversation history and authorisation. Once staff accept thread continuity as evidence, attackers can redirect funds with very little technical sophistication, especially when they control an inbox or can replay prior correspondence.
Failure mechanism: The recipient validates the invoice by recognising the thread, sender, or tone, instead of independently confirming the payment instruction through a separate channel. That lets the attacker change the account number while leaving the surrounding narrative intact.
Impact: The immediate consequence is misdirected payment, but the wider impact can include repeated fraud against the same vendor relationship, delayed recovery, and loss of confidence in email as a trustworthy business channel. In regulated environments, the event may also trigger financial-crime reporting or internal escalation requirements.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while OWASP ASVS, NIST SP 800-53 Rev 5, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V10 — OAuth and OIDC | Thread hijacking and lookalike sign-in paths depend on authentication integrity. |
| Recommendation — Verify sender and workflow identity with phishing-resistant authentication before trusting payment changes. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Invoice fraud often follows mailbox compromise or stolen credentials that enable message tampering. |
| Recommendation — Rotate and protect credentials that can alter invoices or payment instructions. | ||
| CIS Controls v8 | CIS-5 — Account Management | Compromised mailboxes and reused accounts are a common path to invoice fraud. |
| Recommendation — Review and secure accounts that can approve or relay payment instructions. | ||
| MITRE ATT&CK | T1566 — Phishing | Invoice fraud commonly uses impersonation and trusted-thread abuse to induce payment changes. |
| Recommendation — Map invoice-fraud lures to phishing techniques and hunt for mailbox takeover indicators. | ||
| NIST SP 800-63 | 3 — Digital Identity Guidelines, Authentication and Lifecycle Management | Invoice fraud is reduced when authentication and account recovery are harder to spoof or hijack. |
| Recommendation — Use stronger authenticator and recovery processes for staff who can change payment instructions. | ||
Practitioner Guidance
What to prioritise: Treat the bank account as the item that must be verified, not the email. If the invoice changes payment details, change the review path as well and require a separate confirmation step before release.
What to verify: Confirm whether the sender identity was authenticated by something outside the thread, and whether the payment change was approved through a channel that the attacker could not silently inherit. The question is not whether the message looks normal, but whether the instruction is independently authorised.
Decision rule: If the request changes payee, bank, or urgency, assume the thread may be compromised until proven otherwise. If the same vendor is asking for a new account or a one-off exception, escalate to manual verification rather than treating the request as routine.
Practitioner takeaway: The safest control assumption is that email continuity is a clue, not an approval signal, so payment workflows must verify authority outside the inbox every time the destination changes.
Related resources from NHI Mgmt Group
- Why do crypto fraud campaigns remain effective against legacy email security?
- Why do phishing attacks remain effective even with secure email gateways?
- Why do socially engineered attacks remain effective even when email filtering is in place?
- Why do email attacks remain effective even when organisations use MFA?