Here is the pattern that shows up in almost every Vendor Email Compromise case we investigate. The details change every time. The structure never does.

A company with an established supplier relationship. Years of invoices, delivery confirmations, routine correspondence between an AP coordinator and a vendor contact. The kind of relationship where the emails are unremarkable. Where nobody thinks twice when the next one arrives.

The next one asks the AP coordinator to update the vendor's banking details. The language is clean. The tone is right. It references the correct outstanding invoice number. It arrives on a Thursday afternoon when the finance team is closing out the week.

What the AP coordinator does not know: the vendor's Microsoft 365 account was compromised weeks earlier. The attacker has been reading every message in the mailbox since. They know the invoice number because they found it in the sent items. They know the communication style because they read the last sixty emails. They know Thursday afternoon works best because the payment pattern told them so.

The payment clears. By the time the real vendor contacts the company asking about the outstanding invoice, the money is gone. The attacker is already inside another vendor's account, reading another set of emails, preparing another Thursday afternoon message for another AP coordinator at another company.

This is not a phishing attack that slipped through the filters. This is an attack designed, architecturally, to have nothing for the filters to catch. Understanding precisely why that is true is what this post is about.

Vendor Email Compromise does not find a gap in your technical defences. It walks through the front door using trust that your vendor earned legitimately and that your security system has been explicitly configured to respect. The entire security model built for CEO fraud and first-contact phishing is structurally blind to it.

The Single Architectural Reason VEC Is Invisible to Conventional Detection

Every email security system ever built rests on one foundational assumption: the attacker is an outsider trying to get in.

Secure Email Gateways check whether the sending domain is on a blocklist. Behavioural ML systems check whether the sender's communication pattern deviates from a known baseline. Anti-phishing policies check whether the sender is impersonating a protected domain. Authentication protocols check whether the sending infrastructure is authorised to send on behalf of the sending domain.

Every single one of these checks assumes the threat comes from an entity that is not already trusted. An unknown domain. An unusual sender. A mismatched display name. The entire security model: inspect the sender, find the anomaly, block the message.

Vendor Email Compromise destroys this model at its foundation. The attacker is not an outsider. They are operating from inside an account your security system explicitly trusts — a vendor's compromised email account with years of legitimate sending history, a verified domain, authenticated credentials, and an established relationship with your organisation.

There is no anomaly in the sender. The anomaly is in the purpose of what the legitimate sender is asking for. And detecting purpose requires a question that most email security architectures never ask.

Standard BEC — what your security stack was designed for:

• Attacker registers a lookalike domain to impersonate your CFO
• Domain is new, reputation is zero, impersonation policies fire
• Detection question: Is this sender who they claim to be?
• Answer: No. Blocked.

Vendor Email Compromise — what your security stack was not designed for:

• Attacker compromises a real vendor account with three years of clean sending history
• Domain is legitimate, authentication passes perfectly, reputation is spotless
• Detection question: Is this sender who they claim to be?
• Answer: Yes. Delivered.
• The question never asked: Has this legitimate sender ever done this before?

That single unasked question is where VEC lives. Answering it requires maintaining a relationship-level behavioural model for every sender-recipient pair — not a domain-level reputation score, but a complete history of what this specific account has ever communicated to this specific recipient. Most email security platforms do not do this. They track domains. Not relationships.

What Happens in the Weeks Before the Email Arrives

The most important thing to understand about VEC is that the attack begins long before the fraudulent email lands. The patience embedded in a well-executed VEC campaign is one of its defining characteristics — and that patience is what makes it structurally invisible to conventional detection.

Stage 1: The vendor account is compromised

The attacker gains access to a vendor's email account. In the attacks we observe most frequently this happens through one of four paths: credential phishing targeting the vendor's employees directly, AiTM session token theft where the vendor employee completes a genuine MFA challenge but the authenticated session is captured before redirect, password spraying against tenants with weak password policies, or purchased access from an initial access broker selling authenticated corporate sessions.

This initial compromise is entirely invisible to the target organisation. It happens in the vendor's environment. The target's email security stack has zero visibility into it. There is no alert, no signal, no change in the email traffic arriving from that vendor. From the target's perspective nothing has happened.

Stage 2: Silent reconnaissance inside the vendor's mailbox

The attacker does not immediately send a fraudulent email. That could be detectable. Instead, they read. Systematically. Everything. They are building answers to a specific set of questions:

• Who are the financially relevant contacts? Which name appears in invoice threads? Who approves payments? Who has authority over wire transfers?
• What is the payment pattern? How large are typical invoices? What is outstanding? Are payments processed quickly or do they require chasing?
• What is the communication style? Formal or informal? Long emails or short? Which sign-offs does the account holder use? What does an email from this person feel like?
• What operational context exists? Has the company mentioned any banking changes, restructures, or acquisitions? Is there a legitimate business event the attacker can reference to make a banking detail change plausible?
• What are the open invoices? Which specific invoice numbers are outstanding and for how much? Referencing a real invoice number removes the most common manual verification step.

At the end of this reconnaissance phase the attacker knows the vendor's relationship with the target organisation better than most people at the target organisation do. They have read every invoice, every payment confirmation, every scheduling query across the entire history of the account. The attack is already built. The email is just the delivery mechanism.

Stage 3: The fraudulent message — timed with precision

The email does not arrive on a random day. It arrives at the moment of maximum effectiveness — typically late in the week, when the finance team is in close-out mode and has less time to deliberate. It references the specific outstanding invoice the attacker found. It uses the communication style the attacker studied. It arrives with the full legitimate thread history sitting above it.

The message is short. Clean. Professional. Something like: our treasury team has migrated our accounts to a new banking provider. Please update your records and direct the outstanding balance on invoice [real invoice number] to the new account at your earliest convenience. That message passes every check your email security runs. Not because the checks failed. Because they are asking the wrong questions.

Stage 4: Covering tracks

After sending the fraudulent message, sophisticated attackers add an inbox rule to the compromised account to automatically delete replies from the target organisation — so the legitimate vendor never sees the response confirming payment was redirected. The attacker monitors the account for follow-up and intercepts it if needed.

In many VEC cases the vendor only learns their account was used for fraud when the target contacts them asking why the payment has not cleared. By then the money is already multiple hops through the financial system.

The reconnaissance phase is not preparation for the attack. It is the attack. By the time the email arrives the attacker has built the most informed, contextually accurate message anyone could possibly write about that payment relationship — because they read every message in it.

Why Every Detection Layer Fails Against VEC — Precisely

I want to go through this layer by layer because understanding exactly where each check fails is what makes the right detection architecture obvious.

Authentication — SPF, DKIM, DMARC: all pass

These protocols verify that the sending infrastructure is authorised to send on behalf of the sending domain. In a VEC attack the attacker sends from the vendor's actual email account, on the vendor's actual mail server, using the vendor's actual credentials. SPF passes. DKIM passes. DMARC passes. These protocols cannot determine who is sitting at the keyboard. They verify infrastructure, not intent. The infrastructure is legitimate. Authentication passes perfectly.

Sender reputation and domain age: clean

A vendor with a three-year relationship has a three-year sending history with no complaint reports, no blacklist entries, no suspicious volume spikes. The domain age is healthy. The sending infrastructure is Microsoft 365 or Google Workspace. Reputation systems are built to find domains that have previously done something bad. VEC uses domains that have never done anything bad. The signal they wait for will never come from a genuinely compromised legitimate account.

Content filtering and NLP analysis: no signal

A VEC message is written by someone who has read the vendor's prior correspondence and mirrored its style. Professional tone. Appropriate vocabulary. The specific phrase at the core of most VEC attacks — please update our banking details — appears in both fraudulent and legitimate email every day. NLP classifiers cannot distinguish between them because the content is genuinely identical at the language level. The difference is in the history of the relationship, not the words of the message.

Behavioural anomaly detection: wrong level of analysis

This is where the most sophisticated platforms should theoretically catch VEC — and where the domain-level architectural limitation becomes critical. Most behavioural systems track domain-level patterns: how many emails does this domain send per day, what content distribution, what recipient distribution. A VEC attack sends a single targeted message to a single recipient. The domain-level volume is unchanged. The domain-level content distribution shows nothing unusual.

The anomaly only exists at the relationship level: this specific account has communicated with this specific recipient across dozens of messages and has never once requested a banking detail change. That is a profound deviation from the relationship history. But detecting it requires tracking the history between this specific sender and this specific recipient — not the aggregate behaviour of the sender's domain across all recipients. Most platforms do not do this. The architecture required is fundamentally different.

Human judgment: actively undermined

Security awareness training for financial fraud focuses on CEO fraud — urgent wire requests from executives, first-contact pressure, mismatched sender addresses. VEC defeats this training on every dimension. The sender is a vendor, not an executive. The email is not urgent — it is framed as a routine administrative update. The sender address is exactly right. The prior thread history shows a legitimate long-running relationship. Every cognitive signal that training creates to flag CEO fraud is absent.

Employees are more likely to act on a trusted vendor's request than an executive impersonation precisely because their security training told them vendors are lower risk. VEC turns that training against them.

VEC does not need to bypass your defences. It carries credentials your security system was already told to trust. Every check passes. Every signal is clean. The only counterfeit is the intent — and none of your detection layers were built to evaluate intent.

The Detection Model That Actually Works: Relationship-Level Reasoning

Domain-level detection asks: how does this domain behave? Relationship-level detection asks: how does this specific sender communicate with this specific recipient — and does this message fit that history? These are categorically different questions. The first misses VEC entirely. The second catches it.

The bottom three rows are the attack types responsible for the largest financial losses in enterprise email fraud. Domain-level detection is structurally blind to all three. Not because it is poorly implemented — because it is asking the wrong question. Relationship-level detection catches all five because it asks: not what does this domain normally do, but what has this sender ever done with this recipient.

How TRACE Reads a VEC Attack: The Full Reasoning Chain

Let me show you exactly how our reasoning engine processes a VEC attack using a representative pattern from our production dataset.

The email:

From: billing@established-vendor.com — verified legitimate account, 3-year sending history

To: ap@target-company.com

Subject: Updated payment details — Invoice #47291

Body: Hi Jennifer, following up on invoice #47291. We recently migrated our banking to a new provider. Please update your records with the new account details below and direct payment when convenient. Thanks, Sarah

What every conventional check sees:

• SPF / DKIM / DMARC: Pass — legitimate account, authorised infrastructure
• Sender reputation: Clean — 3-year sending history, no complaints, no blacklist entries
• Content NLP: No phishing template match — professional language, appropriate context
• Invoice reference #47291: Real — exists in the relationship history
• Attachment: None. URL: None.

Conventional verdict: CLEAN. Delivered to inbox.

What TRACE sees:

• Step 1 — Relationship history: 71 messages over 28 months between this sender and this recipient. Topics: invoice delivery, payment confirmations, delivery scheduling. Banking detail change requests: zero. In 28 months and 71 messages this specific sender has never once introduced a banking detail change request to this specific recipient. This is the primary anomaly signal.
• Step 2 — Request classification: The message requests a permanent, irreversible change to payment routing. First-occurrence, high-consequence, irreversible financial action. No precedent. No context in the prior thread that would explain it.
• Step 3 — Intent mapping: Stated purpose is a banking migration. TRACE checks whether prior messages reference a migration, new payment platform, or treasury restructure. None. The stated purpose arrived with zero prior context in a relationship where operational changes are normally discussed.
• Step 4 — Header anomaly: The Reply-To address differs from the From address by one character. Replies route to an attacker-controlled address so the legitimate vendor never sees the response. This is consistent with post-compromise concealment behaviour.
• Step 5 — Peer context: No other recipient in the organisation received a banking detail change communication from this vendor in the same window. Genuine banking migrations are communicated to all accounts receivable contacts — not to a single AP coordinator referencing one outstanding invoice.
• Step 6 — Verdict: High-confidence VEC. Compromised vendor account. Payment redirection attempt. Blocked. Plain-language explanation surfaced to analyst: This sender has 71 messages with this recipient and has never requested a banking detail change. The request is first-occurrence, high-consequence, and irreversible. The stated banking migration has no prior context in the relationship history. The Reply-To header routes responses to a different address. Recommend out-of-band verification before any payment action.

Conventional verdict: CLEAN.  TRACE verdict: BLOCKED.  Resolution: 87 seconds. Full reasoning chain attached. No analyst investigation required.

The conventional system had seven signals all pointing to clean. TRACE had one signal — 71 messages with zero banking change requests — and the reasoning to understand what that absence means. The sophistication is not in the number of signals. It is in knowing which question to ask.

Three Things Every CISO Must Do About VEC Today

1. Ask your email security vendor the VEC question directly

Schedule a call. Ask one specific question: can your system detect a banking detail change request sent from a legitimate vendor account with a multi-year clean sending history, no malicious URL and no attachment, where the request type has never appeared in the prior communication history with the recipient?

Ask them to demonstrate this in your production environment. The output must include a plain-language explanation referencing the sender-recipient history directly — not a confidence score, not a rule match. If the vendor cannot produce that demonstration, their architecture does not operate at the relationship level and is not detecting VEC.

This is not a theoretical gap. It is active, unmitigated exposure in the next email your AP team receives from any established supplier. You need a yes with evidence, not a yes with a brochure.

2. Build an out-of-band verification process for banking changes and make it non-negotiable

This works regardless of what your technical stack detects. Any request to change banking details — regardless of how legitimate the sender appears, regardless of how long you have worked with them — triggers mandatory phone verification before any payment action is taken.

Three requirements for this to actually work. First: the phone number must come from your existing verified records — a prior invoice, a signed contract — not from the email requesting the change. Second: verification must happen before any payment system update. Third: the process must apply to every banking change request, not just suspicious-looking ones. VEC attacks are designed to not look suspicious. The process must trigger on the request type, not the suspicion level.

3. Update your incident response plan to include VEC-specific procedures

Most BEC response playbooks were written for CEO fraud. The response logic assumes the sender was fake. In VEC the sender was real and their account is compromised. Your response must include: immediate notification to the vendor that their account may be compromised, coordination with the vendor's security team to contain the account, review of all recent communications from that vendor across all recipients in your organisation, and forensic review of all payments made in the relevant window.

The vendor is simultaneously a victim and the vehicle for the attack. Your playbook needs to treat them as both simultaneously. Most organisations' current BEC playbooks do not have this procedure.

Final Thoughts

The pattern I opened with — the compromised vendor account, the weeks of reconnaissance, the Thursday afternoon email referencing the real invoice, the payment that clears before anyone questions it — is not unusual. It is the consistent structure of Vendor Email Compromise across every industry, every company size, every geography where we observe it.

What makes it stay with you is the precision of the preparation. Reading every prior email to get the tone exactly right. Finding the right invoice number. Timing the message for maximum compliance. Understanding the payment relationship better than most people at the target company do. That level of preparation used to require a patient, skilled human operator with weeks of time. Today it requires an AI agent and a compromised account that costs a few hundred dollars from an initial access broker. The barrier has collapsed.

We built TRACE specifically because of this attack class. Because the question that catches it — why is this trusted sender, in this established relationship, doing something they have never done before? — is not a question any system built on domain-level reputation or content-pattern matching can ask. It requires a different data model, a different architecture, and a reasoning engine that evaluates purpose in context.

The vendor's account being real is not the attacker's clever trick. It is the entire attack. Defending against it requires a system that understands the difference between a sender who is legitimate and a legitimate sender who is behaving in a way they never have before. That distinction is what relationship-level intent reasoning was built to detect.

Frequently Asked Questions (FAQs)

Q1: What is Vendor Email Compromise and how is it different from regular BEC?

Business Email Compromise is the broad category of email fraud involving impersonation of trusted parties. Vendor Email Compromise is a specific variant where the attacker does not impersonate a vendor — they compromise the vendor's actual email account and operate from inside it. In regular BEC the attacker creates a new or lookalike domain that your security tools can flag. In VEC the attacker uses a real account with a real relationship history that every security check validates as legitimate. The sending domain is genuine. The authentication passes. The reputation is clean. The only counterfeit is the intent behind the specific message — and detecting that requires a system that can reason about what this specific sender has and has not historically done with this specific recipient.

Q2: Why does multi-factor authentication not prevent VEC attacks?

VEC attacks compromise vendor email accounts through mechanisms that bypass MFA or occur after it has been successfully completed. AiTM session token theft captures the authenticated session cookie after a vendor employee completes a genuine MFA challenge — the attacker never needs the password or MFA code again because they captured the session issued after authentication. Initial access brokers sell already-authenticated sessions, bypassing authentication entirely. Additionally, MFA at the target organisation provides no protection against VEC because the attacker is not trying to log into the target's systems — they are attacking through the vendor's already-compromised account. The target's MFA deployment is irrelevant to an attack that originates externally.

Q3: What is the difference between domain-level and relationship-level email security?

Domain-level security builds behavioural models at the sending domain — tracking how a domain behaves across all the messages it sends to all recipients. It detects anomalous domains: new, low-reputation, suddenly high-volume, impersonating a protected brand. Relationship-level security builds models at the individual sender-recipient pair — tracking the specific history of what this sender has communicated to this recipient across every prior message. It detects when a specific sender in a specific established relationship does something that has never appeared in that relationship before — regardless of whether the domain-level behaviour looks normal. VEC is invisible at the domain level and detectable at the relationship level. Moving to relationship-level detection is an architectural change, not a configuration change.

Q4: What should an out-of-band verification process for banking changes look like?

Three non-negotiable requirements. First, it must trigger on the request type — any banking detail change request from any vendor, regardless of how legitimate it appears. Triggering on suspicion level defeats the purpose because VEC attacks are designed to not look suspicious. Second, the phone number for verification must come from pre-verified sources — a prior invoice, a signed contract — not from the email requesting the change. Third, verification must be completed before any payment system update or processing. Post-hoc verification after the change is not verification — the fraudulent payment may already be in process.

Q5: How do we know if our current email security platform can detect VEC?

Ask your vendor one direct question: can your system detect a banking detail change request sent from a legitimate vendor account with a multi-year clean sending history, no malicious URL, no attachment, where the request type has never appeared in the prior communication history with the recipient? Ask for a live demonstration in your production environment. The output must include a plain-language explanation of the specific relationship-history signals that drove the verdict — not a confidence score, not a rule match. If the vendor cannot produce that demonstration their architecture does not operate at the relationship level. VEC is the most financially damaging email attack pattern in enterprise environments and it warrants a direct capability confirmation.

Q6: How do attackers gain access to vendor email accounts?

Several pathways appear most frequently in the attacks we observe. Credential phishing targeting the vendor's employees directly. AiTM session token theft where a vendor employee completes a genuine MFA challenge but the authenticated session cookie is captured before redirect. Password spraying against tenants with weak password policies. And increasingly, purchasing authenticated account access from initial access brokers who specialise in selling corporate account sessions. In all cases the compromise happens at the vendor's environment. The target organisation's security tools have no visibility into an external tenant security failure. There is no signal and no alert until the fraudulent message arrives.

Q7: What makes VEC harder to detect than standard CEO fraud?

Three specific factors. First, the sender is genuine — there is no impersonation to detect, no domain mismatch to flag, no first-contact signal. Second, the relationship history provides legitimacy — prior correspondence makes the fraudulent message feel like a continuation of a normal business relationship. Third, security awareness training works against the target — employees have been trained to be suspicious of executive impersonation and first-contact requests, not of established vendor communications. VEC specifically exploits the trust that security awareness programmes built into vendor relationships. The cognitive profile of a VEC attack is the opposite of what training teaches employees to be suspicious of.

‍