The RFP Email With No Body and No Attacker Infrastructure

Four mailboxes at a global enterprise resource planning (ERP) software vendor received a request for proposal from an energy company nobody there had ever corresponded with. The message passed every authentication check in the mail flow. It also contained no words. Not a short lure, not a one-line note about the attachment, nothing. The only text a reader saw below the subject line was the mail platform's own automatic notice observing that people at the company do not often get email from this address. Everything the attack needed was inside the single PDF hanging off the message.

A Body With Nothing In It to Inspect

An empty body is not a mistake. It is a decision about where to put the payload.

Content inspection on the mail path is built around text. It scores urgency phrasing, weighs spoofed brand strings, resolves visible hyperlinks, and compares tone against prior traffic from the same sender. This message offered none of that: no sentence to score, no brand name to match, no hyperlink in the body to resolve, no salutation naming a recipient. The definition of phishing NIST publishes describes a message crafted to persuade, and persuasion normally leaves fingerprints in prose. Here the prose was in a file.

The one artifact the body did carry, the platform's first-time-sender notice, is a routing hint rather than a verdict. Procurement mail is unsolicited by design. A new correspondent attaching a document is the workflow, not an anomaly.

Authentication Passed Because It Was Telling the Truth

The header block is worth reading closely, because it is entirely clean. SPF passed against a Microsoft Exchange Online egress address. DKIM passed with the signature aligned to the sending company's own domain on the default cloud selector. DMARC passed, aligned, under a published policy of none. Both ARC seals validated. Composite authentication returned a full pass. The message crossed several Exchange Online frontends with no failing hop.

Every one of those results is correct. The sending domain belongs to a long-established energy company, registered through a regional agent, with ordinary parked nameservers. Under RFC 7489, a DMARC pass says the domain in the visible From line authorized the infrastructure that sent the mail. It does not say the sender intended what the mail does, and a policy of none asks the receiver for no enforcement at all. Authentication here proved the mailbox was real. That is the whole of what it proved.

The Clean Verdict on the Attachment Was Also Accurate

The attachment was a PDF of roughly 120 KB, generated through a browser print-to-PDF path. Static analysis found no JavaScript, no form fields, no embedded files, no macros, and no open action. The verdict came back clean, and that verdict was right about the only question it was answering: whether the file could execute anything.

Optical character recognition of the pages shows why the file worked anyway. It is a competent RFP invitation on the energy company's letterhead, complete with a named contact, a street address, and a phone number, written in Hebrew. Both organizations operate in the same country, so a Hebrew-language procurement document was entirely unremarkable, and the language offered no signal in either direction. The body copy invites the reader to view the price-quote document through a secured link. That instruction is the payload. The link itself is a URI annotation stored in the document's object structure, which is a different place from the text layer most inspection paths read (T1566.001).

The Secured Documents Link Was Not a Document Portal

The annotation resolved to hxxps://[compromised-brazilian-website]/Wealthiest/sharep-redirect[.]html.

That host is a real training company in Brazil. Registration records show a named individual as registrant with standard local hosting, the profile of a small business web presence rather than purpose-built attack infrastructure. The directory holding the page has no relationship to anything the site publishes, which is the ordinary shape of a page planted on somebody else's server (T1584.004). The sharep prefix on the filename is decoration meant to read as a document-sharing portal, and this series has seen the same staging filename appear on unrelated abused hosts in other cases.

What the page served cannot be stated: the record confirms only that the URL answered and that the automated scanner scored it clean, with no capture of the landing content. What can be stated is narrower and still decisive: a procurement request from an energy company has no reason to route a reader to a consumer-training website in another hemisphere, and clicking is what commits the reader (T1204.001).

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

Nothing in This Chain Belonged to the Attacker

Line the assets up and the problem becomes structural rather than tactical.

The sending domain is aged, authenticated, and owned by a genuine operating company. The landing domain is aged and owned by a genuine operating company. The attachment contains no code. The body contains no text. Every reputation-weighted control in the path had a true and reassuring answer to the question it asks. Domain-age heuristics saw two established registrations. Authentication saw an unbroken pass. Attachment sandboxing saw an inert document. Nothing lied, and the message still landed in four mailboxes.

That is why timing matters more than it looks. The 2024 Verizon Data Breach Investigations Report puts the median time to click a phishing link at 21 seconds and the median time to submit data at 28 seconds, with phishing present in 15% of breaches. A control whose logic depends on the destination being newly registered, or on the file being executable, has nothing to fire on inside that window.

The Signal Came From a Person, Not a Score

Detection here was human. A delivery team leader at the vendor reported the message as a suspicious link and attachment. No model confidence value exists in this record, and inventing one would misrepresent what happened: the employee reporting loop is what produced the signal, and the platform then quarantined the message across all four affected mailboxes and reverted delivery, with the case closed by manual approval.

The useful lesson sits in what that person noticed. Not the headers, which were clean, and not the file verdict, which was clean, but the mismatch between a routine procurement request and where its only link went. Malicious URL and attachment inspection closes that gap when it treats the file verdict and the destination question as two separate checks: enumerate every URI in the document's object structure, resolve each one independently of the mail-path result, and ask whether the host has any plausible relationship to the sender's stated business. CISA guidance on stopping the phishing attack cycle makes the same point about reporting: the fastest control in an authenticated-and-clean scenario is a recipient who can raise a hand cheaply.

Indicators of Compromise

MITRE ATT&CK Mapping

The Cheapest Question in Procurement Mail

Ask what the sender's business has to do with the host their link points at. In this case the answer was nothing, and that single question was available before anyone opened the file, without a detonation, a reputation score, or a header. Full authentication and a clean file verdict are honest answers to narrow questions. Neither one was ever asked where the reader ends up.