A Vendor Payment Change With Nothing to Block

A regional agricultural commodities supplier opened a notice from one of the food manufacturers it sells into. The message was calm, well formatted and entirely free of urgency. It announced that the customer was adding a new preferred payment method, a single use virtual credit card that would let suppliers collect faster, and it asked for nothing immediately. It said only that in the coming weeks a payment processor would be in touch to complete enrollment, and supplied a toll free number and an email address in the meantime.

There was no link in the body. There was no malicious attachment. The only files present were the four small images that make up a corporate signature block. And the message had genuinely travelled the customer's own mail infrastructure, so every authentication check a receiving gateway could run came back satisfied.

The entire attack was the instruction.

What the Message Actually Asked For

The notice was signed by a vice president of procurement at the customer, with a real corporate street address and a properly rendered signature graphic. Virtual card programs are a genuine accounts receivable modernization, which makes them useful cover: a supplier who has heard of the practice has no reason to treat the announcement as unusual.

The operational content came down to three strings. A toll free phone number. An email address whose local part was the customer's own brand name, sitting on a domain that had nothing to do with the customer. And a promise of follow up contact, pushed out into the future so the supplier would treat an unsolicited call about its banking details as expected correspondence rather than a cold approach.

Notably, the notice contained no account or routing number, and never asked the supplier to change an existing remit to address. That absence is the design: new bank details invite comparison against the details already on file, and comparison is where payment fraud usually dies. This one gave nothing to compare, only an appointment.

Why the Headers Had Nothing to Object To

The message reached the recipient through the customer's real mail path. SPF passed with the envelope sender aligned to the customer's own apex domain, first registered in the late nineteen nineties and continuously in use since. It was relayed by the customer's cloud mail security gateway and then by a hosted email signature service that stamps corporate branding onto outbound mail, carrying that service's own processing header. Both are ordinary pieces of a corporate mail stack.

Microsoft's composite authentication verdict came back as a pass with the highest confidence reason code, the receiving platform's own determination that the message is not a spoof of the domain it claims. It is the strongest single signal in these headers.

DKIM is the one place the record does not resolve neatly. Intermediate authentication headers show no signature at some hops, while the earliest sealed hop records a DKIM pass on the customer's domain, and the two cannot be fully reconciled from the raw headers. Nothing in the record establishes whether a mailbox at the customer was directly compromised or whether the customer's name was simply usable this way. What the record does establish is narrower and more important: the message really did traverse the customer's own infrastructure. Authentication answered the question it exists to answer, and that question was never whether the payee was real.

See Your Risk: Calculate how many threats your SEG is missing

The Payee Nobody Could Verify

The domain in the contact address, prioritypayables[.]com, is where the case turns. Our analysts could not tie that domain, or the toll free number beside it, to an established payments company on public record. There was no verifiable corporate identity behind the party the supplier was being told to trust with its banking details.

Two things about that domain defeat a common heuristic. First, it was not newly registered. It had sat on a mass market registrar for well over a year, long enough to clear every reputation window and newly observed domain rule that would catch a domain stood up the week of the attack. Age is not evidence of legitimacy, only of patience.

Second, it was not a lookalike. It made no attempt to imitate the customer's name, so there is no typosquat or homoglyph relationship to detect. A generic, plausible payables brand is a harder problem than imitation: with no reference string to compare against, string distance detection has nothing to measure. The name only has to sound like a company that might exist.

A DMARC Pass Under a Policy That Enforces Nothing

The customer's DMARC record publishes a policy of none, with the same for subdomains, at full percentage. Under RFC 7489, that instructs receivers to take no action on alignment failures and to send reports only. A pass in that configuration is genuine, but it is a materially weaker assurance than the same pass under quarantine or reject, because the domain owner has declined to make failures consequential.

That is the argument for treating DMARC enforcement as a supply chain control rather than a compliance checkbox. A vendor left at a monitoring only policy exports risk to everyone receiving mail in its name, and those recipients cannot tell the difference from the headers.

What Flagged It

Our Adaptive AI analyst, Themis, flagged the message at 89 percent confidence, drawing on content signals, community signals and sender analysis together rather than on any single reputation lookup. The recipient was additionally tagged as a high value mailbox, which is precisely the population a payment redirection attempt targets. A human analyst then reviewed the finding and approved quarantine of the affected mailbox.

That layering is the point. Nothing here was individually anomalous: the sender, the path, the signature, the tone and the request were all plausible. The finding came from the combination.

Nothing to Detonate, Nothing to Sandbox

Zero payload cases like this one are the uncomfortable end of the business email compromise spectrum. There is no URL to detonate and no attachment to sandbox. The four signature images held no embedded links, forms or scripted content, so attachment analysis correctly found nothing, and correctly finding nothing is not the same as the message being safe.

The 2024 Verizon Data Breach Investigations Report puts pretexting, which is overwhelmingly business email compromise, at the top of the social engineering types it tracks, with a median transaction of roughly 50,000 dollars. The 2023 FBI IC3 Internet Crime Report counted about 2.9 billion dollars in reported losses of the same type, overwhelmingly in attacks that look like this one: no malware, no exploit, just a believable instruction.

The Control That Actually Works Here

Every technical layer in this chain behaved correctly and the message still arrived, so the break point is procedural.

Any change to a payment method, remittance destination or banking detail must be verified out of band, on a phone number already held in the vendor master record, never a number supplied in the message requesting the change. Enrollment with a new third party processor is the same class of change and deserves the same treatment. Pair that with dual approval on vendor master edits, and train finance staff that a non urgent, well written, correctly authenticated notice is not evidence of anything beyond correct authentication. Both CISA and NIST frame social engineering defense around verification behavior rather than message inspection.

A clean authentication result tells you a message travelled the path it claimed. It does not tell you the payee at the other end exists.

Indicators of Compromise

MITRE ATT&CK Mapping