Weekly Security Report #4 — when trust becomes the weapon: vendor email compromise
This week's deep dive is the attack we respect the most, because it barely looks like an attack at all: vendor email compromise (VEC).
This week
In ordinary BEC, an attacker impersonates a trusted party from the outside. In VEC, they do not impersonate anyone — they are sending from the genuine, compromised account of a real supplier or partner. The mailbox is real. The signature is real. The thread is one that was already happening.
The pattern we see is patient:
- The attacker quietly controls a vendor mailbox, often for weeks.
- They read real threads to learn the relationship, the tone, the payment cadence.
- At the right moment — usually around an invoice — they reply in the existing thread with new banking details.
Because it is the real account replying to a real conversation, authentication passes, history matches, and the writing style is correct. Almost every traditional signal says "legitimate," because by every technical measure it is.
Technique in focus: there is nothing to spoof
This is what makes VEC so hard. The usual tells are absent:
- Authentication passes — SPF, DKIM, DMARC are all valid; it is the real domain.
- Sender history matches — you really have corresponded with this address before.
- No look-alike domain — there is no near-miss to catch, because it is the actual domain.
What is left to notice is the behavior in context: a banking detail that changed mid-relationship, a sudden shift in payment urgency, a request that does not fit the rhythm of how this vendor has always worked. The fraud lives in the deviation from an established pattern — not in any single property of the message.
What you can do
- Make any change to payment or banking details a hard verification step, even — especially — when it comes from a known, authenticated vendor inside an existing thread. Confirm out-of-band, on a number you already had, not one in the email.
- Watch for mid-conversation shifts: new account, new urgency, a new "accounts" contact CC'd in.
- Remember that passing authentication is not the same as being safe. VEC passes authentication by design.
WhiteHat helps here precisely because it does not stop at authentication. SA-01 models the relationship and SA-04 reads the intent, so a legitimate-but-deviant request can be flagged on context even when every header checks out.
Test a thread that asks to change payment details in the Analyze console and see how context, not authentication, drives the verdict.