• Packing PDFs – We are spoiled

    by  • September 20, 2011 • Uncategorized

    A few months ago I took a look at one of the more popular exploit kits and ripped into how it did PDF generation. I thought it was weak, easily identifiable and done without much thought. There was much more that could have been done to obfuscate the exploits, deviate from a blank file and hide the fact that the file was malicious. Shortly aftet that post I decided to dive into the process of generating my own malicious PDFs using open source technology and that which could easily plug-in to an attackers existing codebase. 

    It took me a weekend to generate a little framework to generate thousands of malicious files with a number of different JavaScript exploits, encryption and obfuscation techniques. Furthermore, it could easily be implemented into a PHP exploit kit with 5 lines of code. Now you may be wondering, is this going to get released? The short answer to that is no, not right now becuase it is unlikely to provide any value, but it got me thinking that we are spoiled when it comes to doing analysis on these malicious files. 

    Sure, not every file that leads to a successful compromise will be generated by an exploit kit, but lets face it, a lot are. When I look at my sample set I see filesizes that are small, single page documents, ones that contain nothing at all as far as content goes and I think to myself, this could be worse yet we can’t even handle these simple files.

    So how much worse could it get? Great question! When I put together my little hack of a project, I had a few goals in mind. It wasn’t so much to obfuscate the exploits because at the end of the day it wasn’t too hard to find even advanced ones with current tools. Instead, the plan was to generate documents that would make their way to the top of search results and take files we knew were once good and turn them into bad documents.

    Bumping Bad to the Top

    When I see a PDF file that is full of content and usually megabytes in size, I am less likely to walk into my analysis thinking the file is malicious. It doesn’t fit the profile and there usually needs to be some sort of indicator for me to spend the time looking at a document otherwise I would never get anything done. 

    That mentality changed after adding the ability to pack existing PDFs with exploits using my tool. I thought this would be a tough problem to solve, but it wasn’t. In fact, it was done for me aside from a little bit of inheritance and the addition of some exploits. So with the code written, it was time to pick some test subjects to inject into to see what would happen. 

    I imagine most people who follow my blog also know Contagio and the samples that are hosted there. Back a couple months ago there was a zip file containing over 5,000 “known good” files. Because these were called known good I thought they would be the perfect subject for this testing. It took less than 20 minutes to pack over 1,500 files with a couple known, obfuscated exploits with encryption applied. Attached are the packed files if you are interested.

    Moving Forward

    It is clear that the bad guys could be badder, but most chose not to be. They remain stagnent in their techniques and don’t seem to change code that is already working. However, just because we don’t see the techniques, doesn’t mean we shouldn’t predict what could happen. Go ahead and open some of the packed files that are attached. Open them in older versions and watch reader crash. Open them in newer versions and see a nice, clean document that retains its original content. 

    Imagine attackers collecting public documents from your organization and using these same techniques against you. Are they already happening now? I bet they are, but are they happening on a much wider scale? Not that I have seen, but they could easily happen. We need to keep this in mind when tracking these attackers. Things can quickly change and it is much easier to start thinking about it now than reacting to it later.