Malicious PDFs exploit reader flaws, JavaScript, and NTLM leakage

At a glance

What this is: SentinelOne shows that malicious PDFs can execute code or trigger remote callbacks through parser flaws, JavaScript, XFA forms and open actions.

Why it matters: This matters because PDF handling sits at the boundary between user trust, browser and reader execution, and Windows authentication, which means a document can become a credential exposure path rather than just a phishing lure.

Context

PDF is not just a file format for documents. In security terms, it is an executable container with multiple interpretation layers, including reader engines, browser plug-ins, scripting, form logic and remote actions. That makes PDF handling a governance problem as much as a malware problem, because the attack surface exists in the software that opens the document and in the authentication flows it can trigger.

The identity angle is real here because Windows authentication and NTLM handshakes can be induced by a crafted document opening a remote resource. That turns a simple user action into credential leakage, which is exactly the kind of trust boundary failure that identity, endpoint and email security teams need to treat as a control issue rather than a content-filtering nuisance. The article’s starting position is typical for a phishing-focused analysis, but the mechanism is broader than email alone.

Key questions

Q: What breaks when malicious PDFs can trigger JavaScript or remote actions?

A: The trust model breaks because a document stops being passive content and becomes an execution path. Reader flaws, embedded scripts and open actions can create code execution or forced network callbacks before a user understands what the file is doing. That is why PDF controls must be treated as part of endpoint and identity governance, not just as attachment hygiene.

Q: Why do remote PDF actions create credential leakage risk in Windows environments?

A: Because a crafted PDF can make the client reach out to an SMB or similar remote resource, and Windows may automatically negotiate authentication during that connection. The user does not need to type a password for the exchange to happen. In practice, the risk is leaked NTLM material that can support relay attacks or offline cracking.

Q: What are the signs that PDF handling controls are too permissive?

A: Teams should look for readers that allow active content by default, browsers with built-in PDF engines that are not centrally controlled, and outbound authentication attempts triggered by document opens. If security tooling cannot distinguish a normal PDF from one that launches scripts or remote requests, the policy boundary is too weak for modern phishing.

Q: Should organisations disable PDF scripting before tightening NTLM behaviour?

A: They should address both, but active PDF scripting and remote actions are usually the faster risk-reduction win because they reduce the chance that a document can trigger authentication at all. NTLM hardening still matters, especially where legacy systems remain, yet document execution paths are the more direct exposure in this attack pattern.

Technical breakdown

How malicious PDFs execute code through reader engines

A PDF can carry active content in several places, and malicious authors exploit the fact that different readers interpret those structures in different ways. Reader flaws can turn ordinary parsing into code execution, while embedded JavaScript, AcroForms and XFA forms add scripting and action logic that was intended for usability. Browsers also matter because many contain built-in PDF engines, so the same file may be interpreted by more than one renderer. The technical risk is not just malformed content but the combination of parsing, rendering and script execution in a trusted client path.

Practical implication: Treat PDF rendering as an attack surface and restrict active content wherever the business can tolerate it.

Why GoToR and callback actions can leak NTLM credentials

PDF action dictionaries can instruct the reader to open a remote destination, including SMB paths or URLs, when the document is opened. If the target is a network share, Windows may automatically attempt authentication and send NTLM material as part of the login process. That makes the remote action a credential harvesting primitive, even if the PDF never drops a payload. The attacker does not need the user to submit a password. They only need the client to reach out to a hostile resource and negotiate access on the attacker’s terms.

Practical implication: Block or tightly control remote PDF actions that can trigger outbound SMB or other automatic authentication flows.

How obfuscation hides malicious PDF behaviour

Attackers frequently hide JavaScript inside compressed or encoded streams so the file looks like noise in a text editor. The article shows both Flate-compressed streams and octal-encoded JavaScript, which means static inspection requires parsing the object structure rather than trusting the visible bytes. That matters because malicious intent can sit in seemingly benign document features, and simple file extension checks or surface scanning will miss it. The lesson is that content inspection has to understand PDF internals, not merely identify a PDF by signature.

Practical implication: Use inspection tools that decode PDF objects and scripts before the document reaches an endpoint or browser.

Threat narrative

Attacker objective: The attacker wants either code execution on the victim host or reusable credential material for follow-on access and relay attacks.

1. Entry occurs when a phishing email delivers a malicious PDF that the user opens in a reader or browser-based PDF engine.
2. Credential access occurs when the document triggers a remote action or SMB callback that causes Windows to negotiate NTLM authentication with an attacker-controlled host.
3. Impact occurs when the attacker relays, reuses or cracks the leaked credential material to expand access beyond the original document open.

Breaches seen in the wild

• Mailchimp breach 2022: Attackers socially engineered Mailchimp staff, used a support tool to export 102 customer lists and exposed customer API keys for phishing.
• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

PDF abuse is a trust-boundary problem, not a file-format problem. The exploit path runs through the reader, browser and Windows authentication stack, so the control question is where implicit trust is granted. Security teams that treat PDFs as inert content miss the fact that opening a document can invoke code, network reach-out and identity material exposure. The practical conclusion is that document handling must be governed as an execution pathway, not a static attachment workflow.

NTLM leakage through remote PDF actions is a credential governance failure. The article shows that a crafted document can trigger automatic authentication without the user knowingly submitting a secret. That means the blast radius is determined by authentication behaviour, not by user intent. This is exactly the sort of credential-use assumption that identity programmes need to challenge when hardening email and endpoint pathways.

Malicious document execution is a combined content-and-identity attack surface. PDF JavaScript, XFA and open actions matter because they bridge content parsing into network and identity behaviour. That intersection is why NHI and IAM teams should care even when the initial issue looks like classic endpoint malware. The governance lesson is to align document controls with authentication controls, or attackers will keep using one to reach the other.

Reader hardening should be measured by what it blocks, not by what it promises. Disabling active content, restricting remote actions and limiting automatic credential negotiation are concrete controls, but they only matter if teams verify they are actually enforced across readers and browsers. The point is not to eliminate PDFs from the business, but to remove the assumptions that let a document impersonate legitimate user activity. The practitioner conclusion is to govern document execution paths as part of identity security.

What this signals

PDF exploitation now sits at the intersection of endpoint control and identity governance. The immediate programme question is whether document handling policies are written with execution in mind or only with malware in mind. If a PDF can trigger a script, a browser engine and an authentication handshake, then the policy has to govern all three layers together.

The more durable control pattern is to reduce implicit trust in file-open behaviour. That means reader hardening, browser PDF restrictions and tighter control over automatic authentication responses, especially where users regularly handle untrusted attachments. For IAM and endpoint teams, the practical task is to align content security settings with credential exposure policy.

For practitioners

• Harden PDF active-content settings Disable or restrict Acrobat JavaScript, XFA and other active content features in reader policies where business workflows allow it.

Key takeaways

• Malicious PDFs exploit the fact that document readers, browser engines and Windows authentication all trust the file enough to interpret active content.
• The article shows that a crafted PDF can trigger code execution or credential leakage without a user intentionally submitting a secret.
• Defenders should harden PDF active content, limit remote actions and reduce automatic authentication behaviour to shrink the attack surface.

Key terms

• PDF Active Content: Interactive or scriptable features inside a PDF that can cause behaviour when the document opens. In this article’s context, JavaScript, form logic and open actions matter because they can move a document from passive viewing into code execution or network activity.
• Open Action: A PDF instruction that runs when a document is opened, rather than when a user clicks a visible control. Attackers abuse open actions to trigger remote connections, embedded scripts or other behaviour before the user understands the file is malicious.
• NTLM Credential Leakage: NTLM credential leakage is the unintended exposure of NTLM hashes or authentication material during network activity. In practice, an attacker can coerce a system into sending authentication data that can later be cracked offline or relayed. The risk is highest when privileged accounts, weak monitoring, or silent triggering conditions are present.
• PDF Object Stream: A container inside a PDF that can hold embedded data, including code, documents, or binary content. Object streams may be compressed and encoded, which makes them harder to inspect during triage. Analysts examine these streams closely because they are a common place to conceal malicious content or staged payloads.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, human identity, and secrets management in the context of real-world identity risk. It helps security practitioners connect access control decisions to the broader identity and security programme they run.