The PDF That Didn't Need You to Click Anything

The attached PDF passed every scanner in the chain. No malware detected. No embedded JavaScript. No macros, no executables, no form fields. The verdict: clean.

But the file contained one directive that none of those scanners thought to flag. An OpenAction entry, buried in the PDF's object structure, that auto-launches a browser to a credential harvesting page the instant the document opens. No click required.

The recipient at a mid-size engineering services firm never had to interact with anything inside the PDF. Opening the file was the entire attack.

A "Shared Document" From a Domain That Didn't Exist Six Weeks Ago

The email arrived as an Adobe document-sharing notification. The subject line referenced a specific name, a date stamp, and a reference number: all the structural details that make a share notification look routine. The body was minimal. "Hettie Rhodes shared a document with you via Adobe. Please review to avoid delays."

The sender address was inbox@investfidelity[.]com. The domain had been registered on March 2, 2026, just 37 days before this email was sent. It was registered through Cloudflare with WHOIS privacy enabled. DMARC was configured but set to p=none, meaning authentication failures generate reports but never trigger enforcement. SPF delegated sending to SparkPost, a legitimate email delivery platform. DKIM was properly configured.

The result: SPF passed. DKIM passed. DMARC passed. Every authentication check returned green.

This is the fundamental problem with email authentication as a trust signal. SPF, DKIM, and DMARC confirm that the email was sent from authorized infrastructure. They say nothing about whether the domain itself is trustworthy. A 37-day-old domain with a properly configured mail stack is indistinguishable from a 20-year-old brand, at least as far as authentication headers are concerned.

The OpenAction Trigger Inside the PDF

The attachment, a 46 KB PDF named with a hexadecimal string and the current date, contained no traditional malware indicators. No JavaScript objects. No embedded files. No form submission actions. Static analysis engines gave it a clean bill of health.

What they missed was the PDF's OpenAction entry. OpenAction is a legitimate PDF specification feature (defined in ISO 32000) that allows a document to trigger an action when opened. It is typically used for navigation, like jumping to a specific page. In this case, the attacker used it to auto-launch an external URL: hxxps://rentalhomes-view[.]onrender[.]com/.

The moment a recipient opens this PDF in most standard readers, the browser fires. No click on a link. No interaction with the document content. The file opens, and the phishing page loads.

This is what makes the attack particularly effective. Security awareness training teaches people to inspect links before clicking. Hover over URLs. Check the domain. Look for typos. None of that advice applies when the URL launches automatically on document open. According to the Verizon 2024 DBIR, the human element is involved in 68% of breaches. But this attack bypasses the human entirely.

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

Ephemeral Infrastructure on a Trusted Platform

The phishing destination, rentalhomes-view[.]onrender[.]com, was hosted on Render.com's free-tier cloud platform. Render is a legitimate infrastructure-as-a-service provider used by thousands of developers. Subdomains under onrender.com inherit the reputation of the parent domain, which means URL reputation engines face a classification problem: blocking onrender.com would break thousands of legitimate applications.

At the time of analysis, the page returned a holding message ("Please try again in an hour. This file is being updated."), a common pattern for ephemeral phishing pages that rotate between active credential harvesting and dormant states to avoid detection crawlers.

The FBI's 2024 Internet Crime Report documented over $12.5 billion in losses from internet-enabled crime, with phishing remaining the most reported complaint category. Campaigns like this one, using legitimate cloud platforms for short-lived phishing infrastructure, are a significant driver of that volume. The Microsoft Digital Defense Report 2024 noted that attackers increasingly abuse trusted cloud services to host malicious content, precisely because reputation-based URL filtering struggles with shared-infrastructure domains.

Why Static Analysis Failed (and What Caught It Instead)

The attachment scanner evaluated the PDF for known-malicious signatures. It found none, because there were none to find. The PDF did not contain malware. It contained a feature, used exactly as the specification intended, pointing to an external URL that happened to be a phishing page.

This is a category gap in static analysis. The scanner asks: "Is this file malicious?" The correct question is: "What will this file do when opened?" Those are different questions, and most static engines only answer the first.

IRONSCALES Adaptive AI caught this email through a different lens. The behavioral signals told a story that attachment scanning alone could not. A first-time sender. A 37-day-old domain with no prior sending history to the organization. An Adobe brand claim from a domain completely unrelated to Adobe. A "fax confidentiality" footer in an email about a shared document (a copy-paste artifact from a different phishing template). Across the IRONSCALES community of over 35,000 security professionals, similar patterns from recently registered domains abusing SparkPost infrastructure had already been reported and classified. The email was quarantined within minutes of delivery.

The MITRE ATT&CK framework classifies this as Spearphishing Attachment (T1566.001), with User Execution: Malicious File (T1204.002) as the execution vector. The nuance is that "execution" here requires no deliberate user action beyond opening the document.

What This Means for PDF Handling Policies

This case points to a specific gap that most organizations have not addressed: PDF OpenAction directives are a legitimate feature that can be weaponized for zero-click redirection.

Three concrete steps to close the gap:

1. Disable automatic URL launching in PDF readers. Adobe Acrobat, Foxit, and most major readers allow administrators to configure a prompt before opening external URLs. This single setting would have stopped this attack at the endpoint.
2. Evaluate sender behavior, not just sender authentication. Authentication tells you the email came from authorized infrastructure. It does not tell you the domain is trustworthy. Domain age, sending history, and brand consistency checks (IRONSCALES community intelligence) fill that gap.
3. Treat "clean" attachment verdicts as incomplete. A PDF with no malware can still contain an OpenAction that redirects to a credential harvesting page. If your email security stack cannot evaluate what a PDF will do on open, not just what it contains, you have a blind spot.

According to IBM's 2024 Cost of a Data Breach Report, stolen credentials remain the most common initial attack vector, with an average breach cost of $4.88 million. Every gap in the detection chain, including one as specific as unscanned PDF OpenAction directives, is a potential entry point for that cost.

Indicators of Compromise