Clean Attachment, Clean Link, and a Guessed DMARC Pass

The message arrived as a reply, a genuine continuation of a conversation already in progress, carrying an In-Reply-To header and a three-deep References chain. The oldest message ID in that chain belonged to a municipal government mail server, so the thread predated everyone who later mattered. One of its participating mailboxes had simply stopped answering only to its owner.

That mailbox was a shared service address at a small Israeli nonprofit whose website, phone number and signature block our SOC matched against public listings. From it came a short, calm Hebrew note to a chief-of-staff mailbox at a large Israeli food manufacturer: a partner document had been shared for review, please pass it to finance. Attached was a PDF named, in Hebrew, "payment report."

The attachment scanned clean. The link inside it scanned clean. Microsoft stamped the message with its own phishing safety classification and delivered it anyway.

A Reply Into A Conversation That Already Existed

Nothing in the envelope was forged, which is why nothing in the envelope helped. The mailbox belonged to a participant in the thread, so the attacker needed no lookalike domain and no invented display name. The note refused to escalate: no deadline, no threat, no payment demand. It said a document was ready for review and asked the recipient to forward it to finance, which is the real attack surface: the recipient becomes the distribution mechanism, and the next hop arrives from a trusted internal address.

Four mailboxes on the recipient domain were hit over roughly 48 hours. Three received the first subject variant inside an eleven-minute window one morning. A different Hebrew subject reached a fourth two days later, and only that one has any mitigation recorded against it.

The DMARC Pass That Was Never A Policy Decision

The final Authentication-Results header reads, in substance: SPF pass, DKIM pass with the signature verified, DMARC bestguesspass, composite authentication pass. Read carefully, that is three near-misses stacked into a green light.

The verdict is not "pass," it is "bestguesspass," which is what Microsoft returns when the sending domain publishes no DMARC record at all. The receiver inferred an outcome from the SPF and DKIM results it already held. RFC 7489 defines DMARC as alignment plus a published policy. Half of that was absent, and the log line reporting its absence contains the word "pass."

Next, what DKIM covered. The signing domain is the sender's own onmicrosoft.com tenant domain, not the domain in the From header, so alignment is organizational at best. Before egress, the message showed DKIM none, not signed, DMARC none. The proof everyone downstream relied on was applied on the way out by the compromised tenant itself, which is what account takeover buys an attacker.

Then the ARC trap. The message carries two Microsoft ARC seals. The first records SPF pass, DKIM pass for the From domain and DMARC pass. The second demotes DMARC to bestguesspass and moves the DKIM pass to the tenant domain. Read the preserved set instead of the final evaluation and you see a clean DMARC pass that never existed.

Microsoft's own verdict is the last twist. The anti-spam report carries the phishing safety-tip classification alongside a spam confidence level of 1 and a filter verdict of not spam. The platform saw phish, scored it harmless and delivered it. The 2024 Verizon Data Breach Investigations Report found the human element present in 68 percent of breaches and stolen credentials involved in 38 percent.

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

What The Byte Scan Could And Could Not See

The deep attachment analysis never ran. Every structural tool in the chain, from the metadata readers to the embedded-file lister, failed with "No such file or directory" against the file's Hebrew name. A non-ASCII filename reduced a full sandbox pass to nothing, and the record still reported an attachment verdict of clean.

What did execute was a naive raw-byte keyword search across the whole 187,635-byte file, looking for eleven markers. It returned exactly two hits: a URI action and an Additional-Actions object. No JavaScript, embedded-file, form, field, encryption or object-stream markers. Because those two keys sat in plaintext, the document's top-level dictionaries appear uncompressed.

But this is not another PDF that fires on open. No open-action key appears anywhere in the file, and that is the only key that fires when a reader opens a document. A bare Additional-Actions object triggers on other events entirely, depending on which dictionary holds it, and the record does not say which. Nor can a byte scan see inside compressed streams, and no structural parse ever succeeded. The defensible statement is narrow: no script markers appear in the plaintext portions of the file. That is what was visible, not a clean bill of health.

What the PDF demonstrably carries is an address, the same URL that also appears as a body link under Hebrew anchor text meaning "open file." A second attachment, declared as image.png, is not a PNG: its MIME type and leading bytes identify GIF data.

The Gate That Echoed The Attachment

The URL resolves to a page under a /cgi_readme/ path on the website of a real Argentine agro-industrial company, fronted by Cloudflare and returning HTTP 200. That company has no connection to the lure, and its registry publishes no dates, so no registration-age argument runs either way. Treat the owner as a compromised bystander.

The page is a teal-and-white SharePoint imitation with a Hebrew subtitle meaning "secure document access." A document card below it echoes the attachment's own title, and its date stamp matches the day the mail arrived, which suggests the page was built for this campaign rather than reused. Its size chip does not match, reading 2.4 MB against an attachment of roughly 183 KB.

There is not a single input box on that page. Below the card, a padlock, a line asserting the document requires verification, and one full-width button reading, in Hebrew, "access the document now." What sits behind that button was never captured. No Microsoft domain, tenant or asset is involved anywhere in this attack; the imitation is purely visual, on someone else's compromised server.

What Actually Flagged It

Every content control returned green: a clean PDF verdict and a clean link scan carrying a partial verdict. Both CISA phishing guidance and the NIST definition of phishing define the threat by deception and elicited action rather than by files and URLs, which is the framing this case needs.

It was caught on relationships. Themis, our Adaptive AI, scored the incident at 59 percent confidence under a VIP-recipient label, on the strength of a link its own engine flagged as malicious, which is our assessment rather than a URL scanner's verdict, plus two community reputation signals drawn from how similar incidents resolved elsewhere. That is a cross-tenant reputation call, not a payload verdict, and it was the only control in the stack with a chance here. The 2023 FBI IC3 Internet Crime Report put reported business email compromise losses near $2.9 billion, and losses at that scale come from real accounts saying things their owners never sent.

Mitigation was partial. Of the four affected mailboxes, one was quarantined and reverted. The other three carry no mitigation action at all.

What To Take Into Monday

Treat "bestguesspass" as "no record found," and publish a DMARC record for your own domains so nobody has to guess. Check which domain DKIM signed, and read the final authentication results rather than the preserved copy of an earlier one. And test your attachment pipeline against non-ASCII filenames, because a clean verdict on a file no parser could open is an absence of evidence dressed up as a result.

Indicators of Compromise

MITRE ATT&CK Mapping