Every Auth Check Passed, and There Was No Link to Scan

An accounts payable team at a marine-industry equipment manufacturer opened a helpdesk ticket notification in early June 2026 and found a request to prove they were themselves. The message asked for five specific items: the vendor ID on their account, the registered contact address attached to that vendor record, the last three paid invoice numbers along with their matching amounts, the last four digits of the bank account held on file, and the purchase order number plus details for the invoice currently in flight. It described the exercise as a new verification process.

There was no sign-in page. No attachment. No shortened link and no tracking redirect. The instruction was simply to reply.

That absence is the whole story. Take the credential-harvest landing page out of a phishing message and there is nothing left for URL reputation, sandbox detonation or attachment analysis to evaluate. The only links in this message were the self-help pages that the recipient's own external-sender warning banner injected, and all of them scanned clean. What actually landed in the mailbox was a paragraph of pretext and a numbered list.

The Sending Domain Was Never Spoofed

The header-From address was a support subdomain belonging to a real multinational consumer packaged-goods company, and it resolved exactly the way it was supposed to. SPF returned pass, with the receiving gateway recording that the sending host was a permitted sender for that subdomain in published DNS. The mail was relayed through the outbound mail host of a major enterprise IT service management platform and carried that platform's own machine-generated notification headers. This was a genuine platform notification produced by genuine tenant configuration, not a hand-assembled forgery pointed at a lookalike domain.

DKIM was absent. The message was unsigned, with no signing domain to evaluate. DMARC passed anyway, with an action of none, because alignment was satisfied through SPF rather than through a signature. Microsoft composite authentication returned pass with reason 100, and the transport hop assigned a spam confidence level of 1. Every mechanism a receiving gateway had available reported that this mail was allowed to be where it was.

None of that is a failure of the standards. DMARC decides whether a domain owner authorized a sending path and whether the visible From domain aligns with the authenticated identifier, and the current specification in RFC 9989 is explicit that the outcome is a domain-authorization decision. This was a correct authorization decision about an incorrect message.

What the Headers Prove and What They Do Not

Our analysts landed on the same distinction. A passing SPF result proves that the sending tenant was permitted to send for that subdomain. It does not prove that a human being with legitimate business intent composed what the tenant sent, and the internal assessment recorded that the relay evidence was insufficient on its own to declare the message legitimate. The classification note went further and described the pattern as potential tenant misuse, which is the honest ceiling on what the evidence supports.

It is worth being precise about what remains unverifiable. Only the final hop into the recipient environment carries an authentication trail. The invoice conversation quoted below the request, including a mid-thread instruction telling recipients to route all further correspondence to the helpdesk mailbox, is plain body text. Quoted history in an email body has no independent authentication of its own, so whether that earlier exchange happened as printed cannot be confirmed in either direction. Nor does the record establish how the ticket came to exist. Build detection from the provable part: a first-time sender, on authorized infrastructure, asking for financial reference data by reply.

Two Corporate Identities in One Message

The body branding named one corporate entity's accounts payable helpdesk. The header-From domain was a support subdomain belonging to a different corporate entity. That mismatch across domains was the single most legible anomaly in the message, and it is easy to skim past on mail that reads like an automated ticket update.

The context stretched further than the branding did. The invoice conversation the request attached itself to involved a supplier billing marine-industry customers for unpaid invoices, and a consumer packaged-goods manufacturer has no visible role in a marine-parts payables thread. The recipients had no business relationship with the brand whose tenant sent the mail, so the strongest available signal was not technical at all. It was the absence of any reason for that sender to be asking.

The company on the other end of that tenant is a bystander in this case, not an actor. Its infrastructure was real, its DNS was correct and its platform behaved as designed for a tenant configured to send helpdesk notifications. That is precisely why nothing identifying it appears in this teardown.

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

Why a Reply-Only Ask Is Worth the Effort

Partial bank digits, three real invoice numbers with amounts and a live purchase order reference are not the fraud. They are the corroboration that makes the fraud work later. A payment-redirection request that cites the correct vendor ID and the correct recent invoice history reads like continuity inside an existing relationship rather than an interruption of it. The harvest and the payout are separate messages, often weeks apart, which is why the harvest step gets underweighted in incident review.

The economics support the patience. The 2025 FBI IC3 Annual Report recorded $3,046,598,558 in reported business email compromise losses inside $20.877 billion of total reported cybercrime losses. The 2026 Verizon Data Breach Investigations Report puts the human element in 62% of breaches and phishing at 16% of initial access vectors, and now tracks pretexting separately at 6%. Pretexting is the relevant column here, because no exploit and no malware were involved. MITRE ATT&CK catalogues the behavior as phishing for information, a technique defined by soliciting the data rather than stealing it, paired with impersonation. NIST frames phishing itself around the deception, not the delivery mechanism, which is the correct lens for a message with no payload.

The Signals That Survived the Authentication Pass

Because every authentication check passed, the verdict had to come from elsewhere. The sender was a first-time correspondent for the recipient environment and carried a high sender risk assessment. Our Adaptive AI weighed the request pattern against relationship history rather than against a signature, the incident was automatically resolved as phishing, and it was tagged as vendor email compromise. No human reviewer overrode that verdict.

Two near-identical ticket-generated copies went out two days apart, producing four deliveries across two mailboxes. Three of the four were permanently deleted, and a colleague of one recipient reported the message independently, which is the part of the outcome that no gateway configuration produces on its own.

Controls for a Message With Nothing to Scan

Treat any inbound request for vendor IDs, invoice histories or partial banking details as a verification event, not a correspondence event. Confirm out of band against a contact already on file, never against a number or address supplied inside the request, which is the same discipline CISA's phishing guidance recommends for payment-related pretexts. Put change control around vendor master records so a bank detail update cannot be validated by a single email thread. Then make sure detection can act on relationship context and request semantics, not reputation alone, because here the reputation was earned honestly by infrastructure with no part in the ask. That is the gap business email compromise protection has to cover.

Indicators of Compromise

MITRE ATT&CK Mapping