Perfect Authentication, Invented Conversation

A regional sales manager at a large automotive manufacturer received a message that looked like a file-share notification. The layout was the familiar shared-document pattern popularized by Google Workspace: a company name in bold, a line saying a spreadsheet had been shared with the recipient and two other people, and one blue button reading Open. The name in bold was the recipient's own employer. Outlook had tagged the subject as external and posted its unfamiliar-sender banner.

Everything below that banner was built to argue with it. Under the notification block sat a quoted reply chain: a stack of replies attributed to colleagues, every one of them addressed on the manufacturer's own corporate domain, ordered the way a thread reads after months of back and forth. The newest quoted message asked the recipient to look over the previous month payment details and to acknowledge the aspects they wanted to confirm while a billing team finalized the process.

None of those messages had ever been sent. One HTML body, composed once, delivered from a single mailbox with no connection to the manufacturer.

Why every authentication check passed

The header story is the reason this case is worth reading. SPF passed. DKIM passed, signed by the sending domain itself. DMARC passed against a published policy of reject. Microsoft composite authentication returned a pass with the strongest reason code it issues. No spoofing at the protocol level, no relay that broke alignment, no softfail anybody had to interpret.

That is because the sending domain was not attacker scaffolding. It belongs to a long-established export and garment business, registered more than seven years earlier through a small regional hosting provider, with no relationship to the automotive industry or to the recipient. Its DNS reads like a company that sends real commercial mail: an SPF record naming a specific address range plus an include for a large cloud mail-sending service, a live DKIM key, and DMARC set to reject. The connecting host was that domain's own mail server, at an address inside its own published SPF range, handing the message to Microsoft 365 with no authentication break anywhere in the path.

DMARC, as specified in RFC 7489, resolves exactly one question: did the domain in the From header authorize this message. Here the honest answer was yes. Domain age, a strict policy, a signing key, and a clean sending history are all reputation inputs, and this message arrived holding all four. A throwaway domain registered the same week would have held none.

One infrastructure detail did not line up. The public address record for that domain resolved to an IP whose reverse DNS pointed at an unrelated mail transfer agent hostname on a different hosting network. Plenty of legitimate hosting looks untidy, so that blocks nothing by itself, but it fits the two available explanations: the mail estate was compromised, or whoever controls it is renting out its reputation (T1584.001).

The conversation nobody had

Quoted history is not a protocol feature. It is characters in a body. When a mail client draws an indented block with a From line above it and a timestamp beside it, nothing has been checked or signed. The visual grammar of a reply chain is a convention your client renders on request, and anyone editing HTML can render it too.

So the attacker wrote the full cast. A supposed internal colleague opened the chain, a supposed human resources contact replied, a supposed procurement contact replied under that. Each invented participant carried an address on the manufacturer's real corporate domain, and the timestamps were spread across the preceding months so the exchange read as a slow-moving billing matter rather than a cold request. The From address itself was a generic information alias at the export domain, wearing a plausible personal display name that appeared nowhere in the invented thread.

That apparatus exists to answer questions before the reader thinks to ask them. Is this internal? Addresses on your own corporate domain say so. Has this been discussed? The chain runs months deep. Am I the right person? A colleague already routed it here. By the time a reader reaches the single button, the message has manufactured its own authorization, which is impersonation used as infrastructure rather than as a disguise.

The signature block from the wrong industry

One fabricated participant gave the game away. The signature block beneath the supposed procurement contact did not name the automaker at all. It named a large health insurer, in an unrelated sector, as that person's employer, sitting inside a thread otherwise carefully dressed in one brand's identity.

That is not tradecraft, it is residue. A signature block from a different campaign survived a copy-paste into this one and shipped without anybody reading it back. Kits get assembled in volume, templates get recycled across brands, and the quality control that would catch a mismatched employer costs time mass production does not spend. Artifacts like this are the most reliable tells a reader gets, because nobody proofread them.

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

A button that led somewhere unremarkable

There were no attachments. The entire payload was the one link behind the Open button, pointing at a campaign subdomain of the same authenticated export domain, so the click inherited the reputation the message had already borrowed.

When analysts traced that link, the redirect chain issued a 302, then a 301, and terminated with a 200 at the public homepage of a major search provider. That is the honest account of what was captured: a tracked redirector whose observed destination was benign. It is not evidence that no harvesting page exists. Redirectors like this commonly branch on the click, serving inspection traffic something harmless while routing a live click elsewhere, so the destination the recipient would have reached was never observed. Classified as a spearphishing link, with a payment-review pretext pointing at financial theft as the objective.

What actually closed it

Automated detection resolved the message as phishing without an analyst touching it, logged as no action required, one mailbox affected. Nothing in the envelope helped. The resolution came from weighing content and context against a sender relationship that did not exist, which is the work adaptive AI email security has to do when authentication is genuinely clean, and why business email compromise protection has to model conversations and relationships instead of grading envelopes.

That matches what the 2024 Verizon Data Breach Investigations Report describes when it names pretexting the leading social-engineering type and puts the human element in 68% of breaches. CISA phishing guidance and the NIST definition of phishing both land on verification outside the message as the control that survives contact, exactly the step this attack was designed to make feel unnecessary.

Indicators of Compromise

MITRE ATT&CK Mapping

See You Next Friday

Authentication answered the question it was built for, correctly, and the answer was useless here. What no header could say is that the replies quoted underneath were invented, that the brand on the notification belonged to the recipient rather than the sender, and that the only genuine thing in the message was borrowed reputation. The test costs one mailbox search: if the conversation exists nowhere except inside the message asking you to act on it, there is no conversation.