Before I ever open a suspicious PDF attachment in a full parser — or, heaven forbid, in an actual PDF reader — I run it through PDFiD first. It’s a lightweight Python script by Didier Stevens that scans a PDF file for the presence of specific keywords and structural objects that are commonly associated with malicious behavior: JavaScript, embedded files, automatic actions, and more. It’s one of the fastest “is this worth digging into further” checks I know of.
What PDFiD Does and How It Works
PDF files are essentially structured text/binary documents made of objects (obj/endobj), each of which can hold streams, dictionaries, and cross-reference tables. Malicious PDFs typically abuse specific object types and keywords to trigger unwanted behavior when opened — automatic JavaScript execution, embedded/launchable files, or exploiting a reader’s parsing engine.
PDFiD doesn’t fully parse the PDF’s object graph the way a real PDF library does. Instead, it scans the raw file for known keyword strings (/JavaScript, /JS, /AA, /OpenAction, /EmbeddedFile, /Launch, /ObjStm, and more) and counts occurrences. This intentionally shallow, string-based approach makes it extremely fast and resistant to some parser-confusion techniques malware authors use against full PDF libraries — it’s a triage tool, not a full analysis engine.
Installing PDFiD
It’s part of Didier Stevens’ PDF tools suite. On Kali it’s usually preinstalled:
which pdfid.py
If not present, install manually:
sudo apt update
sudo apt install -y pdfid
Or clone directly from the source:
git clone https://github.com/DidierStevens/DidierStevensSuite.git
cd DidierStevensSuite
python3 pdfid.py --help
Dependencies are minimal — plain Python 3 is generally enough.
Basic Syntax
python3 pdfid.py [options] <file.pdf>
Options I use:
python3 pdfid.py suspicious.pdf # basic scan
python3 pdfid.py -e suspicious.pdf # extra keyword search
python3 pdfid.py -f suspicious.pdf # force scanning even with parsing errors
python3 pdfid.py -c -o report.csv suspicious.pdf # CSV output for scripting
python3 pdfid.py -s malware_folder/ # scan an entire directory
Real Example
$ python3 pdfid.py suspicious.pdf
PDFiD 0.2.8 suspicious.pdf
PDF Header: %PDF-1.7
obj 42
endobj 42
stream 5
endstream 5
xref 1
trailer 1
startxref 1
/Page 3
/Encrypt 0
/ObjStm 0
/JS 1
/JavaScript 1
/AA 1
/OpenAction 1
/AcroForm 0
/EmbeddedFile 0
/Launch 0
Any nonzero count next to /JS, /JavaScript, /AA (Additional Actions), or /OpenAction is an immediate red flag — it means the PDF is configured to run script code automatically the moment it’s opened, which is exactly the pattern used in a huge share of malicious PDF campaigns.
Real-World Use Cases
Email/phishing attachment triage during incident response — I run every suspicious PDF attachment through PDFiD before deciding whether it needs a full sandbox detonation or deeper static analysis.
SOC alert triage — quickly scanning a batch of quarantined attachments to prioritize which ones actually contain suspicious structural indicators versus which are benign documents that merely tripped a heuristic filter.
Malware research pipeline — using PDFiD as the first automated stage in a larger pipeline, escalating only flagged files to pdf-parser for full object extraction and manual review.
Integration with Other Tools
- pdf-parser — once PDFiD flags something suspicious, I go straight to pdf-parser (covered separately) to dump the actual JavaScript or object content for manual review.
- peepdf — another Python-based PDF analysis tool I sometimes cross-check results against.
- Cuckoo Sandbox / any.run — for files that need dynamic detonation after static triage flags them as suspicious.
Performance and Troubleshooting
- PDFiD is extremely fast even on large batches — I routinely run it across thousands of quarantined attachments in a scripted loop with negligible runtime.
- Since it’s a string-based scanner, it can occasionally flag benign keywords found inside embedded comments or unrelated text streams — always confirm suspicious hits with pdf-parser before drawing conclusions.
- A mistake I see junior analysts make: assuming a PDF with zero flagged keywords is automatically safe. PDFiD only detects known structural indicators; it doesn’t catch every possible exploitation technique (e.g., some parser-confusion or exploit-specific techniques may not trip any of its keyword counters).
Best Practices
- Always analyze suspicious PDFs in an isolated VM or sandboxed analysis environment, never on your primary workstation.
- Treat any nonzero
/JS,/JavaScript,/OpenAction, or/AAcount as a mandatory escalation to deeper analysis. - Keep the tool updated — new keyword indicators get added over time as new PDF-based attack techniques are documented.
FAQ
Does PDFiD extract or decode the actual malicious JavaScript? No — it only counts and flags the presence of suspicious keywords. Use pdf-parser to extract and decode actual object content.
Can PDFiD be fooled by obfuscation? To some extent, yes — heavily obfuscated or nonstandard PDFs can sometimes evade simple keyword detection, which is why it’s a triage tool, not a definitive verdict.
Is it safe to run PDFiD on a malicious file directly? Yes — it only reads the file as text/bytes and does not render or execute anything, making it much safer than opening the PDF in a reader.
Summary
PDFiD is my fast, low-risk first pass on any suspicious PDF. In seconds it tells me whether a document has the structural fingerprints of malicious behavior, letting me prioritize deeper analysis time on the files that actually deserve it.
References
- Official tool page and documentation: https://blog.didierstevens.com/programs/pdf-tools/
- GitHub repository (DidierStevensSuite): https://github.com/DidierStevens/DidierStevensSuite
