9b+

Update: Upon further analysis of this and other files that appeared releated, this dropper appears to be a modified version of zxshell. 

Thanks to Binjo for the translation help and Nick Bloor for assisting with testing and analyzing zfkeymonitor.exe. 

A couple weeks back I did a write-up on one of the CVE-2011-2462 files that used AESV3 and dropped zfkeymonitor.exe (3765ea5a84df0240f550648a512205fd) along with svchost.exe (5d8d3373f1ded2ee3c0edf9e4dbf117a) and a couple DLLs. At the time it was unclear what role, if any, zfkeymonitor played in the exploit, but more importantly, it was unclear what this exe was or where it came from.

Below is a detailed technical analysis of the files dropped on the system, how they work together and a bit about the malware itself. In between the analysis will be some information on zfkeymonitor and a bit of background behind the file and its true use. 

After executing the PDF file, svchost.exe is dropped on the system and executed. If we disassemble and view the imports and strings a couple details stick out. Specifically the use of WinRar in the executable and the call made to ShellExecuteExW.

Debugging the EXE reveals that WinRar is packed within the binary and used to extract an archive to "C:\Program Files\Common Files\release". This archive contains data that will eventually be used by several other DLLs and processes. 

DAT files are typically application specific and if we open these up an any editor the contents reveal nothing to us. The INI file however uses base64 encoding to mask some of the parameters. Decoding these values reveals the command and control IP address observed when infecting the virtual machine. 

This INI file is later loaded from a hidden DLL, but even without knowing this, replacing the C2 IP address with our own testing server reveals that this file dictates the primary C2 node. 

Having the malware connect back to our lab machines also reveals what would have been sent to the attacker. This information includes the computer name, processor information, RAM and a few other details.

Keeping the DAT files in mind, but moving on, we can begin to debug rundll32.dll . Out of all the routines within the DLL, a few standout given their reading of the DAT files and mentioning of yet another EXE file to be executed (this time with WinExec). Identifying the use of the DAT files is important, but IDA doesn’t show which DAT file is being called upon in each of the routines.

If we load the DLL into Immunity Debugger and call the “Execute” function then we can traverse through the code until we get to the proper subroutine. From the stack it is easy to see that “zblock” files are being loaded first using CreateFileA with generic read access and read into a buffer using fopen. 

When stepping through the code in the debugger it is obvious that each loaded file is being ran through an XOR routine with the key of 0x05. Each zblock#.dat file is read into memory, XORed and then put all together. Once these files are put together, WriteFile is called and “zfkeymonitor.exe” is created before being executed.

To validate this, a simple script was used to manually XOR the DAT files using the 0x05 key. It is worth noting that zfkeymonitor.exe is a signed executable whos author appears to be Shandong Zhongfu Information Industry Inc.

zfkeymonitor.exe is called with no arguments and loads zfulib.dll (874416bb1e8327b59b58c790d7888f9c) into memory. Before stepping onto the next DLL, it is worth spending some time on zfkeymonitor as little search results turn up on the EXE itself. Within the digital certificate we can see who signed the executable, but it is unclear whether or not this file is malicious. 

Several Chinese websites turn up little documentation on the file, but do reveal some interesting details. A doc file downloaded from sjdw.gov.cn isn’t much of a help until we load it into Google Docs. Doing so accurately interprets the character set which we can then copy and paste into Google Translator to get a general idea of what’s going on.

This document identifies that zfkeymonitor is used to manage and handle digital certificates. In order to procure drug products in the Shandong Province, one must request a certificate in order to authenticate with the access portal. zfkeymonitor helps facilitate this process and appears to have a legitimate use. 

Also, the file downloaded included CertReg.exe and was not signed like the one dropped by the malware. Loading both into IDA did not reveal anything suspicious, but our file also shipped with its own zfulib.dll. 

Upon further inspection, the dropped zfulib DLL performed the same XOR operation on the set of iblock#.dat files therefore mapping yet another DLL into memory. Running the XOR script against the iblock.dat files provides the same DLL that we could then load into IDA. This DLL was very small and appeared to function as a loader and persistence mechanism for the final malware to be executed. 

It should be noted that executing the zfkeymonitor.exe binaries in several scenarios eventually revealed that the dropped zfkeymonitor would run properly even with the older versions DLL. However, when using the older version of the DLL, DAT files were not read by the process and remained ignored.

It appears that zfkeymonitor was used in this attack not for its digital certificate functionality, but instead because of its signed status. Having a signed executable means you have more privileges and access to run on the system. The DLL pulled in by the signed process allowed the malware to bypass certain UAC controls put in place by later releases of Windows. The following link reveals more information about this abuse.

After understanding the order of execution, the last and final set of DAT files were decrypted by rundll32.dll using the same 0x05 key revealing the main malware. This file was another DLL that handled the outbound connections, command interface and cleanup of some of the dropped files that were written to the system. 

After walking through several of the subroutines that branch from the main switching cases, the following functionality appears to be present.

• spawn command shell
• restart the host
• shutdown the host
• uninstall all files from the host
• capture user screens
• record and transmit video
• record keyboard events

When transmitting back to the C2, it appears that the malware writes to HostID.dat as a temporary location to store the data and then deletes the file. 

At present, the only vendor to mention or even try to associate this dropper to a class of malware is Microsoft. Unfortunately, they classify this entire threat as "zfkeymonitor" which does not appear accurate.

Summary

Dropped files on the system:

• scvhost.exe (core dropper)
• DAT files (used to construct EXE and DLLs)
• zfulib.dll (deleted)
• zfulibblock.dll (failed to delete)
• ini.ini (main configuration)
• exit.log (never used)
• zfkeymonitor.exe (deleted)
• clean PDF document
• rundll32.dll

DAT files are XOR encoded using 0x05 as the key and decode to reveal the following:

• zblock - zfkeymonitor.exe
• iblock - install.dll (registry settings and loading)
• mblock - mydll.dll (malware functionality)

Command and Control

• 69.197.132.130
• Windows Server 2003 Enterprise Edition (Chinese language pack)

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.

https://www.pdfxray.com/report/7eab072b76abc4c3e8cba8173c79890c/

https://www.pdfxray.com/interact/62c2b73b15b7729d4d8ab6086fd17b1d/

If you want the samples along with the other files I have looked at, jump over to contagio dump. 

Identifying AESv3

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. 

Since this data is defined in the encrypted file, you can identify encrypted files with a quick search. 

Usual Suspects

Once the file is decrypted, you are presented with 85 objects, but most of are not important to the actual exploitation. Object 4 contains what appears to be the same malformed U3D object located within the previously analyzed documents. 

Located within Object 63 is the JavaScript used for the heap spray. This doesn't appear to be very different except for the code sprayed. Putting this into JSbin with the JavaScript hookers outlines essentially what the JavaScript does. 

The definitions for the 3D content and JavaScript were located within several ObjStms making them more difficult to find. 

Running the Document

After running the document a Monsanto clean document is shown to the user.

Connections are made through HTTPS to 69.197.132.130 (appears to be down).

The first file touched on the system is AAAA which is the clean PDF documented (44 pages). The initial malicious file dropped onto the system is "svchost.exe" which has a low detection rate when sent to VirusTotal. This file loads a new exe named "rundll32.exe" that appears to be responsible for the remote connection handling. 

Also dropped on the system are several files located within "C:\Program Files\Common Files\release" 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. 

China Connection

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

Generator Thoughts

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. 

There is no honor amongst thieves and malicious code writers are no different. Why would anyone go through all the work of writing an exploit from scratch when there is a good amount of boilerplate available? When I first took a look at this 0day PDF attack I noticed the string "a pwning u3d model". A quick google search leads you to an older exploit (CVE-2009-2990) PoC written by Felipe Andres Manzano with a lot of matching details. Below is a walk through of how the attackers may have leveraged this existing code to construct the exploit.

Page Explanation

The working malicious document contained three pages, but it was unclear at first if there were reason behind this. After doing some research I found that one page needed to be blank so the heap spray could execute and then a second page would be needed to render the vulnerable U3D object. Three pages were not required, but were present and below is a screenshot of the code why.

JavaScript Trigger

For the exploit to be triggered, the U3D object needs to be shown. Does it need to be handled through JavaScript? No, in fact, you could create a working document that contains real content with a page that renders the malformed U3D module. When the user scrolls to that page it will execute the exploit. The reason for the trigger is to avoid any user interaction ensuring a higher chance of exploitation. 

Above shows the use of "app.platform" and "this.pageNum" by Felipe's code. It is worth noting that the platform check is not necessary and was likely left in by the attackers because of laziness. Felipe included this only to differentiate between which exploit to fire since he had both Windows and Linux.

U3D Annotation

For the exploit to work a U3D annotation needs to be created. This annotation essentially defines the U3D object and how it is going to render within the document. Below is Filpe's code to generate his annotation. 

This is an exact match to what we see within the malicious document. 

Small Matches

Observed within the malicious document were a couple things I didn't quite understand. Within object 7 for instance was a flatedecoded "(Aaaaa) Tj". This value doesn't appear to play any role in the exploitation, but it is also included in Filpe's code. Also included is metadata defining the author, email and web. While this has changed it is funny to note that the attackers left the matching "googlepages.com" domain. 

U3D Source

Obviously this portion of the code was not stolen, or at least not in its entirety. Within the U3D content are several strings that identify parts of the human arm. There has been a link circulating on Twitter of a Swiss FTP site containing code to generate a U3D stream with the same strings found present in the malicious document. Without the full source it is hard to say if this code was modified to produce the exploit, but it is a theory worth listing. 

Analyzing the Attacker

When looking at these attacks I like to try and understand how the attacker may have generated the document and the reason behind their process. There is an old saying that goes "if it ain't broke, don't fix it". I think this is highly applicable in this case as the attackers likely just modified what was already working. All that needed to be replaced was the heap spray code which was easily defined and the U3D stream. 

Given the static data present in all the samples I have, I also believe that the tool used to create this document has little modularity or sophistication. For this reason alone I have a hard time believing this attack was created by a nation state government. Instead, I think this was done by a small group of people who's motivation would be to support their government and send data back to them. This sort of behavior fits the Chinese hacker model and gives a bit more value to the Chinese traits identified within the document and dropper. 

Conclusions

Doing development makes people lazy which is great, but not when you are writing exploits. The attackers re-used code that was publicly available and therefore makes our jobs as incident responders easier. Until any changes are seen within the documents being sent out, I think it is safe to say we have a good list of static signatures that can be used to identify them. This attack also shows that attackers read what researchers publish and sometimes put it to use. More value needs to be placed on proof-of-concept attacks and what attackers could do before it actually happens. 

Introduction

On December 7^th, Brandon provided his analysis of a malicious PDF (MD5: 517fe6ba9417e6c8b4d0a0b3b9c4c9a9) which utilized an Adobe Reader 0day (leveraging a U3D vulnerability). After successful exploitation the PDF drops a windows executable (MD5: E769A920B12D019679C43A9A4C0D7E2C). The file named pretty.exe, then drops DLL_101 (MD5: BA7793845FE2A02187263A96E8DAAEC6) which is stored as a resource in pretty.exe.

Analysis

Symantec posted a blog that well describes the threat. In this post we provide additional detail specific to the executables delivered from the initial PDF.

Dropper:

The attacking PDF extracts and executes an initial dropper as ctfmon.exe and then renames it to pretty.exe. The purpose of this executable is extract another executable (stored as a resource) and inject it into other processes.

Resource 101:

This file is the primary payload of the executable, and appears to be a Sykipot variant. The binary itself is not packed or otherwise protected. The various C&C systems are hardcoded and easily read strings. The binary has no obvious VM detection or anti-reversing strategies. Further analysis is generally straightforward via static analysis primarily following library calls.

This executable works by stealing the process token from Explorer.exe and then injecting into one or more of the following processes:

1. IExplorer.exe
2. Firefox.exe
3. Outlook.exe

The injected executable then sleeps before checking into the C&C server where it obtains orders to perform so actual function. The known command set is as follows:

The command and control features are hard-coded and readily visible in the binary as seen here:

C&C is done via SSL to : hxxps://www.prettylikeher.com/asp/kys_allow_get.asp?name=getkys.kys&hostname=[COMPUTER NAME]-[IP-ADDRESS]-pretty20111122

The IP at time of discovery was: 71.36.88.82

Temp Files:

The following temporary files are dropped:

1. gtpretty.tmp
2. ptpretty.tmp
3. gdtpretty.tmp
4. pdtpretty.tmp

The list of temporary files is seen in the source code below:

An example temporary file:

Adversarial Model

The use use of a PDF 0day in itself demonstrates advanced capabilities. The exploit itself is reliable accross several platforms. The dropped executables analyzed in this post do not demonstrate any advanced capabilities. Their functuality is non-modular and non-scalable. It appears to rely on limited hardcoded C&C servers. However, the functonality is concise. It appears to be the work of multiple individuals but isn't clobbered together. Further, if one considers that as a user driven attack that delievers a file to disk and targets a highly capable orgnization, this attack had a high likeliness of detection. Therefore, leveraging this type of trojan has a certain logic.

One brief clue that could indicate origin is illustrated below:

As you can see, the language set appears to be Chinese.

Files

Original files:

http://www.mediafire.com/?nqnw5bv8zc4fxtv

The decompiled source code (thanks to IDA and HexRays) is available here:

http://9bplus.com/files/pretty.c

http://9bplus.com/files/dll-101.c

No guarantess on the accuracy of the analysis - it was done quickly and in "spare" time.

This is a super short post, but I wanted to put it out there for those attempting to identify the specific bug and trigger for the exploit. My theory is that object 10 (see my earlier post) is the whole show. In other words, as long as you have the U3D content in your document, it should in theory trigger the bug. I believe this because the JavaScript merely functions as a heap spray and then makes a call to a specific page within the document. This page contains the annotation reference to the 3D content and therefore causes it to display. To merely display a page, you don't need JavaScript. 

To recycle content, we must first go steal it. I took the sample I had, loaded it in peep and then saved the contents to a file. You can download the U3D raw object content from here. I then used Didiers make PDF tool and hardcoded the values I knew needed to exist. This mainly consisted of the single page, the 3D definition and then the actual 3D content. 

I executed the output file on Windows XP SP3 running Adobe 9.4.6 and was able to get a successful crash (doesn't bypass DEP). Obviously this is not a working exploit, but it does show that there is potential to throw your own heap spray code into the mix and gain execution. A few things to point out before you get too excited though. OpenAction is not required because we only have one page. It would be required however if we were to include JavaScript, so at the end of the day, a few things will need to be put back for a production exploit though I do think one page is all you need assuming you time your spray properly with the 3D render. 

Here is the code to generate the test document I have (seriously, it's horrible):

Object 10 U3D decoded contents

Sample generated document

Before I went to bed last night I took a look at uploaded files to PDF X-RAY in hopes that Christmas would come early (CVE-2011-2462 in my reports) and was surprised when I came across a file with /U3D references. I snatched the file off the server, opened up my snapshots to the latest 9.4 build of Adobe and ran the file. Reader crashed, and a new document was succesfully opened. That was enough to stay up, so analysis started and can be found below. 

Bug Sample Viewing

https://www.pdfxray.com/interact/517fe6ba9417e6c8b4d0a0b3b9c4c9a9/

Object Execution Flow

1. Object 4 - OpenAction fires reference to JavaScript
2. Object 14 - JavaScript reference to object 15
3. Object 15 - JavaScript code does heap spray and then directs to page "2"
4. Object 11 - Definition of 3D data and how it should be formatted
5. Object 10 - 3D data that is to be rendered (likely the corruption)

Objects of Interest

• Object 10 - References to named dictionaries - /3D, /U3D
• Object 11 - References to named dictionaries - /3DI, /3DD, /3D, /3DA
• Object 15 - Contains JavaScript routine for heap spray and page redirection (triggers render)
• Object 16 - Fails to decode properly, but not referenced (clean file dropped on successful exploitation)

Understanding the U3D Components

Within object 11 is the definition of how the U3D content should be displayed within the PDF. Understanding of the named dictionaries is helpful when trying to isolate the bug being exploited. Below is a listing of named dictionaries used and a short definition:

• U3D - currently the only supported subtype and 3D object
• 3DD - (required) - specifies the stream or dictionary with the 3D data that is to be rendered
• 3DA - (optional) - activation dictionary defining the times of when the 3D data should be shown
• 3DI - (optional) - boolean value that defines the primary use. true defines an interactive use and false defines interaction through JavaScript
• DIS - (optional) - name specifying the state of the 3D data upon deactivation (i is used for instantiated) 
• A - name under which the annotation should be activated
• PO - annotation should activate as soon as page containing the annotation to the 3D data is opened

Details worth pointing out

Within some of the metadata, the following was found:

<< /email (fo@gmail.com) /Author (Fo) /web (fo.googlepages.com) >>

Googlepages appears to since moved to Google Sites, so this page is no longer active. 

Object 10 Hash - 773793a36f0ba12e6e48f8483b845500 and content download

Breaking apart the JavaScript

Like most JavaScript observed in other malicious files, checks are done for the proper version number before the main routines are executed. What is interesting about this document is that it checks for versions that do not exist and makes a point to redirect the user to an infinite loop assuming they are running a version great than 10. 

Assuming the version requirements are correct, the main heap spray function is invoked. The final call to “zzzzzzzzzzzz()” appears to be the main spray routine and setup. After the spray is complete, another spray follows with generic padding and then some Adobe specific calls. What is interesting to note are the calls that follow. 

A call is made to check whether or not the platform is a Windows machine and then Reader is told to move to page 2. I believe this portion of the code is the trigger for the rendering of the 3D data. Page 2 contains references to the annotations and content of object 11 which defines the 3D data to display (object 10). Without this, I am not certain the vulnerability would be triggered and is likely called manually to ensure enough time was given to spray into memory.

Running the PDF

Using Adobe Reader 9.4.6, the PDF was executed resulting in a crash and opening of a new document. This new document is a survey geared towards defense contractor ManTech. 

The first file to be dropped is "ctfmon.exe" which is later "pretty.exe" after several registry changes.

This file has a fairly high detection rate according to VirusTotal.

http://www.virustotal.com/file-scan/report.html?id=b9231471a9af849ccf3690ebc12cdc7ac4d942f6e417ba7261e7a4414bf1e329-1323275615

Also, dropped shortly thereafter is a .TMP file which appears to be a DLL..

http://www.virustotal.com/file-scan/report.html?id=21d58245c495b9ed4234577fa3fb43cd4c703f38a9b5ce83aa490613168a735f-1323275543

Callbacks are not made initially unless certain processes are opened (http://www.securelist.com/en/blog/2335/Sykipot_exploits_an_Adobe_Flash_Zero_Day). I rolled back my snapshot, executed Internet Explorer and then the PDF file. After waiting, code could be seen injecting into Internet Explorer. A PCAP dump of the traffic shows a call out to hXXps://www.prettylikeher.com (note the SSL). Running strings against the running process reveals the following request that would likely be made through the connection:

hXXps://www.prettylikeher.com/asp/kys_allow_get.asp?name=getkys.kys

This file appears to be encrypted in some form, but used within pretty.exe later on. Visiting the site directly shows a automobile site based out of Raliegh, NC. More analysis needs to be done on the dropped binary. These results will be posted soon.