Business email compromise has a reputation problem. Most organizations know the name, have seen it in security awareness training, and believe their email security handles it. What they're missing is how much the attack has changed — and how little of what they've deployed actually addresses what BEC looks like in 2026.
Microsoft's Q1 email threat landscape report, published April 30, 2026, documented approximately 10.7 million BEC attacks in the quarter. That's not the number that should concern security leaders. It's the composition. The majority of those attacks were described as "low-effort, generic outreach messages" — meaning the high-volume, template-based campaigns that security tools are reasonably good at catching. The targeted, sophisticated attacks that actually cost organizations money are a different problem entirely.
How the Money Actually Disappears
Before talking about evolution, it helps to be concrete about what a successful BEC attack looks like at the moment of conversion — because this is the part most security content skips.
End-to-end scenario — Vendor Email Compromise leading to payment diversion:
1. Attacker compromises a vendor's email account (through credential phishing or AiTM)
2. Attacker monitors the mailbox for 2-4 weeks, reading ongoing correspondence with target organizations
3. Attacker identifies an open invoice or pending payment in an active thread
4. Attacker sends an email — from the real vendor address, continuing the real thread — notifying the target's finance team of a "banking detail change effective immediately"
5. Finance team receives the request from a known address they've been corresponding with for months, in a familiar email thread, with no technical indicators of compromise
6. Finance team updates the payment record and processes the next scheduled payment to the new account
7. By the time the real vendor queries the missing payment, the funds have moved through multiple accounts and are unrecoverable
The entire attack happens within the target's normal business processes. No malware, no technical intrusion, no suspicious login — just a fraudulent instruction that fit exactly into an expected workflow.
The conversion point is almost always a financial workflow with time pressure: payment due dates, end-of-quarter processing, "urgent" bank change requests. Attackers who monitor target mailboxes understand the operational rhythm. They time the fraudulent request to coincide with periods when the finance team is moving fast and scrutinizing less.
BEC Variants: What You're Actually Facing
BEC is an umbrella term covering several distinct attack patterns. Treating them as the same problem leads to misaligned defenses.
|
Variant |
How it works |
Why it converts |
|
CEO Fraud |
Impersonates executive requesting urgent wire transfer |
Authority + urgency, usually no approval chain |
|
Vendor Email Compromise (VEC) |
Uses compromised real vendor account for invoice fraud |
Trusted domain, existing relationship, passes all auth checks |
|
Invoice Fraud |
Spoofed or lookalike domain sends fake invoice |
High volume makes scrutiny difficult |
|
Payroll Diversion |
Requests HR to update direct deposit details for an employee |
Single point of approval, low scrutiny, delayed discovery |
|
Attorney/Legal Impersonation |
Impersonates law firm or legal counsel for confidential transaction |
Intimidation, NDA framing prevents internal discussion |
VEC is the highest-converting variant in 2026 precisely because the email comes from a real address. No spoofing, no lookalike domain — just a compromised account being used to send a fraudulent request. Traditional defenses are blind to it.
What BEC Actually Is in 2026
The definition of BEC has expanded well beyond its original form. The FBI's initial framing — an attacker impersonates an executive to redirect a wire transfer — still happens. But it represents a fraction of what the category now covers.
Vendor Email Compromise (VEC) has quietly become the dominant variant. The Abnormal AI 2026 Attack Landscape Report, published April 2026, found that VEC now accounts for 61% of all BEC attacks. Instead of impersonating an internal executive, attackers compromise a legitimate vendor's email account and use it to deliver fraudulent invoices or redirect payment details. The email comes from a real, authenticated address with a clean reputation — it passes SPF, DKIM, and DMARC checks. No filters catch it on technical grounds because there's nothing wrong with the address.
The danger compounds in the details: billing account update requests carry a 26.5% compromise rate according to the same report, compared to under 1% for routine invoice inquiries. Asking a finance team to reroute ongoing payments to a new account is the single highest-converting BEC lure. The request feels administrative. The urgency is built in — ongoing payments, not future ones. And it comes from an address the organization has been receiving legitimate correspondence from for months.
AI-Generated BEC: The Quality Gap Closes
For years, BEC emails were detectable by native speakers who knew what executive communication actually looks like. AI has eliminated that signal almost entirely.
AI now generates approximately 40% of all BEC emails (Vipre Security Group data, 2025). The result is correspondence that matches the vocabulary, tone, and communication style of the individual being impersonated — because it's built from scraped LinkedIn posts, company communications, press releases, and public data. A CFO who routinely uses specific phrases in investor communications will see those exact patterns reflected back in a well-targeted BEC attempt against their finance team.
The 1,265% increase in phishing emails since the launch of ChatGPT (StrongestLayer, February 2026) isn't just about volume. It's about the collapse of the quality floor. Previously, mass BEC required either skilled operators for high-quality attempts or poor quality at scale. AI makes high quality scalable.
AiTM as the New BEC Entry Point
The most significant structural change in BEC is upstream: how attackers get the account access they need to launch convincing campaigns.
Traditional BEC relied on domain spoofing or account compromise through credential phishing. Both have well-understood defenses. What replaced them is adversary-in-the-middle phishing — and the combination of AiTM with BEC has produced a qualitatively different threat.
In January 2026, Microsoft documented a multi-stage AiTM and BEC campaign targeting energy sector organizations. The attack chain: phishing email from a pre-compromised trusted vendor → AiTM proxy captures victim's session cookie post-MFA → attacker uses compromised session for reconnaissance → compromised internal identity launches intra-organizational and external phishing → BEC operations against finance teams. Multiple organizations were compromised in a cascade that started from a single vendor account.
The key insight from that campaign: resetting a compromised user's password did not remediate the intrusion. Session cookies remain valid after a password reset. Attackers had registered new MFA devices before the security team responded. By the time remediation began, the attacker had lateral access that password rotation couldn't touch.
This is what modern BEC infrastructure looks like. It starts with AiTM phishing — a technique that bypasses every form of MFA except FIDO2 — and converts account access into a trusted identity for downstream attacks. Understanding the offensive mechanics of how these initial access chains are constructed helps security teams build detection logic that catches the attack before BEC activity begins. This technical breakdown of phishing attack vectors covers the full offensive side in depth.
Why Legacy Defenses Fail
Legacy email security defenses use pattern matching — known-bad signatures, malicious IP reputation, recognized phishing templates. They're effective against commodity attacks built from reused infrastructure.
AI-generated BEC contains no known-bad signatures. There's no malicious link to scan, no attachment to detonate in a sandbox, no sending IP on a blocklist. It's a text-based email from a real or realistically spoofed address, containing a request that fits normal business communication patterns. Pattern matching has no surface to grip.
Legacy security awareness training has the same problem. The traditional advice — "look for poor grammar, check the sender address, hover over links before clicking" — was built around observable indicators that no longer reliably exist. A 2026 BEC attempt may have flawless grammar, come from a real vendor's compromised account, and contain no links at all. Every trained behavior the user has been taught to apply finds nothing to apply to.
StrongestLayer's 2026 analysis is blunt about it: "Relying on the 'Human Firewall' is a failed concept against 2026-level AI attacks." This doesn't mean training is worthless — compliance requires it, and it builds baseline awareness. But counting on end-user detection as a primary control against AI-generated, vendor-impersonation BEC is a risk acceptance decision, not a mitigation.
Red Flags: What to Train Finance Teams to Recognize
The behavioral signals that precede a successful BEC conversion are consistent across campaigns. Finance teams who know what to look for can interrupt the attack before the payment processes.
In the email:
- Urgency that wasn't there before — "must be processed today," "end of quarter," "CEO is traveling and unreachable"
- A request that arrived in a thread with existing history, but the specific ask feels out of character for that vendor or contact
- Payment or banking details changing mid-engagement, especially close to an invoice due date
- New IBAN or routing number with an explanation that sounds rehearsed ("we switched banks," "our old account is being audited")
- Request sent outside the vendor's normal business hours — a German supplier emailing at 2am their time is worth a second look
In the relationship context:
- First-ever bank change from a vendor you've worked with for years
- Change request arriving right after a new contact at the vendor is introduced
- Request for confidentiality ("please don't loop in anyone else on this")
- Slightly different email address than the one you've previously used — single character changes, hyphenation, or new domain suffix
Mini-playbook for finance teams — what to do when a bank change request arrives:
1. Do not update payment records from the email alone
2. Call the vendor contact on a phone number from your existing records — not any number provided in the email
3. Confirm the change verbally, ask them to resend from their official address if needed
4. Log the verification call (date, time, who confirmed)
5. Apply a 5-business-day hold before the new banking details become active for payments
6. If the vendor expresses urgency about removing the hold — treat that as a red flag, not a reason to comply
The entire point of the callback is that an attacker who controls the vendor's email cannot control a phone call to a number that existed before the attack began.
Three Layers of Defense — Aligned to What They Actually Stop
The defenses against BEC map to three distinct layers, and each layer stops a different phase of the attack. The most common failure is investing heavily in one layer while leaving another entirely unaddressed.
Technical controls (email authentication, gateway filtering, Conditional Access) stop a meaningful volume of commodity BEC — domain spoofing, known-bad sending infrastructure, simple impersonation attempts. They don't stop VEC from a compromised real account, or AI-generated emails that contain no detectable payload.
Process controls (dual approval, callback verification, change-of-bank holds, segregation of duties) stop conversion — the moment where a fraudulent instruction becomes a fraudulent payment. They operate independently of whether the email was technically suspicious. A callback on a verified number stops VEC even when the email itself is perfect.
Human controls (awareness training, red flag recognition, escalation culture) reduce the probability that an employee acts on a BEC attempt alone and without verification. They're necessary but not sufficient — their role is to create friction and escalation opportunities, not to be the last line of defense.
Organizations that have good technical controls and no process controls will still lose money to well-executed VEC. Organizations that have strong process controls and weak human controls will still have employees sometimes bypass the process under pressure. All three layers need to be functional.
What Actually Reduces BEC Risk in 2026
Payment workflow controls that don't depend on email trust. The highest-converting BEC vector is payment rerouting. The most effective mitigation isn't catching the email — it's requiring out-of-band verification for any request that changes payment details. A phone call to a pre-verified number, following a documented process that finance staff understand and consistently apply, removes the vulnerability that BEC exploits at the point of conversion.
Conditional Access with compliant device requirements. AiTM-based BEC starts with session token theft. If access to corporate email requires a compliant, managed device, session cookies replayed from an attacker's machine fail the compliance check. This doesn't prevent the phishing attempt, but it prevents the attacker from converting a stolen session into operational BEC access.
FIDO2 / passkeys for high-value accounts. Finance, executives, HR — the accounts BEC attackers want most are also the accounts most worth protecting with phishing-resistant authentication. FIDO2 cryptographically binds authentication to the legitimate domain, making AiTM token capture impossible for those accounts. It's the only MFA type that addresses the AiTM problem at the technical layer.
Post-authentication monitoring. Given that AiTM attacks succeed before traditional detection fires, the detection opportunity is in post-authentication behavior. Inbox rule creation within minutes of a sign-in from a new device is the canonical AiTM-to-BEC signature. Microsoft Entra sign-in logs combined with Exchange Online audit logs for rule creation events catch this at the persistence-establishment phase — before any BEC emails are sent. Unfamiliar device registration on an account is the other early indicator worth alerting on immediately.
Behavioral AI for email analysis. The vendors who have made the most progress against AI-generated BEC are those that analyze intent and communication context rather than matching known patterns. These approaches compare new messages against established communication baselines — flagging deviations in tone, vocabulary, and request type that wouldn't register as suspicious based on pattern matching but would appear anomalous relative to how that sender actually communicates.
Process Controls: The Defenses That Actually Stop BEC
Security technology stops many attacks. BEC is specifically designed to bypass security technology and land on a human decision-maker. That means process controls — not email filters — are the last meaningful line of defense at the conversion point.
Dual approval for payment changes. Any request to modify payment details — bank accounts, wire instructions, payroll records — requires approval from a second person through a channel other than email. One person receives the request; a second confirms it. The confirmation happens by phone to a pre-verified number on file, not to a number provided in the change request email.
Callback verification on verified numbers. When a vendor requests a bank change, call them back. Not on the number provided in the email — on the number in your vendor management system, or the number you've used in previous calls. This catches even fully compromised vendor email accounts, because the real vendor will tell you they didn't make the request.
Change-of-bank verification period. Implement a policy: new banking details cannot be used for payment until 5-7 business days after the change request, during which the change is confirmed separately. This kills the urgency pressure attackers create.
Segregation of duties. The person who can request a bank change and the person who can approve it should be different individuals. Finance teams with a single point of approval for payment modifications are structurally vulnerable to BEC regardless of their security awareness level.
These aren't technical controls. They're workflow decisions. They work because they remove the email channel as the sole authorization mechanism for high-value financial actions. BEC attacks that route through email can't compromise a phone call to a number that was verified before the attack began.
Detection: What to Watch Before the Money Moves
The indicators that precede BEC activity are detectable — but only if you're looking in the right places.
Inbox rule creation. After AiTM-based account compromise, attackers create inbox rules within minutes: forward all emails to an external address, delete messages containing words like "security," "suspicious," or the attacker's own domain. A new inbox rule appearing immediately after a sign-in from an unfamiliar device is the single most reliable early BEC indicator.
New device registration on high-value accounts. AiTM attacks frequently result in the attacker registering a new MFA device. An unfamiliar device appearing on an executive, finance, or HR account — particularly outside business hours — warrants immediate investigation.
Sudden bank detail change requests from known vendors. Any incoming request to update payment information for an existing vendor should trigger a manual callback workflow, regardless of whether the email passes all authentication checks.
Email forwarding to external addresses. Automatic forwarding rules redirecting copies of emails to addresses outside the organization are a persistence mechanism and an intelligence-gathering tool. They're set up early, run quietly, and often go unnoticed until fraud is discovered.
Login anomalies on vendor accounts. If you have visibility into your critical vendors' security posture, sign-in alerts on their key contacts can surface VEC attacks before your organization becomes a target.
The False Confidence Problem
SPF, DKIM, and DMARC tell you the email came from an authorized sender. They say nothing about whether the content is fraudulent. A fully compromised vendor account sending a fake invoice passes every technical authentication check — because the account is legitimate, the domain is legitimate, and the sending infrastructure is legitimate. The email *should* be there.
Systems that have been trained to detect malicious links, attachments, and known phishing templates fall short against current BEC tactics. A text-based email from a trusted domain requesting a bank account change contains none of those signals. They only see a normal business communication.
Security awareness training helps, but the evidence on BEC specifically is sobering. AI-generated emails written in the exact vocabulary and communication style of the impersonated sender defeat the behavioral recognition skills that training builds. Telling employees to "check for unusual requests" is reasonable advice. It's not a control.
If the payment process relies on email as the authoritative channel for financial instructions, the security technology layered around that process is defending against the wrong attack.
The Difficult Reality
BEC success rates haven't declined despite better tooling and more awareness, because the attacks have adapted faster than the defenses. The organizations suffering the most are those still calibrating their controls to 2020-era BEC — spoofed domains, obvious impersonation attempts, grammar mistakes. The organizations doing better have accepted that the threat is fundamentally different and have built controls around that reality: verifying financial instructions out-of-band, protecting high-value accounts with FIDO2, monitoring for post-authentication compromise indicators, and treating session security as part of email security.
Email authentication and filtering are not the last line of defense. They stopped being sufficient for BEC when BEC stopped relying on anything they could reliably detect.