Vendor Account Takeover: An Invoice That Passed Every Check

The invoice looked exactly the way a routine invoice should. It came from a foodservice-equipment supplier the recipient had done business with for years, sent from the vendor's own EDI and invoicing mailbox, routed out through an internal Exchange host and the vendor's own Mimecast-fronted relay. The recipient was a group purchasing organization, a procurement firm that coordinates buying across the B2B foodservice supply chain, and this supplier was a known quantity. Two of its mailboxes received the thread. Nothing about the sender, the routing, or the branding looked out of place.

That was the problem. Every technical signal a gateway could check came back green, because the message was not a forgery. It was a genuine email from a genuine account that had quietly fallen under someone else's control.

A Clean Bill of Authentication Health

When our team examined the headers, the authentication story was flawless. SPF passed, with the sending IP properly authorized for the vendor's domain. DKIM passed, carrying a valid cryptographic signature from the vendor's own domain. DMARC passed with an alignment result of action=none. Microsoft's composite authentication (compauth) returned pass with reason 100, the cleanest possible verdict.

There was no lookalike domain to catch, no freshly registered typosquat, no relay that broke alignment mid-flight. The mail genuinely originated from the supplier's real infrastructure and traveled through their real security gateway. For a filter that treats authentication as the primary trust signal, this message was indistinguishable from every legitimate invoice that vendor had ever sent. DMARC, defined in RFC 7489, tells a receiver whether a message is aligned with the domain it claims to come from. Here the answer was an honest yes. Alignment is not the same as intent.

The One Thing That Changed

The fraud lived in the body text, not the metadata. Inside an otherwise ordinary invoice thread was a first-time instruction: the vendor's remittance address had changed, and payment for the referenced invoice should now be directed to the new details. No urgency theatrics, no threats, just a small administrative update tucked into a routine payment cycle.

That single request is the entire attack. This is vendor email compromise, a subtype of business email compromise in which an attacker rides a trusted supplier's real identity to redirect money. Because the relationship was established and the sender was authentic, the change-of-remittance request inherited all of the vendor's accumulated trust. If a finance team processes it, the next payment lands in the attacker's account and the fraud is not discovered until the real vendor asks why the invoice is still outstanding.

The 2024 Verizon Data Breach Investigations Report names pretexting, which is dominated by business email compromise, as the top social-engineering pattern, with a median BEC transaction of roughly 50,000 dollars. The 2023 FBI IC3 Internet Crime Report put reported BEC losses near 2.9 billion dollars. Payment diversion is not a fringe technique. It is one of the most lucrative plays in email fraud, precisely because it needs no malware to succeed.

What Was Inside the PDF

The email did carry an attachment, a PDF invoice generated by a common reporting tool and, notably, mislabeled at the MIME layer as application/octet-stream rather than a standard PDF content type. Static analysis surfaced something worth noting: one embedded JavaScript object, compressed inside a FlateDecode stream, alongside six separate Additional Actions (the /AA dictionary entries) that can trigger on open or page events.

On paper that sounds alarming, and it is worth watching. But the details matter. The antivirus verdict was clean, with no known malware signature. The document held no credential-harvesting form fields and no external links pointing anywhere off the page. The scripting artifacts were present, yet the actual mechanism of this attack was never the PDF. It was the remittance-change request in plain text. Treating the attachment as the whole story would have missed the point, and over-indexing on a clean scan verdict would have missed the fraud entirely.

Why Authentication Was Never Going to Catch This

This case is a clean illustration of a structural gap. SPF, DKIM, and DMARC verify that a message came from where it claims to come from. They say nothing about whether the person behind the account should be trusted, or whether the instruction inside is legitimate. When the account itself is compromised, authentication becomes a rubber stamp on the attacker's message.

The only reliable tell here was behavioral. A supplier who had invoiced this buyer routinely, suddenly, for the first time, asked to reroute payment. That deviation from an established pattern is what IRONSCALES is built to see. Our Adaptive AI learns the normal shape of each sender relationship, so a first-time change-of-remittance request from a long-known vendor reads as an anomaly regardless of how cleanly the message authenticates. More than 36,000 security professionals across 18,000 organizations rely on that behavioral layer to catch exactly the fraud that passes every cryptographic check.

Indicators of Compromise

MITRE ATT&CK Mapping

• T1566.001: Phishing, Spearphishing Attachment (invoice PDF as the lure prop)
• T1204.002: User Execution, Malicious File
• T1657: Financial Theft (the payment-diversion objective)

How to Defend Against Vendor Email Compromise

Authentication remains necessary, but it cannot be the last line. Pair it with behavioral analysis that flags first-time remittance or bank-detail changes, and require out-of-band verification of any payment-instruction change before funds move. A thirty-second phone call to a known number defeats this entire class of attack. For the mailbox-takeover angle that starts it, account takeover protection catches the anomalous access and sending behavior that precedes a fraudulent invoice, and dedicated business email compromise protection scores the intent of the message, not just its headers. Guidance from CISA reinforces the same principle: reduce the reward, not just the delivery.

See You Next Time

Clean authentication is a floor, not a ceiling. When the fraud rides a real account, the money follows behavior, so that is where your detection has to live too.