BEC Wire Diversion via Compromised Authenticated Vendor: PDF Bank Instructions From a Domain That Passed DKIM and DMARC

# BEC Wire Diversion via Compromised Authenticated Vendor: PDF Bank Instructions From a Domain That Passed DKIM and DMARC

Authentication is supposed to be the baseline guarantee: if DKIM passes and DMARC aligns, the message came from the domain it claims. That guarantee holds right up until the sending account is compromised. This attack arrived at a finance and accounts-payable team from an authenticated cold-chain logistics vendor domain, carried a PDF containing new ACH and wire routing instructions, and asked the recipient to start using them immediately. DKIM passed. DMARC passed. The composite authentication result was clean. None of that meant the request was legitimate.

Why the Sending Domain Appeared Authentic

The vendor domain involved is long-established (registered 1997) with a current registrar and an up-to-date WHOIS. The message carried a valid DKIM signature for that domain, and DMARC alignment succeeded against the p=quarantine policy. The ARC seal chain in the headers preserved the authentication results across relay hops, and Microsoft's inbound handler recorded compauth=pass with reason code 100.

The SPF result was a failure, but for an explainable reason. The message relayed through a Trend Micro outbound gateway (inpost[.]tmes[.]trendmicro[.]com) at IP 18[.]208[.]22[.]112, and that gateway IP is not in the vendor domain's SPF record. Security gateways commonly proxy mail for scanning without being listed in the domain's SPF, producing SPF failures that are expected and benign when the DKIM and DMARC chain is intact. ARC was present and valid, confirming that the original authentication state was preserved through the relay.

The most probable explanation for the full authentication picture is that the vendor's email account was compromised. An attacker with access to a mailbox at an authenticated domain gets all the cryptographic benefits of that domain's DKIM key and DMARC policy for free. There is no spoofing required. The attacker sends as the vendor.

The Payment-Diversion Request

The body of the message was three sentences. It stated that effective immediately, all future ACH payments should be directed to the account listed in the attached banking letter. It offered no invoice number, no purchase order reference, and no prior correspondence thread to establish context. The salutation was "Dear Valued Customer," generic across all recipients, which is inconsistent with genuine vendor-relationship correspondence where both parties know each other's names and ongoing transactions.

The signature block included a local phone number for an accounts-receivable contact. That number did not match the vendor's publicly listed contact details, a discrepancy that would be invisible to a recipient who had no reason to cross-check and who was seeing an email that appeared to come from a vendor they had already vetted and trusted.

The phrase "Effective immediately" is the key urgency mechanism. It frames the change as already decided and requiring only procedural compliance, not a request that invites deliberation. Business email compromise actors use this framing because it moves the cognitive load from "should I do this" to "how do I do this."

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

The Attachment as the Attack Vector

The payload was a PDF attachment with a filename referencing bank instructions and a vendor name (MD5: 6090900dc2f054dbcdf8124969babb98). The incident system recorded the file verdict as clean, which is accurate in the narrow technical sense: the PDF contained no malware, no exploit, no embedded script. It was a document stating fraudulent bank account numbers. This is how the most effective payment-diversion attacks work: the "malicious" content is human-readable financial instructions, invisible to any tool that measures payload threat by code behavior. The email spoofing and social engineering are in the request, not the file.

Defenders who rely on attachment scanning to catch BEC-style payment diversion will miss this class of attack consistently. The file is clean. The fraud is the content.

What Caught It

Our Adaptive AI scored the message as high-risk based on the behavioral pattern: an unsolicited, context-free banking-change request with urgency framing, a generic salutation inconsistent with an established vendor relationship, and an attachment whose filename explicitly references wire and ACH instructions. The message was a first-time sender to the recipient mailbox. That combination, an authenticated sender making a high-stakes financial request with no verifiable context, is a recognized BEC signature that authentication status cannot offset.

Defender Takeaway: Verify Bank Changes Out of Band, Always

No email should be sufficient authority to change payment routing details, regardless of the sender's authentication state. Finance teams should maintain a call-back verification policy using phone numbers sourced from internal vendor records or the vendor's official website, not from the email requesting the change. The test is simple: if you would need to call to verify a wiring address for a new vendor, you should apply the same step for any routing change from an existing one.

Indicators of Compromise