Security PDF-related links in 2010: analyses and tools

After one year full of security issues related to the Portable Document Format I've made a little compilation of useful links to analyses and tools:


2010-01-04: Sophisticated, targeted malicious PDF documents exploiting CVE-2009-4324  (embedded binaries)
2010-01-07: Static analysis of malicous PDFs (Part #2) (getAnnots, arguments.callee)
2010-01-09: PDF Obfuscation (variable substitution, LuckySploit, CVE 2008-2992)
2010-01-13: Generic PDF exploit hider. and goodbye AV detection
2010-01-14: PDF Obfuscation using getAnnots() (getAnnots, arguments.callee, Neosploit)
2010-02-15: Filling Adobe's heap (Javascript, ActionScript and PDF Images)
2010-02-18: Malicious PDF trick: getPageNthWord
2010-02-21: Analyzing PDF exploits with Pyew
2010-03-01: Analyzing PDF Files (getPageNthWord, getPageNumWords)
2010-04-08: JavaScript obfuscation in PDF: Sky is the limit (getAnnots,arguments.callee)

Yet another Oficla email campaign (CV)

This time I've received a nicer e-mail, a woman sending me her CV!! with a picture of her included too!! :) In fact, she has included in the image some words too, a bit strange...

Again the same actors: Oficla and ZeuS. This time not Feodo downloading. Inside the zip file we can find the Oficla sample, with a medium detection rate. It connects with the domain (now it's down) to ask for URLs to download more malware:

The server response contained the same URL (active yet) as the DHL campaign, downloading the same version of ZeuS, different MD5.

Beware with women!! they are not trustful!! ;)

DHL e-mail campaign downloading ZeuS and Feodo

This past month a new DHL campaign has been spreading malware in a zip file. The executable in the zip was identified (with a high detection rate) as Oficla by the Antivirus engines. This malicious code, with filename DHL_Etiqueta.exe, acts as a downloader asking a server the URLs it must use to download the other malicious files. It always uses in the requests the User-Agent Opera\9.64. These are the requests and responses in this case:

Both of the downloaded files, morph.exe and esmilk.exe, are banking trojans. The former is a sample of Feodo, with a low detection rate (7/41), which downloads the configuration file from a server after sending to it a POST request:

Some thoughts and facts about ZeuS MitMo

One month ago David Barroso and me visited one online banking user. David extracted one file from his mobile phone and I picked some ZeuS files up  from his computer.This was the starting point of the so-called ZeuS MitMo.

When ZeuS injects HTML code it usually asks the user for the necessary TANs in order to carry out a fraudulent transaction, but sometimes this information is not enough. Some banks ask for an additional code, sent by SMS, that the user (or criminal) must enter to finish the process. Until that moment this type of authentication (two-factor authentication) was successful, but not since then. This ZeuS gang had modified the configuration files to ask for the mobile phone number too. It's not so strange, but yes using it to commit the fraud. They sent to him an SMS with a link inside, telling the user that he should install that "certificate". When the user installed it, the malicious application began to monitor all the incoming SMSs, looking for the bank SMS and forwarding it to the criminals. This way they already had all the information they needed to make the transaction, game over.

Apart of asking for the user phone number the configuration file had other curious things. When the user visited the online banking URL ZeuS added an script element to the legitimate web page pointing to an URL, avoiding to store all the HTML code in the config file. But this is not the strange thing, it's that normally the src attribute it's an absolute URL while in this case was a relative one:

Spyeye using MitB to make fraudulent transactions

Recently our e-crime team has discovered that Spyeye is using Man in the Browser (MitB) techniques in order to make fraudulent transactions. Thanks to MitB cybercriminals can make the transactions in the same banking online session as the real user, therefore they can do it in a quickly and clean way. I say clean because in the logs of the online banking application there won't be more IPs than the real user ones. It means less proofs in an hypothetical court against the bad guys, for example.

The whole MitB core was written in Javascript and the actions performed to make the fraudulent transaction are the following:

  • When the user goes to the accounts details screen the information (account number, type of account and balance) of all of them are grabbed and sent to the malicious server in a serialized array:

    ["maxCheck" = ["name" = "MY_ACCOUNT_NAME",
               "check" = "MY_ACCOUNT_NUMBER",
               "sum" = $$$],
    "allChecks" = [ 0 = ["name" = "MY_ACCOUNT_NAME",
    "check" = "MY_ACCOUNT_NUMBER",
    "sum" = $$$]


  • From all the possible accounts it's chosen like preferred the one with more money (maxCheck array).

CVE-2010-1797 PDF exploit for Foxit Reader <= 4.0

After the Jailbreakme PDF vulnerability explanation I'm gonna publish the proof of concept of the same vulnerability for Foxit Reader. This is a patched vuln for this product so I suppose there will be no problem with that. Like I said, we can use a 116-bytes shellcode without the necessity of another exploiting stage, so I've modified this calc.exe shellcode for this PoC.

This exploit generates a PDF file which can be used against Foxit Reader in Windows XP and Windows Vista.  This is functional only for the latest versions of Foxit Reader but it's very easy to modify it for other ones (there is an example in the exploit for the 3.0). You can find the python script in the Exploits section or directly here. Enjoy it!! ;)

More about the JailbreakMe PDF exploit

Today has been released the source code of the Jailbreakme exploit, so maybe this explanation comes a bit late. In the update of the previous post about this subject I knew that I was right about the overflow in the arguments stack when parsing the charstrings in the Type 2 format, so here is a little more info.

After decoding the stream of the object 13 we can see the following bytes (talking about this file):


The selected bytes are the important ones for this exploit because the overflow occurs when parsing them. Like I mentioned, the Type 2 format is composed of operands, operators and numbers, and use the stack to push and pop values. This stack has a maximum size of 48 elements. We can understand better the meaning of these bytes with this tips:


About the JailbreakMe PDF exploit

Some days ago Comex published his JailbreakMe for the new iPhone 4 in the Defcon 18. The interesting thing is that in order to root the device he used a PDF exploit for Mobile Safari to execute arbitrary code and after this another kernel vuln to gain elevated privileges. I've being taking a look at the PDF files with peepdf and these are my thoughts about it.

The PDF file itself has no many objects and only one encoded stream:

The stream is encoded with a simple FlateDecode filter, without parameters, and if we decode its content we can see this strings, related to the JailbreakMe stuff:
As this object seems to contain the vulnerability we are looking for we'll take a closer look to this stream and what this is for:

Recovering deleted SMS from the SIM card

Some time ago I wanted to recover the deleted SMS from a friend's SIM card and I tried to find some programs to do it. After some time searching the web I found SIMCon and SIMEditor which made well the job, showing all the SMS slots, deleted and not, with the help of a SIM reader, of course. I was curious about the raw process of these programs so I search the web again ;)

First of all we'll need some software to send commands to the SIM card. I'm a Linux user so I used scriptor, contained in the pcsc-tools package. We need to know what to send and what the SIM card structure is. For this we have the GSM specification, a brief resume of the commands we must send and we can receive, and some information about the directories within a SIM card. These commands are called Application Protocol Data Units (APDU). After reading this links we know that we have to send the following commands:

  • VERIFY CHV (20): PIN authentication.
  • SELECT (A4): selection of the file we want to work with.
  • GET RESPONSE (C0): read the response data.
  • READ RECORD (B2): read the specified record.


Welcome to!! This is my first post and I want to welcome you to this new site. Like I say in the About section I'll try to put content related to the security information but also to many things not directly connected to it but with the curiosity of knowing how the things work.

This site contains some tools, scripts and advisories I've developed or published (or in which I'm currently working). I hope to add many more and that you enjoy it ;)

I've started posting some of my publications on S21sec blog about PDF files and ZeuS, they are a bit old but interesting anyway...

ZeuS spreading via Facebook

ZeuS is still the talk of the town. It's downloaded through fake antivirus, downloaders and several exploit kits. Of course, the best-known social networking site couldn't be out of this. Last week we could see some Facebook messages like the following:

The link in the message would take the users to a Facebook phishing page where they were requested to authenticate. Simultaneously, obfuscated Javascript code was being executed, creating a hidden iframe in the page body:

This iframe redirected the user to another web page with two more iframes:

<iframe g1g="321" src="xd/pdf.pdf" l="56" height="31" width="13">
<iframe g1g="321" src="xd/sNode.php" l="56" height="31" width="13">

After advancing further, we arrived to a directory listing in the same server:

New ZeuS binary

The evolution continues. Some days ago a new ZeuS binary appeared with the version number This new development is an attempt to improve the stealth techniques used to date, as stated in one of the TODO files found some time ago. After just a quick look, one can notice the following changes:

  • When it's executed and the system isn't infected yet, it copies itself in the directory %SystemRoot%/system32, but with a different filename in each execution. Also it gets the basic file information from the %SystemRoot%/system32/ntdll.dll file (creation, last access and modification dates).

  • If it finds a previous ZeuS version installed it deletes the binary, leaves and shows the hidden files in the next reboot. To give an idea of the situation, one of the latest samples with sdra64.exe as executable filename is the 1.2.12 one.

  • Apparently the configuration and data files are not stored on disk anymore but they're exclusively stored in memory.

Detecting ZeuS

In the S21sec blog we have been talking some time ago about our dear friend, almost one more colleague: ZeuS. It is a malware with more than 3 years of life which continues changing and evolving to hide itself better and making the fraud more efficient. But what we maybe have not mentioned yet is how to know if our little friend is here, spying all our movements and reporting all of this to its parents, because sometimes the AV software is not so effective as we expect.

There are several evidences in its different versions which mean that we are infected with ZeuS:

  • Filesystem
  • ZeuS leaves a trace in the filesystem when it's installed in the computer, but it hides and blocks all the files it creates, avoiding that a normal user can see and delete them. The solution to find these files is using antirootkit software which will show us the hidden files.

Analysis of malicious PDF files

As I mentioned before, one of the ways to hide information in a PDF file is trough the encoding/compression of streams, thanks to filters (/Filter parameter), being /FlateDecode the most used. The bad guys have been using it some time ago to hide obfuscated Javascript code with some vulnerable functions (Collab.collectEmailInfo, util.printf, getAnnots, getIcon, spell.customDictionaryOpen), or using heap-spraying to exploit another vulnerability not related with Javascript, like the /JBIG2Decode filter one.

To help in the analysis of these malicious files I've written a mini Python tool, using Spidermonkey to execute the found Javascript code and showing the shellcode to be launched. Automating the execution of obfuscated Javascript code is not a simple issue because there are many ways of doing it and everyday a new one arises, so I've tried to do an approximation to the problem, thanks to the malicious samples that I've seen. In the case the script won't be able to go till the end it's possible to specify the parameter -w to write to disk the Javascript code, helping to carry out a later manual analysis.

Hiding information in a PDF

I'm gonna stop writing about actions in PDFs to begin with the filters that can be applied to the stream objects. An stream object is composed by a dictionary followed by the real content between the words stream and endstream. Within this dictionary are defined the stream properties like size, filters to apply in order to decode/decompress it or the file name in the case of the stream is located in an external file.

As you suppose, a way to hide information in a PDF file is applying to it one or more filters in order to avoid identifying it easily and putting it hard to extract the real content. In fact this is an usual technique in most of the malicious files that try to exploit some of the latest vulnerabilities.

Syndicate content