AV Said This PDF Was Clean. It Was Wired to Fire a Google Script the Second You Opened It.

The antivirus verdict was one word: clean. No macro. No embedded executable. No known-bad hash. A 101 KB PDF named like a shared file, sent from a school district staff member to a care coordinator at a regional health system, scanned green and landed in the inbox.

The verdict was technically correct and completely useless. The PDF was weaponized. Its payload just was not a file.

Buried in the document structure was a /AA auto-action wired to a /URI annotation pointing at a Google Apps Script endpoint. Open the PDF in the wrong viewer and it navigates to that URL on its own. No click. No warning. The attack did not smuggle malware past the scanner. It smuggled a behavior, and behaviors do not have signatures.

A File Share From a School District to a Hospital

The lure was mundane, which is exactly why it worked. The subject read like a document-share notification. The body was three lines: a court case number, a note that "new order(s)" had been filed, and a pointer to the attached PDF for full details.

The signature block sealed it. Logo, job title, direct phone line, and a full confidentiality notice for a real Midwest K-12 school district. It looked authentic because it was authentic. The message came from a genuine, compromised mailbox inside that district, and the district's own email signature service appended the branding on the way out.

That is the uncomfortable part. This was not a spoof. It was a legitimate account doing an attacker's work, and it hit four mailboxes at the health system before anyone flagged it.

Why Every Scanner Waved It Through

Walk the checks a modern email stack runs, and this message passed almost all of them.

• DKIM: pass. The message was cryptographically signed by the district's real domain, using the district's real signing key.
• DMARC: pass. Alignment held against the sending domain. Composite authentication scored a perfect 100.
• Attachment scan: clean. Sophos-class antivirus inspected the PDF and the companion PNG and found nothing to match.
• Reputation: trusted. The mail transited well-known gateway providers, a signature-management relay, and a hosted email security appliance whose policy for that sender was set to allow. The final spam confidence landed at negative one, the lowest possible risk score.

Only SPF showed friction, a fail at the last forwarding hop, and that is precisely the kind of noise multi-hop cloud routing produces every day. Any analyst who blocked on it would drown in false positives.

Authentication was never designed to answer the question that mattered here. SPF, DKIM, and DMARC prove a message came from authorized infrastructure. They say nothing about intent. When the authorized infrastructure is a hijacked account, every green checkmark is telling you the truth and lying at the same time.

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

The Payload Was a Behavior, Not a File

Here is what the antivirus engine could not see because it was not looking for it.

A PDF can hold an /AA object, short for Additional Actions. It defines what happens automatically when a document event fires, including the open event. Attach a /URI action to that trigger and the file becomes a launcher: open it, and the viewer reaches out to a web address without a single click.

In this case the target was a Google Apps Script /exec URL. That maps cleanly to two MITRE ATT&CK techniques. The weaponized attachment is Spearphishing Attachment (T1566.001), and the auto-action that runs the moment the document opens is Malicious File (T1204.002), except the "user execution" step is reduced to the act of opening the file.

There was a second tell in the attachments that a structural scan would catch and a hash scan would not. The companion image bundled with the PDF carried creator metadata naming a motion-graphics editing tool, an odd fingerprint for what was presented as a scanned business document. It is not proof on its own. It is one more data point that the packaging did not match the pretext.

Why Google Apps Script Is the Perfect Host

Attackers did not pick Google Apps Script by accident. An /exec endpoint runs on script.google.com, a domain no sane organization blocks and most explicitly trust. It serves valid TLS, resolves instantly, and can host a form, a redirector, or a full credential-collection backend behind a single opaque URL.

For a URL reputation filter, that link is indistinguishable from any other Google service. The trust attached to the domain becomes the attacker's cover. This is the same logic behind abuse of other legitimate cloud platforms, and it is winning because the security industry spent a decade teaching filters to trust brand-name infrastructure.

The 2024 Verizon Data Breach Investigations Report found phishing present in 15 percent of breaches and stolen credentials involved in 38 percent. Attacks like this one sit at the intersection: a phishing delivery designed to farm credentials, riding infrastructure that no reputation engine will challenge.

Indicators of Compromise

How to Catch an Attack With No Bad File and No Bad Domain

You cannot block your way out of this one. The domain is Google. The file is clean. The sender is authenticated. Every static control is working as designed and every static control is beaten.

Three shifts close the gap.

Treat compromised legitimate senders as the default threat, not the exception. According to IBM's Cost of a Data Breach report, stolen and compromised credentials remain among the costliest and slowest breaches to contain. A first-contact message from a never-before-seen external account, carrying a court-case pretext under a school-district signature, is a behavioral anomaly even when the account is real. Adaptive detection that models sender relationships, not just sender identity, is what flags it. That behavioral layer is why Themis, the IRONSCALES agentic AI analyst, scored this message as phishing while the gateway scored it as safe.

Inspect attachment structure, not just attachment signatures. A /AA open-action pointing to any external URL should raise a flag by itself. This is exactly the surface that reputation-blind advanced malware and URL protection is built to examine, decomposing the file rather than trusting the AV verdict on it.

Assume trusted domains will be weaponized. CISA, the NSA, and the FBI make this explicit in their joint phishing guidance: defenders should scrutinize destination intent, not just destination reputation. A link to script.google.com deserves the same behavioral inspection as a link to a domain registered yesterday. And because the delivery vehicle here was a hijacked mailbox, account takeover protection on your own side of the fence is what stops your users' accounts from becoming the next trusted sender in someone else's campaign.

The Signal That Actually Mattered

Every reputation and authentication check in the path returned the answer the attacker wanted. The account was real. The signature was real. The Google domain was real. The only thing that was fake was the intent, and intent is the one thing a signature can never carry. The industry keeps building filters that ask "is this sender allowed?" The attacks that land are the ones where the honest answer is yes.