The PDF was 46 kilobytes. No macros. No embedded JavaScript. No executable payload. The static scanner called it clean, and it was right, technically. The file contained no malware.
It also contained an OpenAction directive that launched hxxps://rentalhomes-view[.]onrender[.]com the moment anyone opened it. No click required. No prompt. No warning. Just open the file and your default browser navigates to a phishing page.
That is how four mailboxes at a professional services firm ended up quarantined on April 9, 2026, the day after this landed in their inboxes.
Attachment scanning operates on a simple premise: inspect the file for known malicious content. Malware signatures, embedded scripts, suspicious macros. If none present, the file passes. That logic is sound for the threats it was designed to catch.
PDF OpenAction is not that kind of threat. It is a legitimate PDF specification feature, defined in the standard, supported by every PDF reader, and used routinely in enterprise documents for things like auto-playing presentations or opening a related web page. The OpenAction object in this PDF contained nothing malicious by itself. It was a pointer to a URL. The URL happened to be a phishing page hosted on Render.com.
Static analysis sees a clean PDF with a valid document action. It does not open the file in a browser and watch what happens next. That distinction is where this attack lives.
According to MITRE ATT&CK T1566.001, spearphishing attachments remain one of the most reliable initial access techniques precisely because attachment handling is inconsistent across security stacks. The Verizon DBIR 2024 found phishing involved in a significant share of breaches with an external actor, and the specific vector keeps shifting toward techniques that pass automated scanning.
The email arrived Wednesday, April 8, 2026 at 15:04 UTC. Subject line: [EXTERNAL]_ATTN: Hettie Rhodes shared a document - 2026-04-08 Ref:9b57e1db576c1775660666973.
The body was minimal by design. Three lines: a notice that someone shared a document via Adobe, a request to review to avoid delays, and a sign-off. A fax confidentiality footer was appended below the signature block, an anachronistic detail that suggests a template pasted from elsewhere. The visible links in the body were Microsoft support URLs, all legitimate, all pointing to sender identification guidance and phishing protection resources. Microsoft's own safety content provided the legitimacy cover.
The actual payload was in the attachment: 9b57e1db576c_2026-04-08.pdf.
Delivery came through SparkPost, a legitimate commercial email delivery platform. The sending domain investfidelity[.]com had been properly configured with SparkPost's infrastructure, which meant the authentication headers all checked out. SPF passed because SparkPost's IP 192.174.87.107 was an authorized sender for the domain. DKIM passed because the domain's signing key validated the message. DMARC passed because SPF and DKIM aligned. Full green.
See Your Risk: Calculate how many threats your SEG is missing
This is exactly the scenario the Microsoft Digital Defense Report 2024 describes when it notes that attackers increasingly use legitimate infrastructure to deliver threats, specifically because authentication passes where content controls would otherwise flag a message.
investfidelity[.]com was registered March 2, 2026. The email arrived April 8, 2026. That is 37 days from registration to payload delivery.
The registration used Cloudflare as registrar, with Cloudflare nameservers. WHOIS registrant data is redacted. DNSSEC is unsigned. The DMARC policy is p=none, which publishes a record for SPF/DKIM alignment purposes but takes no enforcement action on failures. MX records point to Zoho, suggesting the domain was configured as a functional mailbox, not just a throwaway domain used once and abandoned.
A 38-day-old domain with no prior sending history is a meaningful signal. The FBI IC3 2024 report documented $2.77 billion in business email compromise losses, with newly registered lookalike domains as a consistent infrastructure pattern across those campaigns. "InvestFidelity" also carries ambient brand confusion with Fidelity Investments, which did not need to be the primary lure, just enough to prevent scrutiny of the sending domain.
hxxps://rentalhomes-view[.]onrender[.]com was the destination the PDF would have opened. Render is a legitimate cloud hosting platform, widely used for web applications and static sites. Like many developer-friendly platforms, it allows subdomain creation under onrender.com with minimal friction.
When Themis investigated the link, the page returned a placeholder message: "Please try again in an hour. This file is being updated." That kind of response is typical of phishing infrastructure in one of two states: either the page had already been taken down, or it was temporarily offline between victim sessions. Ephemeral hosting is a deliberate operational security choice. Threat actors use platforms like Render specifically because the subdomains are transient, the pages cycle quickly, and URL reputation services do not have time to build a verdict before the page either harvests credentials or rotates.
IRONSCALES community intelligence, drawn from more than 35,000 security professionals, flagged this email before Themis completed its analysis. That community signal, based on pattern recognition across similar campaigns seen by other organizations, triggered the investigation. Themis then confirmed the finding by tracing the attachment's OpenAction to the Render subdomain and assessing the sending domain's registration age and DMARC posture. Four mailboxes were quarantined within hours.
The combination of community detection and autonomous behavioral analysis is what caught this. A scanner that only evaluates static file content would have seen a clean PDF and moved on.
| Type | Indicator | Context |
|---|---|---|
| URL | hxxps://rentalhomes-view[.]onrender[.]com | Auto-launched phishing page via PDF OpenAction |
| Domain | investfidelity[.]com | Sender domain, registered 2026-03-02, Cloudflare, DMARC p=none |
inbox@investfidelity[.]com | Attacker sending address | |
| File | 9b57e1db576c_2026-04-08.pdf | PDF lure with OpenAction redirect, MD5: 422fb59710e59868bbc0c120feb8fb28 |
| IP | 192.174.87.107 | SparkPost MTA used for delivery |
| MTA | mta-174-87-107.smtp-out.sparkpostmail.com | SparkPost sending infrastructure |
The core gap this attack exposes: attachment scanning produces a verdict on what the file contains at rest, not what it does when opened.
Enforce PDF action policies. Most enterprise PDF readers have settings to block or prompt before executing automatic actions. Group policy enforcement closes this specific vector. The CISA cybersecurity advisory catalog covers document security controls in detail.
Apply domain age as a triage signal. A 38-day-old first-time sender is worth sandboxing regardless of authentication results. Authentication proves the message came from authorized infrastructure for that domain. It says nothing about whether to trust the domain.
Use behavioral attachment analysis. Sandboxing that actually executes the PDF and observes runtime behavior catches what static analysis misses. Behavioral analysis at the attachment level is the control that would have caught this file's OpenAction before delivery. MITRE ATT&CK T1204.002 maps the technique: malicious file execution, even when the "execution" is the document's own auto-open directive rather than a user's deliberate choice.
The IBM Cost of a Data Breach 2024 pegs the average breach cost at $4.88 million. This attack cost the attacker almost nothing to build. That gap is the problem. Static clean is not the same as safe.