The Reply Supplied the Attachment the Recipient Asked For

The recipient had already asked for it. On August 12, a genuine industrial controls vendor sent a business development executive at a global pharmaceutical development and manufacturing company an invitation to bid on a named capital project. The executive read it, found no document, and replied with the most ordinary sentence in procurement: "I don't see anything attached." That reply sat in the thread as an open request, visible to anyone who could see the conversation.

A week later, someone answered it.

The Opening the Recipient Had Already Created

The message that arrived on August 19 was a reply. It carried the original subject line, the quoted history beneath it, and the same recipient address. It apologized for the missing attachment and supplied a link to a secure quotation portal so the bid documents could be retrieved directly. Every contextual cue a person uses to decide whether an email belongs was correct, because the conversation it attached itself to was real.

Most guidance about suspicious email assumes the message arrives cold, from a stranger, asking for something the recipient was not expecting. Here the recipient had asked for a document, said so in writing, and received a reply offering that document. The attacker never had to manufacture urgency or invent a pretext. The victim had already supplied one.

A Company That Had Never Been in the Thread

The reply did not come from the vendor who started the conversation. It came from a third party, signing as a managing partner and principal at an engineering services firm that had never appeared anywhere in the exchange. Nothing in the thread introduced them, and nothing had to. In real bid processes new participants show up unannounced all the time: a subcontractor, an estimator, a partner firm looped in without a formal handoff. A previously absent name offering to help with a quotation is not an anomaly in procurement. It is a Tuesday.

So the trust exploit here is not display-name impersonation of someone the recipient already knows. It is an appeal to organizational plausibility: the recipient was not asked to recognize the sender, only to accept that their counterparty had brought someone in.

No Misspelling to Catch, Only a Different Suffix

The impersonated firm is a real business with a real website on a .com address, and it is a bystander here. The attacker registered the identical second-level label under the .us top-level domain instead. Not a swapped letter, not a doubled consonant, not a homoglyph. The same characters, in the same order, followed by a different suffix.

That distinction matters because the usual advice fails against it. Telling people to read the domain carefully works when there is a misspelling to find. Here the readable part is correct, and the difference lives in the two characters after the final dot, the region of a domain almost nobody inspects. The visible link text compounded it, displaying the genuine .com address while the underlying href pointed elsewhere.

WHOIS puts the creation date of the lookalike domain at 2026-08-18, through a low-cost retail registrar, in the name of a private individual in California with no connection to either company. The message went out the next day. Registering infrastructure for a specific operation, MITRE ATT&CK T1583.001, was a one-day task, and the hosted mail tenant on top of it, T1585.002, was configured just as fast.

The Quotation Portal Was a File-Share Notification

The single call to action did not go to a supplier portal. It went first to a click tracker belonging to a well-known project-management platform, whose email-tracking feature the attacker was using through an account of their own rather than through any compromise of the platform. The real destination sat inside an opaque token in the query string.

That destination was a Google Sites page published under a Workspace domain unrelated to either company, and it rendered as a Microsoft file-share notification: a sender name above the line "Shared a file with you," a file card labeled RFQ_&Quote.docx, a reassuring note that the link only works for the direct recipient, an Open button, and a footer styled as a Microsoft privacy bar. A procurement request answered by a Microsoft-branded document handoff hosted on Google infrastructure is a mismatch, but only if you were looking for one.

Two layers of borrowed reputation are stacked here, which is the point. The tracker hostname belongs to a legitimate software vendor, so the first hop scans clean, and the landing page lives on sites[.]google[.]com, one of the most widely allowlisted destinations in existence. Abusing web services as both relay and staging ground, T1102, meant the attacker never had to own anything a filter would recognize as hostile.

What the Headers Proved, and What They Did Not

SPF returned none at the final hop, since the message left a Google Cloud sending address for which the one-day-old domain published no policy. DMARC was none, action none. DKIM passed, and that pass is the interesting failure: the signature was issued by the attacker's own newly created Workspace tenant, whose name was simply the lookalike domain with its dot converted to a hyphen, signed on Google's shared gappssmtp[.]com infrastructure. Microsoft's composite verdict recorded compauth=pass, reason 106, because the freshly registered domain's own signature aligned with its own From header.

That is a closed loop. The attacker vouched for the attacker, and the mail system recorded the vouching as a pass. Authentication answers whether a sender was authorized by the domain they claim, the question RFC 9989 exists to standardize. It does not answer whether the domain deserves standing, and as CISA's phishing guidance and the NIST definition of phishing both frame it, the deception is social before it is technical.

What actually moved on this message was behavior. Themis scored it at 83 percent and labeled it as reaching a high-value recipient. Content analysis read the linked page as malicious rather than trusting the allowlisted first hop, and sender analysis weighted the newly created return-path domain and sending behavior consistent with bulk mail. Our Adaptive AI does not need the header to confess, because the signals that mattered here all survive a passing signature. The message was mitigated, and one mailbox was involved.

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

The economics are why this pattern recurs. The 2026 Verizon Data Breach Investigations Report puts the human element in 62 percent of breaches and phishing as the initial access vector in 16 percent, with credentials involved in 39 percent somewhere along the kill chain. The FBI's 2025 Internet Crime Report recorded $3,046,598,558 in reported business email compromise losses. A domain costs a few dollars and a day. Credential harvesting at the end of a plausible procurement thread is the cheapest path into a vendor payment relationship, which is the ground that business email compromise protection has to hold.

Indicators of Compromise

MITRE ATT&CK Mapping

What Procurement Inboxes Should Change

A real thread is context, not verification. The moment a participant who was never introduced starts supplying documents, the thread's history stops being evidence about them, because they were not in it. Authenticate the new party, not the thread.

Two habits follow. Compare the full sending domain, suffix included, against the vendor record rather than the display name, because a top-level-domain swap leaves the readable part intact. And treat a supplier portal link that lands on a generic cloud file-share page as a stop, whatever logo is on it. The attacker here spent a dollar and a day on infrastructure, then borrowed reputation from two of the largest software vendors on earth. The one thing they could not borrow was a place in the conversation.