top of page


"blogger, InfoSec specialist, super hero ... and all round good guy" 



Distributing malware inside Adobe PDF documents

Distributing malware inside Adobe PDF documents is a popular method for attackers to compromise systems. Within the latest versions of Reader, Adobe has added multiple updates to address vulnerabilities. Additionally, Adobe has added a robust software sandbox capability to Reader, which activates if attackers use PDF vulnerabilities to attempt exploit of a system. Due to this sandbox addition, attackers are left with extremely limited and temporary access, restricting what can be accomplished.

Let’s start by examining how PDF files are constructed. The following are the major components of a PDF file.

PDF Header

The first line of a PDF file shows the pdf format version. For example, “%PDF-1.4means it is the file’s fourth version.

PDF Body

The body of the PDF file consists of objects used to define the contents of the document. These objects include fonts, images, annotations, and text streams. Users can also insert invisible objects or elements into the document body, which can enable PDF features like animation or security features.

The Cross-Reference Table (xref table

)The cross-reference table links all objects and elements that exist within the document, and it is stored in file format. You can use this feature to see other page contents. When the users updates a PDF document, the cross-reference table is also automatically updated.

The TrailerThe Trailer contains links to the cross-reference table and always has %%EOF at the end, which identifies the end of a PDF file. The Trailer enables a user to navigate to the next page by clicking on the provided link. From the attacker perspective…

Malicious PDF through Metasploit

We are going to use Metasploit in Kali Linux to create a malicious PDF file.This exploit can be created within the Metasploit framework, so we are going to create the malicious PDF and then perform an analysis in KALI Linux.We want to gain shell access on our victim’s computer and run a key logger to gather passwords or other critical information. We start off by loading our msfconsole. I am basically going to follow the steps outlined on the following site:, I have made some minor changes.

We want to put our social engineering skills to the test here. I recommend when you practice creating these files, you try to make your PDF file look as legitimate as possible. This builds good habits. You also want to avoid antivirus systems and malware detection capabilities by providing your PDF file with a good title, proper pages, and legitimate content.We are going to use an older vulnerability, known as the Adobe Reader ‘util.printf()’ JavaScript Function Stack Buffer Overflow vulnerability. This was a problem on Windows systems using Reader versions 9.4.6 thru 10.

Adobe Reader is prone to a stack-based buffer overflow vulnerability because the application fails to perform adequate boundary checks on user-supplied data. An attacker can exploit this issue and execute arbitrary code by gaining access to the privileges of a valid user who is running the application. The attacker can also crash the application, which results in denied service to legitimate users.

Although this is an older vulnerability, many newer vulnerabilities work in a similar fashion. Attackers will generally try to take advantage of a zero-day attack in order to achieve similar results to what we will see here.

Let’s start by creating our malicious PDF file for use in this client side exploit.

Once we have all the options set the way we want, we run ’exploit’ to create our malicious file.

We see that our PDF file was created in a sub-directory. To make it easier to locate later in our exploit exercise, we can copy it to our /tmp directory.Before we send the malicious file to our victim, we need to set up a listener to capture the reverse connection that will be created when the file is opened.

We will use msfconsole to set up our multi handler listener.

The script allows us to input a FROM (-f) address, TO (-t) address, SMTP (-s)server, Titles (-u), and finally our malicious attachment (-a).

Once we set everything and press enter we can type the message we want to use on the victim. Again, flex your social engineering skills and make it a compelling one! We then simply press CTRL+D which sends the email to the victim.

If you followed the above steps correctly and sent the file, the victim’s antivirus will rarely detect it as an event. However, the antivirus landscape is always changing so I always recommend testing it. Even though antivirus systems might not catch the malicious PDF, I know most breach detection and sandbox systems will detect the file as malicious.

As we can see, it passed through the antivirus examination with flying colors and our victim is probably ready to open this file to quickly implement the upgrades. However, clicking the file opens Adobe but only shows a greyed out window to the victim instead of a PDF document.

If we go back to the attacker’s machine, we see the following:

We now have a shell on their computer through the use of a malicious PDF client side exploit.

It would be wise at this point to move the shell to a different process. The reason is simple… if the victim closes Adobe the attacker will not lose the shell. The next logical steps in the attack are to obtain system information, start a key logger, and continue exploiting the network.

The Victim’s Recourse…

Let’s say the victim (or security technology) caught the malicious attempt and the security team was notified. Incident responders came to the rescue and decided to do some analysis. We will be that team and analyze the file to see what’s going on.

Defending the Network

We can defend our network from these types of malicious files and attacks by providing strong e-mail and Web content filtering, and deploying Intrusion Prevention Systems (IPS). Application-level controls can also be used to thwart attacks, such as:

  • Disabling JavaScript

  • Disabling PDF rendering in browsers

  • Blocking PDF readers from accessing file system and Network resources

  • Newer PDF client software includes a malware sandbox that gets implemented when malicious PDFs are detected by the application. However, there have been exploits that allow attackers to subvert these countermeasures, so multi-layered defense is always recommended.

Other general measures that have a very solid success rate of detecting and eliminating these types of attacks include:

Implementing breach detection systems that specifically look for zero-day type attacks

Monitoring outbound network activity for malicious behaviors

Setting your security tools to look for command and control characteristics as defined above.

Happy hunting…

Recent Posts

See All
bottom of page