The Wrong Tax Form Broke a Flawless Vendor Email

Over roughly a week, four mailboxes at a large consumer hygiene-products manufacturer received the same notice from a long-standing supplier. The subject opened with ACTION REQUIRED. The body announced that the supplier's account was being moved to a newly named LLC, and it attached two documents to support the change: a bank letter carrying a new remit-to address and new banking details, and a completed IRS tax certificate. Every authentication check passed. Not partially, and not under a permissive policy, but end to end under an enforced one, because the message genuinely was sent from inside the supplier's own Microsoft 365 tenant.

Nothing in the Envelope Was Fake

The header block reads like a textbook example of a message you should trust. SPF passed, with the connecting address in a Microsoft 365 outbound range and the envelope sender aligned to the supplier's domain. DKIM passed with a verified signature under the supplier's own signing domain and the default Microsoft 365 selector, not a third-party relay key. DMARC passed, and the ARC chain records the policy it passed under: quarantine, applied to the apex domain and to subdomains, at one hundred percent. That is enforced, not monitor-only. Composite authentication returned a pass at full confidence.

A registration lookup closes the last door. The supplier's domain was created in 1994, is active, and is held by the real operating corporation, with no sign of a lapsed or hijacked registration. There is no attacker-registered lookalike: no same-day domain, no homoglyph, no display-name trick over free webmail. The cryptographic trust here is entirely real, so there is nothing in the technical envelope to block. Blocking the sender would mean blocking a genuine supplier.

How that access was obtained is not established: the record shows only that the message left the supplier's own authenticated infrastructure. Whether someone stood up a mailbox inside a compromised tenant or took over an existing account, it does not say. Both routes produce the same header block, which is exactly the problem.

The Attachment That Contradicted the Story

The second attachment is where the whole thing falls apart, and it has nothing to do with email security.

It is a completed IRS Form W-8ECI: the Certificate of Foreign Person's Claim That Income Is Effectively Connected With the Conduct of a Trade or Business in the United States. That form exists for exactly one population, non-US persons and entities. A newly formed, US-domiciled company that will receive ordinary domestic payments from a US customer does not file a W-8 series form at all. It files a Form W-9. Submitting a foreign-payee certificate to justify a domestic entity change is a category error, and it means the fraud's own supporting paperwork disagrees with the story the email is telling.

That is a document-species mismatch, and no email control grades one. Both PDFs were scanned clean by antivirus, the correct verdict, because the payload here is persuasion rather than code. A scanner can confirm a PDF is not weaponized. It cannot ask whether the tax form inside belongs to the kind of entity the email claims to be creating. The banking details in the letter are not reproduced here; they are beside the point. The tell was never the numbers. It was the form.

Two other details reinforce it. Research into the claimed transition found no authoritative public announcement of it, and the contact addresses printed inside the message did not appear on the supplier's own authoritative pages. A change large enough to redirect an enterprise customer's payments does not usually happen quietly.

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

A Deferred Instruction Is a Patient One

The pretext inverts the urgency most people are trained to spot. It opened with a generic salutation to a valued customer, then told recipients explicitly not to change their vendor records, remit-to address, or payment process yet. Everything was to stay as it was until a stated changeover date a few weeks out, when the new details would apply.

That reads like governance, and it does three things for an attacker. It removes the pressure cue that triggers suspicion. It buys a runway in which nothing looks wrong because nothing has happened. And it arranges for the fraudulent change to be made later, from documents already sitting in the mailbox, once the message that delivered them has scrolled out of the review window. Separating the instructions from the action is a scheduling trick, not a technical one.

The spread fits that patience. The same notice reached four mailboxes at the same customer across roughly a week, and one copy was forwarded onward inside the organization with an FW prefix. That forward matters more than the repetition. A notice circulating internally under an employee's own name has stopped being external mail and become a colleague's message.

What Actually Surfaced It

Automated triage bucketed this one as bulk gray mail rather than routing it to the phishing queue, and no confidence score for it exists in the record at all.

What surfaced it was a person. One recipient reported the message with a four-word comment: they did not know the sender. The case was then approved manually and all four copies moved to Junk, roughly two to three weeks after the earliest one arrived. That is a slow clock for a payment-diversion attempt, and the honest measure of the detection surface. With no malicious link, no malware, no lookalike domain, and no authentication failure, the remaining signals are behavioral: a payment-detail change arriving unrequested, a corporate transition with no public trace, a first contact from a mailbox nobody recognizes, and supporting documents that do not match each other. Those are the patterns Themis, our Adaptive AI weighs together, because individually not one of them is disqualifying.

The 2024 Verizon Data Breach Investigations Report puts pretexting, mostly business email compromise, at the top of the social-engineering category, with a median transaction near $50,000. No amount was ever named in this case, and that figure sizes the category rather than this incident.

Where the Control Has to Live

Treating a full authentication pass as a trust decision is the mistake this message was engineered around. Authentication answers whether a domain's DNS is lying about who sent the mail. Here it was not lying. The fraud lived in the business-process layer, one level above anything SPF, DKIM, or DMARC can measure, so the control has to live there too.

Any change to banking details, remit-to addresses, or payment routing gets verified out of band, by calling a number already on file from an established relationship, never one supplied inside the request. That rule has to hold even when the request comes from a genuinely legitimate mailbox, because vendor email compromise means it usually does. Finance teams should also be told that supporting documents are evidence to be read, not decoration to be filed. A tax certificate for the wrong class of taxpayer is disqualifying, and visible before the money moves. CISA's phishing guidance argues the same, and NIST's definition of phishing turns on deception of the recipient, not provenance of the packet.

This message had honest custody of the right infrastructure, and it still lied. Read the paperwork, and confirm bank changes on a phone line you already trusted. Where that needs enforcing rather than encouraging, business email compromise protection catches the pattern before the payment run.

Indicators of Compromise

MITRE ATT&CK Mapping