Friday, March 16, 2012

Basic analysis of APT_1104statment.pdf

The purpose of this blog post is to outline the results of the basic static and basic dynamic analysis performed on the malicious "APT_1104statment.pdf" file.  The premise of this exercise is that I have received the aforementioned file and now want to determine its capabilities and identify any host and network indications of compromise.  Although this analysis is purely pedagogical in nature, the analysis techniques and results may be useful to other computer network defenders. 

This file was obtained from the Contagio Malware Dump.  There were 30 malicious documents included in this sample and I plan on analyzing and blogging about several of these files in the future.

Please note that during my testing, complete exploitation  did not occur 100% of the time; the exploit would still compromise the test system, however several key events do not happen.  Specifically, the "RTHDCPL.exe" file does not get copied to the "C:\Documents and Settings\%USERNAME%\Local Settings\" directory, the "A9R21D2.tmp" does not get deleted and the "~dfds3.reg" file does not get created.  Since the "~dfds3.reg" file is not created, persistence is not achieved.

I am presently unable to determine exactly why 100% exploitation does not occur 100% of the time, although, if time permits in the future, I may revisit this issue.  It should be noted that content of this blog post is based on the events of complete exploitation.

Basic Static Analysis:
For the basic static analysis I used REMnux, ExifTool, PDF Tools and PDF Stream Dumper to calculate several hashes, view any metadata and determine the exploit capabilities contained in the APT_1104statment.pdf file. 

File Details:
File Name: APT_1104statment.pdf
Size:  91010 bytes
File Type: PDF 1.7
MD5: 86730a9bc3ab99503322eda6115c1096
SSDEEP: 1536:40AOB3HN+RNlmABHf9t/NICdaRTHh9cCJzPw+r4Bh9lSp:40zb+vYABFx2G0BSCNPQvq

When I ran the file through ExifTool I noted several interesting attributes in the metadata and I have outlined these attributes in red in the following image:
Output from ExifTool

Note that the timezone in the create, modify and metadata dates is UTC+08:00.  Note that the title is set to "未标题".  According to Google Translate, "未标题" translates to "Untitled" in English.  Note that the language is set to "zh-cn".  According to the MSDN Library, "zh-cn" is Chinese (PRC).   

Exploit Detection:
The first thing I like to do when analyzing PDF documents is use the PDFiD script to test for the presence of any active content.  When I ran the "APT_1104statment.pdf" file through PDFiD I noted that while there was no JavaScript present, there were 9 ObjStm and 1 AcroForm objects.   

Please reference the following image for additional context:

Output from PDFID

I then opened the file with the PDF Stream Dumper tool in order to determine if any flash files were present.  For good measure I decided to use the exploit scan module available in PDF Stream Dumper to quickly test for the presence of any malicious content.

From what I can tell, PDF Stream Dumper uses a signature based system to detect many known exploits, so it was not surprising that the tool classified the exploit contained in the "APT_1104statment.pdf" file as CVE-2010-1297, CVE-2010-2884 and CVE-2010-3654.  Given that these three CVE's were all for vulnerabilities in Adobe Flash Player from late 2010, this leads me to believe that the exploit contained in the "APT_1104statment.pdf" file also exploits the Adobe Flash Player.

I have outlined the results of exploit scan and presence of the flash file in red in the below image: 

Output from PDF Stream Dumper

I next queried Virus Total for the MD5 hash of the "APT_1104statment.pdf" file and as expected, the results indicate that this document exploits a vulnerability in the Adobe Flash Player as outlined in CVE-2011-0611.

Basic Dynamic Analysis:
For the basic dynamic analysis I used Autoruns, Process Explorer, Process Monitor, Capture-BAT and REMnux to observe the system behavior upon opening the "APT_1104statment.pdf" file.  My goal is to identify any host and network indications of compromise that can be utilized to identify any other systems that may have been compromised by this exploit.

Files Created: 
The following files were created during exploitation testing:

C:\Documents and Settings\%USERNAME%\Local Settings\Temp\A9R21D2.tmp
C:\Documents and Settings\%USERNAME%\Local Settings\Temp\RTHDCPL.exe
C:\Documents and Settings\%USERNAME%\Local Settings\Temp\1.pdf
C:\Documents and Settings\%USERNAME%\Local Settings\Temp\~dfds3.reg
C:\Program Files\Common Files\System\MSMAPI\1033\iso88591

It should be noted that the "iso88591" file is only visible when the "Show hidden files and folders" option is enabled and is created in whatever directory the "APT_1104statment.pdf" file is opened from.

It is also worth noting that since this file will likely be received as an e-mail attachment and opened within Microsoft Outlook, the "iso88591" file will be created in the directory that Microsoft Outlook opens attachments from.  In my testing this was the "C:\Program Files\Common Files\System\MSMAPI\1033\" directory.

It should also be noted that the "A9R21D2.tmp" and "~dfds3.reg" files are deleted and that the "RTHDCPL.exe" file is copied into the "C:\Documents and Settings\%USERNAME%\Local Settings\" directory and is renamed randomly to a seem like a server or service.

Please refer to the following image for additional context:
Files Created
 Processes Created:
The following processes were created during testing:


It should be noted that the original AcroRd32.exe process creates the malicious RTHDCPL.exe process and another AcroRd32.exe process before exiting.  The second AcroRd32.exe process is used to open and display the decoy document "1.pdf".

The RTHDCPL.exe process creates a separate malicious svchost.exe process.  The regedit.exe process is used to import the settings in the "~dfds3.reg" file.  It can be assumed that svchost.exe is used in order to have the malicious process blend in and appear inconspicuous.  

Please refer to the following image for additional context:
Processes Created

Registry Changes:
When the malicious svchost.exe process creates the regedit.exe process, the "~dfds3.reg" file file is used to add the Trojan executable to the "HKCU\Software\Microsoft\Windows\CurrentVersion\Run\" registry key.  This will enable persistence as the Trojan executable will be executed during start-up and will connect back to the attacker's botnet. 

Please refer to the following image for additional context:
Registry Changes

Network Behavior:
The malicious svchost.exe process then attempts to connect to TCP port 443 on host  The process will attempt to connect three times and then will attempt to connect to TCP port 80 if unsuccessful. 

If the svchost.exe process is unable to connect to host on either TCP port 443 or 80, it will then attempt to connect to TCP port 443 on host  If this is also unsuccessful it will attempt to connect on TCP port 80.

Please refer to the following image for additional context:
Network Connections

If the svchost.exe process is successful in connecting to either IP address, it issues an HTTP GET request for a PHP script and attempts to pass an 18 character query string to the attacker's web application.

The name of the requested PHP file is always 5 characters in length and was randomly generated between each iteration of testing.  The first 6 characters of the query string were also unique to each iteration of testing, however, the last 12 characters of the query string remain constant on the compromised system.  At this time I am unable to determine exactly what these characters represent, but given the consistency across multiple systems, it can be inferred that this is an identification scheme.

It is worth noting that the beaconing frequency was approximately every three seconds and that the length is consistently 193 bytes. 

I have outlined these attributes in red in the following image of the HTTP header:
HTTP Header

It should be noted that IP addresses and are hard coded into the Trojan executable as there were no DNS queries observed in the network traffic generated during testing.

It is also worth noting that the network traffic to TCP port 443 is sent in clear-text format and that the User-Agent string in the HTTP header is forged and hard coded to "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)". 

According to WHOIS records, the hostname for is and the hostname for is   Additional analysis of these IP addresses is beyond the scope of this blog post, however, it should be noted that both IP addresses are listed in various known blacklists for spamming and malware.

Decoy Document:
Last, but certainly not least, it is important to discuss what the end user sees upon opening the "APT_1104statment.pdf" file.  There is a momentary observable crash of the Adobe Reader application before the "1.pdf" file is finally opened and presented to the end user; the content of the "1.pdf" file simply reads "Wrong!!".

Analysis of the metadata from viewing the properties and from opening the "1.pdf" file with the PDF Stream Dumper revealed several interesting attributes as well. Like the timezone in the "APT_1104statment.pdf" file, the timezone in the "1.pdf" create date is UTC+08:00.  The original file was created using the WPS Office application.  According to Wikipedia, WPS Office is office suite software created in China by Kingsoft

Please reference the image below for additional context:
Decoy Document Metadata