The Scanner Said Clean. The Link Was a .exe on GitHub

In late August 2026, a global pharmaceutical contract development and manufacturing organization received an email with exactly one thing to click. The body announced, under a heading about a statement being ready for download, that a benefit statement had been prepared and was available immediately. A single navy button sat in the middle of the template. The button read "Obtain Statement." Behind it was a Windows executable, published as a downloadable release asset on GitHub.

Our own URL scanner looked at that link, the one a user would actually click, and returned a verdict of Clean.

That verdict was not a defect. It was an accurate statement about the host and a useless statement about the threat, and the gap between those two things is the entire case.

Nothing Failed Anywhere

There is a familiar shape to a phishing teardown: something fails, and the failure is the tell. Not here. The message arrived at the recipient's Microsoft 365 tenant with SPF passing, DKIM verified against the sending domain, DMARC passing on alignment as well as on signature, and composite authentication passing with the maximum reason code. An independent upstream SPF check at the receiving gateway also returned a pass. The sending domain was registered more than two decades ago and belongs to a real, operating US business with no connection to benefits administration.

The message went out through a mainstream email service provider on that domain's behalf, which is why it carried the domain's own signature. The provider is shared infrastructure, and the sending business is a victim here too, not the attacker. Whether its bulk-mail account was compromised or fraudulently provisioned, the record does not say.

Microsoft's own filtering agreed with everything above. The antispam report scored the message as non-spam, with a spam confidence level of 1 and no category assigned. It went to the inbox.

The Payload Was a Release Asset, Not an Attachment

The attachment list on this incident is empty. Nothing was carried in the message. Delivery was entirely by link, and the link pointed at a release-download path on a public code-hosting platform, ending in a filename that began with "StatementDoc" and ended in .exe.

We did not retrieve the binary, and nothing in the record establishes what it does. Anyone who tells you otherwise from a filename alone is guessing.

One detail in the URL is worth its own sentence. The recipient's own email domain was appended to the payload link as a bare query string, with no parameter name at all. The observable effect is that every recipient got a slightly different URL, which is enough to defeat exact-match URL blocklisting and message-hash deduplication, and it may be nothing more than a cache-buster. It does not report anything back to the attacker.

Reputation Is Inherited, Not Earned

Two links in this message resolved to the same download. The first was the code-hosting URL in the button, and our scanner rated it Clean. The second was the release-asset CDN hop that the platform redirects to, and that one came back Mixed Result.

The clicked link scored better than the hop behind it because it had a better host. Reputation flows from domain to URL, and no organization blocks a public code-hosting platform. Attackers have worked that out. The 2026 Verizon Data Breach Investigations Report reports that 16% of breaches use phishing as the initial access vector, and one reason that number stays stubborn is cases like this one, where staging the payload on borrowed trust removes the last artifact a blocklist could act on.

Read the indicator table below and notice what is missing from it. There is no attacker-owned domain anywhere in the delivery chain. The sending domain belongs to a real business, the egress address belongs to an email service provider, the landing host is a code platform used by millions of developers, and the asset host is that platform's own CDN. The only attacker-supplied artifacts in the case are a file and a template.

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

The Second Hop Cannot Be Re-Examined

The asset URL our scanner resolved carried a signed token valid for exactly 300 seconds, plus a storage signature that forced the file down as an application/octet-stream attachment. It is tempting to read that as tradecraft, an attacker choosing throwaway hosting to frustrate later analysis.

It is not. The signed token was minted when our scanner followed the link, and its not-before timestamp matches the incident creation time to within a second. That URL never appeared in the email at all. The platform issues a fresh short-lived token for every release download, malicious or entirely legitimate. The honest version is narrower and still uncomfortable: the second-hop artifact is structurally unretrievable minutes later, because that is simply how release delivery works. Abusing the platform inherits that property for free.

Five Mailboxes, Four Subject Lines

The campaign touched five mailboxes at the organization under four distinct subject lines, all variations on a statement or personal information being ready. The primary message landed on the evening of August 24, 2026. The remaining four arrived the following evening, all of them inside roughly 56 minutes, which puts about 21 hours between the first send and the cluster.

Themis, our Adaptive AI analyst, returned a recommendation confidence of 90 and labelled the primary recipient a VIP based on their role in the organization. The driving insight was blunt about the mechanic, noting that one or more links in the email had been flagged as malicious, specifically the "Obtain Statement" link, and two further insights flagged community-reputation similarity to previously reported phishing. The sender was a first-time sender carrying a high risk level. The incident automatically resolved as phishing.

The response was thinner than the detection. Three of the four secondary mailboxes show a mitigation status with no action actually taken, and one was never mitigated at all.

Defending a Chain With No Bad Domain

Three practical shifts follow from this case.

Stop letting host reputation function as a decision. It is one weak input. A link terminating in an executable deserves the same scrutiny whether hosted on a bulletproof VPS or a code platform with a nine-figure user base, and advanced malware and URL protection has to evaluate what a link returns, including the final content type, rather than who serves it.

Second, do not treat native platform filtering as the ceiling. This message passed Microsoft as non-spam, which is exactly the residue that M365 augmentation exists to catch. CISA's phishing guidance and the NIST definition of phishing both frame the problem around deception rather than infrastructure, and the deception here was intact.

Third, score context. A first-time sender, an unexpected benefits pretext, a generic do-not-reply alias, and a download link ending in .exe are individually unremarkable and jointly damning. That is a behavioral judgement, not a reputational one, and it is what 36,000+ security professionals across 18,000+ organizations in our community keep reporting when reputation gives them nothing.

Indicators of Compromise

MITRE ATT&CK Mapping

The Takeaway

The uncomfortable version of this case is that every control did its job and the message still landed. Authentication verified the route, and the route was genuine. Reputation verified the host, and the host was genuine. What none of them evaluated was the one thing that mattered: the link ended in an executable, and trust in a platform is not evidence about a file that someone uploaded to it.