SPF Pass, DKIM Pass, DMARC Pass. Still Phishing.

Every Authentication Check Said Trust It

The email passed SPF. It passed DKIM. It passed DMARC with compauth=pass reason=100. The sending infrastructure was Google Workspace, relayed cleanly into the recipient's Microsoft 365 tenant. No spoofing. No header manipulation. No forged return path.

And it was phishing.

A procurement team at a global specialty ingredients manufacturer received what looked like a routine purchase order from a known Mexican supplier contact. The subject line read "Envio de documento Orden de compra MAT 5685." The body contained a single line claiming the message was auto-generated by SAI ERP software. Attached: a PDF invoice for $1,726.31 USD.

The sender's display name was an exact match for a contact the team had corresponded with before. But the email address was wrong. The real contact sends from compras2@[supplier-stem][.]net. This message came from compras@[supplier-stem][.]com[.]mx.

Cousin Domain, Exact Display Name

This is vendor email compromise executed with uncommon discipline. The attacker did not try to spoof the legitimate domain. Instead, they registered a cousin domain (same brand stem, different TLD) and set up full email authentication: SPF records designating Google's outbound servers as permitted senders, DKIM signing with the cousin domain, and a DMARC policy that aligned everything.

The result: a message that clears every gateway check designed to catch spoofing. Because it is not spoofed. The domain is real. The DNS is configured. The signatures are valid. The authentication infrastructure is working exactly as designed.

What authentication cannot tell you is whether the person controlling that domain is the person you think they are.

The FBI IC3 2024 Annual Report documents $2.9 billion in adjusted losses from BEC attacks alone. A growing share of those losses involve supply chain compromise, where attackers impersonate vendors rather than executives. The Verizon DBIR 2024 confirms that social engineering remains the top action variety in breaches, and pretexting (the technique behind invoice fraud) now outpaces standard phishing in BEC scenarios.

Inside the Invoice

The PDF attachment (ordcomp_20260427_042yhd.pdf, MD5: cd5d4d96dfefd03026c4ed216256b410) was technically clean. No embedded JavaScript, no OpenAction triggers, no AcroForm credential-harvesting fields. Static analysis returned no malicious indicators.

That is the point. The payload is not the PDF. The payload is the trust.

The invoice itself was well-crafted: vendor name, line items, delivery details, and a total of $1,726.31 USD. Small enough to fly under most approval thresholds. A clickable link in the PDF footer pointed to hxxps://www[.]castelec[.]mx, which resolves to legitimate AWS-hosted infrastructure belonging to an ERP vendor (clean reputation, not a malicious destination). The link appeared to be standard branding from the ERP software that generated the document.

The email body was minimal by design. One line in Spanish: "Se envia Orden de compra con folio: MAT 5685 Correo electronico enviado desde SAI ERP." No greeting, no signature block, no contact details. This brevity is actually consistent with how ERP systems generate automated dispatch notifications, which makes it harder for recipients to spot as unusual.

The X-Mailer header, however, listed MailBee Objects (ActiveX) 9.2, a Windows COM-based email library. That is an odd choice for a message that was submitted through Gmail's SMTP infrastructure. Legitimate ERP dispatch systems typically use their own SMTP integration or the platform's native sending library, not a third-party ActiveX control.

What Headers Cannot See

Here is where the MITRE ATT&CK framework maps the technique chain:

The attacker targeted three members of the procurement team simultaneously, all within the same organization. This is not spray-and-pray. This is targeted business email compromise with reconnaissance behind it: the attacker knew the supplier relationship, the contact name, and the buyer-side roles.

The Microsoft Digital Defense Report 2024 highlights that attackers increasingly invest in authenticated infrastructure specifically to defeat gateway controls. When the cost of registering a domain and configuring DNS is negligible compared to the potential payout, authentication becomes a tool for the attacker, not just the defender.

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

Traditional email security would have passed this message without hesitation. SPF, DKIM, DMARC: all green. Attachment scan: clean. Link reputation: clean. Content analysis: low-urgency, short, consistent with automated ERP output.

What flagged the email was a behavioral signal. The platform maintained a learned mapping: the display name of a known supplier buyer is associated with the address compras2@[supplier-stem][.]net. When a message arrived bearing that exact name but originating from compras@[supplier-stem][.]com[.]mx, the sender fingerprint mismatch triggered an impersonation alert.

This is the gap that authentication alone cannot close. SPF validates the domain. DKIM validates the message integrity. DMARC aligns them. None of these protocols evaluate whether the human identity claimed in the display name matches the historical communication pattern for that identity.

The email was automatically classified as phishing and quarantined across all four affected mailboxes.

Defending When Authentication Is Not the Signal

For security teams dealing with supply chain email risk:

1. Sender fingerprinting over authentication. If your email security relies solely on SPF/DKIM/DMARC to determine trust, fully authenticated cousin domains will sail through. Behavioral baselines that map display names to known sending addresses catch what authentication cannot.

1. Watch for cousin domains in your supplier ecosystem. Monitor for domain registrations that share brand stems with your top vendors. Services like CISA's cybersecurity advisories and commercial brand monitoring tools can surface these before they are weaponized.

1. Treat invoice PDFs as pretexts, not payloads. A clean attachment scan does not mean a safe email. In VEC campaigns, the PDF is the social engineering vehicle. The damage happens when the procurement team processes the invoice through normal channels, redirecting payment to attacker-controlled accounts.

1. Scrutinize minimal-body ERP notifications. Legitimate ERP-generated emails typically include system footers, reference numbers traceable in the buyer's own ERP instance, and sender addresses matching known vendor domains. A one-line body with no contextual metadata is a red flag, even if the format looks plausible.

1. Verify out of band. When a known supplier contact appears to send from a new address, pick up the phone. A 30-second call to a verified number costs nothing compared to a misdirected payment.