Update: I added in some comments to the Origami library to show me the password used to encrypt the documents. The user encryption password used for the samples I have was a null password. If you would like the modified library, email me.
In one of my last posts I took a look at what likely made the 2462 files I saw floating around. The techniques were poor and the generated PDFs were predecitable given the structure changed very little. I happened to come across a couple other files and had a hard time figuring out how to make any sense of them. The object structure did not add up and it appeared the document was corrupt, yet it still exploited the machine. I came across a posting from MalwareTracker and realized what I was dealing with.
Two of the samples I had were targeting Lockheed Martin and Monsanto, but I was only able to decrypt the Monsanto document without error. Unfortunately, PDF X-RAY does not support the ability to decrypt these documents, but you have two options. You can submit your document to MalwareTracker or you can use the Origami framework and their pdfdecrypt tool.
Below are the PDF X-RAY links for each document with the first being the encrypted version and the second being the decrypted version.
If you want the samples along with the other files I have looked at, jump over to contagio dump.
Located within an extension of the PDF specification is the outline for the AESv3 encryption definition. At times the explanations are a bit difficult to follow, but what you need to know is that AESv3 is considered version 5 of encryption and is represented as “/V 5″ or “AESV3″ within a “/CF” dictionary.
Also dropped on the system are several files located within “C:Program FilesCommon Filesrelease” and an exe named “zfkeymonitor.exe”. These files are unrared to the system I attempted to run this file under multiple different settings and was not able to have it load properly. I am not certain what this file does, but VirusTotal shows no hits and Google doesn’t return any detailed results. If anyone has any ideas on what zfkeymonitor is or might do, feel free to email me and I will share the exe.
It is said that these attacks and documents were the work of Chinese groups. Given the extreme difference in document generation and dropper usage, it appears that two different groups are potentially working together to steal information. Throughout my analysis I made several notes of Chinese-related information.
- Use of “XIANGU” within the metadata and computer build path (object 7)
- “zh_CN” listed as locale (object 8)
- zfkeymonitor results in a large amount of Chinese search results
It is clear to see that this document is far more advanced in regards to its construction. The encryption, use of object streams and bigger size all point to a more sophisticated method of generation, but the tool use to create this document may not be custom at all. The metadata contained within Object 7 identifies the creator as “Adobe LiveCycle Designer ES 8.2″. Normally I would shrug this data off as being less useful, but what follows are several conditions for how the file was generated.
These definitions include compression level and reader settings for when the file is opened. When I built documents using LaTeX I had the ability to specify a compression level to dictate how compressed the output file would be. The more compression I defined, the more ObjStms were used inside the document. This document contained a lot of features that are hard to replicate in custom code, but something like this would be easy for an Adobe product.
If the creator of the document turned out to be true, then this means anti-virus and researchers need to step up their analysis. Why? Well, these documents were able to bypass a lot of anti-virus vendors due to the newer encryption used. Most parsers lack the ability to decrypt these files making it difficult to perform analysis.