The RFP Was Addressed to the Company That Sent It

A message with the subject "REQUEST FOR PROPOSAL" landed in four mailboxes at a regional broadband network construction and installation contractor. It carried a three-page PDF that looked exactly like what it claimed to be: scope summary, submission instruction, sequential reference number, and a formal To-block naming an addressee by organization, executive title, street address, and contact mailbox.

The addressee was the company that sent the email.

That inconsistency is the fastest way into this case, and it costs nothing to check. Everything else was built to survive inspection.

Everything in the Mail Path Passed

At the final receiving hop the results read as clean as authentication gets: SPF passed on a Microsoft Exchange Online egress address authorized for the sending domain, DKIM passed with a verified signature aligned to the header-from domain under that tenant's default outbound selector, DMARC passed, composite authentication returned a pass with reason 100, and the ARC chain was sealed with a pass. The Received chain shows internal Exchange Online hops inside one tenant's namespace before the outbound node: composed in a real cloud mailbox, not injected by an external relay wearing a borrowed domain. A supporting header preserves the original submission state, DKIM unsigned and DMARC none, because the platform signs on egress. That is not evasion, it is what genuine tenant-originated mail looks like from the inside.

The sending domain was registered well before this message and published p=none, which under RFC 7489 means no enforcement on a failure. Nothing failed. The only soft signals were a first-time-sender flag, a high sender risk rating, and a spam confidence level of 1. The cryptography proved the message came from that tenant, and nothing about the file attached to it.

The Loudest Indicator Was a Mail Client Artifact

One string would stop any analyst: the signature's website link rendered with a doubled top-level domain, the sender's own domain followed by a second .com. That reads as a textbook deceptive lookalike, and it is what most triage would close the ticket on.

It is not attacker infrastructure. Both anchors carrying it were tagged with Outlook Web App's automatic link-detection class, so the mail client built the address out of fragmented signature text. The attached PDF, written by the same sender, spells the same website correctly with a single .com. And the registrable domain behind the doubled suffix was registered in the mid-1990s and answers wildcard labels, so nobody registered anything for that hostname to resolve. It returned HTTP 403, failed certificate validation, and pointed at Cloudflare anycast addresses: parked wildcard behavior, not a credential page. Triage that stops at the loudest string closes the case on a bystander and never opens the attachment, which is where the only real indicator lived.

The Payload Was a Single Clickable Rectangle

The PDF was 223,960 bytes across three pages, and the platform verdict was clean. That verdict was accurate as far as it went. In the raw bytes the file holds zero JavaScript entries, zero open-action entries, zero form dictionaries, and zero embedded files. There is no additional-actions dictionary and no packed executable. Its long compressed runs are ordinary font and content streams.

What it does contain is one link annotation: a single object declaring a link with no visible border, roughly 195 by 36 points, whose action carries a URI entry pointing at an attacker-controlled redirector. Text extraction places the words "VIEW RFP DOCUMENT" at precisely that rectangle, right after a sentence telling the reader to access the secure document below.

That is the entire attack: a quiet business document and one button. It maps to spearphishing attachment for delivery and user execution of a malicious link for the click, and it works for a jurisdictional reason. No URL reputation check in the mail path looked inside the annotation layer, and the one link the platform did scan came back clean. The redirector was never in the scanned-links set, because nothing extracted it.

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

Its naming is the only clue about intent: a billing path under a hostname whose apex domain returns no registration data, and a page filename echoing a familiar document-sharing platform, matching endpoints that appear in public sandbox reports as redirectors. The destination itself was never scanned or observed, and guessing at it would be the easiest mistake here.

The Document Named Its Own Sender as the Recipient

Back to the To-block. The proposal was addressed to a chief operating officer at the sending company, at that company's own street address, with its own contact mailbox listed. It purported to come from a technology services firm on an unrelated domain, with a named contact mailbox printed beside the button. Its issue date was the day it was mailed, and the file was created forty-three minutes before the message went out.

Whether the sending mailbox was compromised and pushed the lure onward, or a mail merge filled the To-block with the wrong party, the record does not settle. It matters less than the artifact: an inbound proposal naming the sender's own executives is either misdirected or recycled.

The visible body offered no urgency, no credential request, and no payment request. Just a signature block, a confidentiality notice, an inline logo image, and the recipient organization's own external-sender banner printing its company name in the alert text. Reply headers referenced four earlier message identifiers all stamped with the same mailbox host: successive drafts from one mailbox, not a conversation between two organizations. The 2024 Verizon Data Breach Investigations Report puts phishing in 15% of breaches and the human element in 68% of them, and a message this quiet routes the whole decision to a person.

What Actually Flagged It

Automation did not carry this one. There is no Adaptive AI confidence figure attached to this record at all: the recommendation carried no confidence value, only a label marking the recipient as high-value. The strongest machine signals were the first-time-sender flag and the high sender risk rating, neither of which blocks a message alone.

A human closed it. An operations manager in the recipient organization reported the message with the comment "Suspicious link/attachment." An analyst set the incident to approved manually, confirming a genuine threat rather than a false positive, and all four mailboxes were quarantined the next afternoon, roughly seventeen and a half hours after delivery. The same report puts the median time to click a phishing link at 21 seconds. That is the gap that reporting culture closes.

Where This Leaves Attachment Inspection

A clean attachment verdict answers whether a file can run code, not whether every destination reachable from inside it is safe. This document passes the first question and fails the second, so link extraction has to reach into the object structure instead of stopping at the text layer (advanced malware and URL protection). And authentication is provenance, not intent: abuse of valid accounts plus impersonation of a plausible counterparty is the whole method here, so a pass is not a safety verdict.

The cheap checks are the good ones. Both give-aways here were free: a document addressed to its own sender, and a file created less than an hour before it was mailed. Neither needs a sandbox, and both belong beside standard CISA reporting guidance and the baseline definition NIST uses. The 2023 FBI IC3 Internet Crime Report puts reported business email compromise losses at roughly $2.9 billion, which is the scale that makes building a procurement pretext worth an attacker's afternoon.

Indicators of Compromise

MITRE ATT&CK Mapping