The Invoice Authenticated Cleanly for the Wrong Company

The message that landed in the accounts-payable role mailbox at a regional agricultural commodity processor ran four sentences of plain text. Process the ZoomInfo invoice today. The ACH details are on the invoice. Contact the billing contact for wire details. No links, no urgency theatrics, no misspellings.

The display name was the exact name of one of the company's own senior executives, an identity the platform already held in its VIP directory.

Then the authentication summary came back clean on every line. SPF passed for the sending subdomain, DKIM passed with a signature aligned to the From domain, DMARC passed, composite authentication returned 100, and Microsoft scored the message SCL 1 and marked it not spam. Nothing in the header had been forged.

The signature that passed belonged to an unrelated business on the other side of the world, with no stake in the invoice, no relationship to the vendor and no connection to the recipient.

The Authentication Was Real and It Covered a Stranger

This is not a spoofing story. An email service provider had domain authentication configured for that company's apex domain, a normal and correct setup: the provider signs on the customer's behalf, so the DKIM signature carries the customer's domain, SPF passes for the envelope subdomain, and DMARC passes because the signing domain aligns with the From domain. No ARC chain, no per-hop divergence, no broken alignment at a relay. The bounce path was a VERP-style return address the provider generates automatically, encoding the recipient's own address, which is why it is described here rather than printed.

How the attacker reached that sending identity is not established in the record. An account takeover would produce these headers, and so would an attacker signing up and configuring a subdomain. Either way that company is a bystander, which is why its mailbox and domain are withheld.

Alignment as defined in RFC 7489 answers one narrow question: did a domain authorize this message. One did, honestly. It was simply not the domain whose identity the message claimed, and not a domain anybody in the transaction had heard of.

The Only Forgery in the Header Was a Name

The platform's impersonation engine made the comparison a gateway does not. It already knew the executive's real address on the company's own domain, saw the same name arrive from an external sending domain, and fired an exact display-name impersonation tag with the impersonated party marked as a VIP.

The recipient side matters too. This did not go to a named individual but to a role mailbox for the payment function, staffed by people whose job is to process invoices from companies they have never met. A stranger's invoice is not an anomaly there. It is the work.

Two Escape Hatches, and Neither Ever Authenticated

The body named a billing contact for wire details at zoominfo[.]it. The real vendor operates on zoominfo[.]com and does not own that country-code lookalike, which WHOIS shows was created two days before the message arrived, its record updated minutes later. A clerk who followed the instruction and emailed that contact would have been talking to the attacker.

The Reply-To header pointed somewhere else again: a third domain, unrelated to both the sending domain and the vendor brand. A clerk who simply hit reply and asked for the wire details would also have reached the attacker, by a different route and without making a decision. That domain returned no WHOIS data at all, so its role here is verified while its ownership and age are not, which is why it is neither published nor labelled.

Two different mechanisms: one hatch is instructed, the other silent. Neither domain appears in any authentication check, because neither ever sent anything. Authentication covers the transport, not the addresses a message tells you to use.

A Thread That Never Happened

Underneath sat a fabricated two-hop forwarded thread, two separator lines deep, inventing an exchange that did not exist: the supposed vendor contact sending the invoice, and the executive replying with an approval, "Got it, we'll take care of this." Both hops were attributed to addresses the attacker controlled or claimed. The thread also lifted in the impersonated vendor's genuine public corporate street address as a prop, and repeated the invoice number the body cited, so the story held under a skim.

The effect is to move the request from approval to execution. Nobody on the payables side is being asked to judge whether the spend is legitimate. Somebody senior already did, apparently, further up the thread.

On the attachment: the body directs the reader to ACH details on one, and no attachment was available in the record for analysis, so nothing can be said about what it held.

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

No dollar amount appears anywhere in this record. For scale, the 2024 Verizon Data Breach Investigations Report puts pretexting, most of it business email compromise, as the leading social-engineering type with a median transaction near $50,000, and the 2023 FBI IC3 report counts roughly $2.9 billion in reported BEC losses in a year.

What Scored It

With clean authentication and nothing to scan, the evaluable material was identity and behavior. Themis, the IRONSCALES Adaptive AI analyst, weighed the display-name-versus-sending-domain mismatch against the content language, the payment urgency and community resolutions of similar incidents, and returned 56 percent confidence with three labels: VIP impersonation, credential theft and VIP recipient. One mailbox was affected, the message was quarantined and closed as permanently deleted, and a human analyst approved the verdict.

The middle label deserves an honest note: credential theft is not the tidiest description of a wire-fraud attempt with no links and no login page in it. The score and the impersonation signal carried the decision, not the taxonomy, helped by the resolution history of the 35,000+ security professionals across 17,000+ organizations in the IRONSCALES community.

Where the Control Has to Sit

Stop reading a clean authentication summary as a verdict about who wrote a message. The check that mattered was an identity comparison, not a cryptographic one, which is the argument for scoring business email compromise on relationship and behavior rather than header validity.

Flag Reply-To divergence as its own signal, extend that suspicion to any contact address the body tells the reader to use, and weigh the age of every domain named in a payment instruction. A domain created days before it surfaces as a billing contact is a finding by itself.

Then keep the process rule in front of the technology, consistent with CISA phishing guidance and the behavior NIST describes: bank details and first-time invoices get confirmed out of band, on a number the finance team already holds, never on one supplied by the message requesting the money. One scope note, since it gets conflated: enforcing DMARC on your own domain stops somebody spoofing you, and would have done nothing here, because this message never claimed your domain.

Indicators of Compromise

MITRE ATT&CK Mapping

See You Next Time

Three domains touched this message and only one had to prove anything. The two aimed at the money never sent a byte. Check back tomorrow.