How should security teams investigate a suspicious PDF that may be delivering malware?

Security teams should begin with static inspection of the PDF structure, looking for multiple versions, embedded files, JavaScript objects, encoded streams, and unusual cross references. If those indicators appear, extract the suspicious objects and review the payloads separately. That approach helps distinguish a benign document from a delivery container used to launch credential theft, shellcode, or a second-stage exploit.

Why This Matters for Security Teams

A suspicious PDF is often more than a document, because the file format can carry embedded files, scripts, or compressed objects that hide the real delivery mechanism. Teams that treat it as a simple attachment often miss the boundary between content inspection and payload extraction, which is where the malware usually lives. That is why static review of structure, objects, and cross references is the right first pass before any detonation or user-facing analysis.

For defenders, the key issue is not whether the PDF “looks malicious” at a glance, but whether it contains components that shift it from passive content to active delivery. If the PDF is acting as a container, the investigation has to separate the wrapper from the embedded artifact, preserve evidence, and avoid triggering secondary code while triaging. This is especially important when the suspected outcome is credential theft, a staged exploit, or a download chain that continues after the initial file is opened. In practice, many security teams discover the real payload only after the document has already been forwarded, opened, or indexed by downstream tools.

How It Works in Practice

The investigation should start by preserving the original sample and working from a copy, because even a static review can change timestamps or trigger preview handlers in some tools. Analysts typically validate file type, inspect the object tree, and look for common delivery features such as JavaScript actions, Launch actions, embedded files, streams with high entropy, and suspicious cross-reference tables. Those details help distinguish ordinary business documents from weaponized PDFs designed to unpack a second stage.

Check for object inflation, malformed references, or multiple incremental updates that suggest the file was modified to hide content.
Extract embedded objects and decode suspicious streams before judging the payload by filename or extension alone.
Review JavaScript and action dictionaries for auto-execution, spawning behavior, or redirection to external content.
Correlate the structure with mail, web, and endpoint telemetry to see whether the PDF was part of a broader delivery chain.

If the sample contains an embedded executable, archive, or script, treat that artifact as the real subject of analysis and move it into a separate sandbox or malware workflow. That reduces the chance of conflating document layout issues with the malware logic itself. The most useful outcome of static triage is a clear decision on whether the PDF is benign, a simple lure, or a container for active code. For control alignment, teams often pair this with CIS Controls v8 because malware defense, logging, and controlled analysis all depend on disciplined triage. These controls tend to break down when analysts rely only on PDF rendering or preview tools, because the active content may never be visible in the rendered page.

Common Variations and Edge Cases

Tighter inspection often increases analyst time and false positives, so teams have to balance speed against the risk of missing a staged payload. Not every suspicious PDF is a malware carrier, and not every embedded object is malicious, which is why guidance is best treated as a workflow rather than a single signature check.

Encrypted PDFs, heavily compressed object streams, and documents generated by complex business systems can look similar to malicious samples at first glance. Current guidance suggests treating those files as higher risk when the document arrives from an unexpected source, claims to require urgent action, or contains objects that do not match the business purpose of the file. A legitimate invoice, contract, or statement may still contain scripts or attachments in rare cases, but that should be explainable by the use case and the sending environment.

Edge cases also matter when an email gateway, sandbox, or content filter has already rewritten the file. In those situations, teams should compare hashes, metadata, and extraction output from the original attachment and any downstream copies, because the inspection toolchain itself can obscure the indicators that matter. When the PDF is part of a phishing campaign, the file may be only one step in a longer chain that also uses a lure page, macro-enabled document, or remote payload retrieval.

Risk and Threat Considerations

The main risk is that a PDF is being used as a delivery container, not as the payload itself. That creates exposure to hidden code execution, staged malware retrieval, and content that looks inert until a viewer, parser, or preview engine processes it.

Failure mechanism: Attackers exploit PDF features such as embedded files, scriptable actions, malformed objects, or compressed streams to conceal the real malicious content. If defenders only inspect the visible document layer, they can miss the secondary payload, the redirect, or the exploit trigger.

Impact: The result can be credential theft, malware execution, persistence on the endpoint, or a broader intrusion chain that starts from a single attachment and expands into lateral movement or data access.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS Control 10 — Malware Defenses	PDF malware triage depends on malware detection and containment controls.
	CIS Control 8 — Audit Log Management	Attachment triage should be correlated with logs across mail, endpoint, and gateway layers.
	CIS Control 16 — Application Software Security	Malicious PDFs abuse parser and viewer behavior, making secure handling of document software material.
Recommendation — Apply malware defenses and isolate suspicious attachments before detonation. Centralize telemetry so attachment handling and extraction steps are traceable. Harden and update PDF handlers, viewers, and preview services to reduce exploit exposure.
NIST CSF 2.0	DE.CM — Security Continuous Monitoring	Suspicious PDFs require correlated monitoring across mail, endpoint, and content inspection tooling.
Recommendation — Correlate alerts and file activity to detect staged document-based delivery chains.
MITRE ATT&CK	T1204 — User Execution	Malicious PDFs often rely on user opening the file to trigger the payload chain.
Recommendation — Hunt for document-open events that precede payload execution and user-triggered compromise.

Practitioner Guidance

What to prioritise: Preserve the original sample, then triage the PDF as a possible container for a second-stage payload rather than as a normal office document. Prioritise object extraction, script review, and stream decoding before verdicting the attachment.

What to verify: Confirm whether the suspicious objects are actually reachable from the document logic, whether the file was modified in multiple increments, and whether the payload survives outside the PDF wrapper. If the answer depends on rendering only, treat the sample as incompletely analysed.

Decision rule: If the PDF contains an embedded file, active script, or suspicious external reference, isolate the extracted artifact and route it to malware analysis immediately. If the file is malformed but contains no active components, keep the case in document triage and focus on provenance and delivery context.

Practitioner takeaway: The most common mistake is to stop at “it opened” instead of asking what the PDF is hiding, because the risk usually sits in the objects behind the page, not the page itself.