I have a PDF with important information that may contain malware. What would be the best way to view it?
1Is it of a JS kind? I think you can turn off JS.– curiousguyAug 19, 2012 at 17:26
The thing I would do is open it in a virtual machine without network access.– LucAug 19, 2012 at 19:25
There may be a question here as to whether static or dynamic analysis is most effective.– adricAug 24, 2012 at 11:15
1If a PDF contains malicious software then it no longer should be viewed. Besides non-malicious content likely doesn't even exist. You could also open the PDF file in a Linux virtual machine, but like I said, the content is likely gone.– RamhoundAug 24, 2012 at 16:06
@curiousguy - ok. I don't know this. Why does someone have legal JS code in a PDF OR What does it do that a non-JS PDF cannot?– FirstName LastNameFeb 5, 2013 at 10:13
Document-based exploits are directed not at the document itself, but rather at some vulnerability in the viewer. If you view the document in a program that isn't vulnerable (or in a configuration that inhibits the vulnerability), then you won't be exploited.
The real issue is knowing whether or not your viewer is vulnerable, which usually means knowing specifically what the exploit is. But there are alternate PDF viewers such as foxit or even Google chrome's built-in viewer that do not necessarily have the same vulnerabilities as Adobe's official viewer. This is not necessarily true for all vulnerabilities, so it's important to understand what you're getting in to ahead of time.
If you find yourself frequently dealing with potentially malicious materials, it would be very wise to set up a hardened virtual environment. I'd recommend booting into a Linux system and running your target OS (usually Windows) in Virtualbox or a similar environment. Save a snapshot of the virtual OS, and then revert to that snapshot after you're done interacting with the malicious content. Also, it's not a bad idea to run the host Linux environment from a read-only installation (i.e. Live-CD).
4Reasonably simple setup would be a VM + Sandboxie + DigiSigner Aug 19, 2012 at 19:59
I don't use foxit or adobe. I use an obscure reader. Recently, it crashed when i opened a pdf file. Can this be a malware attack? How do I check? Feb 5, 2013 at 10:11
1Note about the edit - most modern Linux systems have several native PDF viewers available (including a ancient version of Adobe Reader, usually you don;t need to bother with that - I suggest using Okular, and most versions of evince and mupdf work great as well), you don't need to use a Windows VM....– WilfApr 23, 2015 at 20:10
3@FirstNameLastName be weary of using lesser known products to avoid infection. 1: the product may use a common library and unknowingly be actively exploitable and 2: it may not be getting patched as often or as quickly as more main stream products. Hardened VM really is the only way to be sure.– robNov 30, 2016 at 10:38
Put it through a PDF viewer that isn't vulnerable to the exploit. If it's someone else's viewer, that's even safer. Try Google Docs, where they will parse it and display it as HTML, so the malicious payload won't harm you. (I'm sure that their PDF parser is extremely secure, so you shouldn't feel bad about possibly infecting them.)
11I don't want to give the information in the PDF to google but thanks.– user11101Aug 20, 2012 at 3:21
5Using Google Docs is good advice, but "Put it through a PDF viewer that isn't vulnerable to the exploit" sounds strange to my ears. Usually, you don't know whether a particular viewer is vulnerable until it's too late. Jun 21, 2017 at 10:42
@barbecue If avoiding "almost all" exploits is good enough then by all means one should stick to a PDF viewer without JS support. Jun 21, 2017 at 16:59
@DmitryGrigoryev I'm not sure what your point is. An exploit specifically targeted to work with Sumatra is possible, as I stated in my answer. Its likelihood is exceedingly small. If you're claiming there is a way to eliminate 100% of all exploits, you're simply wrong. No such method exists. Jun 21, 2017 at 18:29
Use pdf.js with a sandboxed browser (such as Chromium or Firefox) in a virtual machine without network access.
It should be quite tricky for malware to get out of this.
In this situation I've always used the Unix/Linux/OSX shell command "strings". On *nix systems, do this:
strings ScaryFile.pdf | less
You can also get "strings" for Windows, as mentioned by Polynomial, below. You can download it here. Runs on XP or higher. Here is an example of using it on Windows:
strings ScaryFile | findstr /i TextToSearchFor
But for the rest of my answer here I'll assume you're on *nix, since that is my experience with strings. Assuming all you're looking for is text content (not bitmaps or vector graphics), you can scroll down or search and find bits of the text you need. Unfortunately, to find it you have to wade through tons of metadata, most of which is in XML, and formatting settings in some other markup, plus some binary (as ascii, not raw bytes). So you may want to use the search capabilities of the "less" command. To search down the document for the case-sensitive string "thingyouwant", use the slash key + your string + return:
Then hit the "n" key to see the next instance of "thingyouwant", over and over till you find what you want. You can use the "?" key to do the same thing in the upward direction. See the less man page (type "man less") for more magic.
You could also analyze things like which URLs the document links to:
strings ScaryFile.pdf| grep -i "http" | sort | uniq | less
But, as stated above, 99% of what you'll see from the output of "strings" is going to be metadata and formatting settings.
2Windows has strings too. Aug 20, 2012 at 6:04
+1 for strings(1) and pdfinfo with a followup in evince. Paging through the file looking for JS and calls to outside resources is quite effective if a bit slow.– adricAug 24, 2012 at 11:14
3You shouldn't rely on strings for security: lcamtuf.blogspot.ca/2014/10/…– TanathFeb 17, 2017 at 17:45
Sumatra also has configuration options to lock it down even further, such as preventing file system or internet access.
The PDF file format has many interactive features intended to make the format more useful, but which create significant security risks, including:
- The ability to interact with the local file system
- the ability to issue an HTTP request to a remote server
- the ability to carry a payload of arbitrary file attachments, including malware
- the ability to present a fillable form to the user, and then capture and act on the information filled in
These abilities combined together make a powerful toolkit for an attacker. Many so-called "drive-by download" attacks rely on the use of PDF files.
Common PDF viewers attempt to provide safety for these features by creating sandbox environments or giving the user prompts, but these solutions are both more complex (and therefore subject to their own vulnerabilities) and less compatible with other parties' products than the simpler solution of leaving out that functionality entirely.
Sumatra is one example of a PDF viewer that does not provide many of the functions which are most commonly used in PDF exploits. By completely eliminating entire categories of potential attacks, such programs greatly reduce the risk of viewing unknown PDF files.
A further advantage of using a less popular viewer is that because it's both less common and less powerful, it's a less interesting target.
The Sumatra viewer could be possibly be exploited by a specially crafted PDF which takes advantage of some unknown bug to cause a buffer overflow, for example. Such cases are rare however, and there have not been any significant security exploits for Sumatra in recent years.
What makes you think Sumatra is safer than any of the 1001 other PDF viewers out there? Jun 21, 2017 at 10:37
@DmitryGrigoryev My reasons for thinking this are clearly stated in my answer. I recommend re-reading the first paragraph and looking at the link in the second paragraph. You will find your answers there. Jun 21, 2017 at 15:04
1There's no need to be rude. I did read your answer in full, yet I fail to see what makes Sumatra so special. There are plenty of PDF viewers which either don't support JS or let the user disable it. Jun 22, 2017 at 7:18
Use a virtual machine that can be reverted to clean slate after tests. If the PDF reader is vulnerable, your real workstation will be much less likely to be affected.
Latest versions of Adobe Reader (version 10.1 and up) support "Protected Mode" or sandboxing which can be used to view untrusted PDF files. This effectively restricts the access of the process displaying the PDF file to
%appdata%\Adobe\Acrobat and other PDFs which are explicitly opened by the user.
Protected mode has to be activated by going to Edit->Preferences menu and selecting either General or Security tab, depending on the version:
Obviously, you'll want to close any sensitive PDFs like your bank statements before opening the untrusted one.
What is consiered as "unsafe location"? For example, would that be triggered if you open a document from a USB thumbdrive? May 10, 2020 at 6:09
@Jean-FrancoisT. I don't use Acrobat anymore, but as far as I remember, yes, thumbdrives are considered unsafe locations. Trusted locations are your local drives, excluding problematic folders such as "Downloads" and "Temp", anything else is untrusted. May 10, 2020 at 16:36
We can say ALL of the in-the-wild or targetted attack using malicious PDF file are covered with obfuscation techniques to hardened the analysis or detection process.
Another easy and less time consuming option is to open it in the Sandboxie app, which would isolate it.
1Considering this answer is written in 2017, I wonder why you advocate using Sandboxie instead of the sandbox built-in into Adobe Reader. Jun 21, 2017 at 10:33
You can open the PDF in a container. Here's a docker image you can use: https://hub.docker.com/r/chrisdaish/acroread/
MY_PDF_DIR='/tmp/foobar' docker pull chrisdaish/acroread docker run -v $MY_PDF_DIR:/home/acroread/Documents:rw \ -v /tmp/.X11-unix:/tmp/.X11-unix \ -e uid=$(id -u) \ -e gid=$(id -g) \ -e DISPLAY=unix$DISPLAY \ --name acroread \ chrisdaish/acroread
This will open an Acrobat Reader that will display via the local X server.
The approach reduces the attack surface, but not 100% safe as it's got access to your X server.
You can use a less popular viewer/OS combination. I guess no one targets Okular running on FreeBSD (though it can still be vulnerable), so if you open the file in a VM you should be very safe.
In order to do harm the rogue payload must match the viewer version and the OS and the CPU architecture of course. It is really low-level assembly and memory stuff (the payload expects to be placed at a particular memory address and expects some standard system functions to be available). If you change any of those, then the payload may not execute properly (or the viewer may simply crash without doing harm).