Les vulnérabilités du VPN vous préoccupent ? Découvrez comment profiter de notre solution de migration VPN qui inclut 60 jours de service gratuit.

Blog Zscaler

Recevez les dernières mises à jour du blog de Zscaler dans votre boîte de réception

S'abonner
Recherche sur la sécurité

Analyzing PDF Exploits For Finding Payloads Used

image
THREATLABZ
mars 09, 2011 - 4 Min de lecture
We have written a couple of previous blogs which focus on an in-depth analysis of PDF exploits as this is yet another techniques used by attackers to package malicious code and avoid antivirus detection. We have also written in the past about different decoding filters used to hide the malicious code inside PDF files. In this blog, we will examine yet another in the wild PDF exploit which has hidden it’s malicious code under different objects. We will also identify the final payload used to carry out the attack. The malicious PDF sample was retrieved from “hxxp://sj1s.co.cc/games/pdf.php?f=21”. Here is the PDF source code:

Image

 

 

 

The above PDF file is small in size and contains clear text JavaScript. Let’s look at object 1, which contains malicious JavaScript code. This code is very simple to read and understand. The JavaScript accesses some property values declared elsewhere such as “this.producer”, “this.subject” etc. Now, where are those declared values coming from? If you look at the object 3, you will notice that all other variables are accessed from these object properties. The strings used like “eval” and “StringfromCharCode”, suggest this JavaScript is used for malicious purposes. Now, we have 3 different strings from object 3, which will be used in the malicious JavaScript code.

1) Property Producer contains a long array of values
2) Property Subject contains string “eval”
3) Property Title contains string “StringfromCharCode”

We will use Malzilla for decoding this malicious JavaScript. For that, we need to substitute the respective values into the variables. We will re-create the JavaScript code for Malzilla using those values to as it with the decoding process. We will need to look at the code carefully, because the array contains some substitution and arithmetic operations. Here is what we need to substitute:

Image

 

 

 

 

 

Let’s take the first value from the Producer property array, which is “t9.5*w”. The malicious JavaScript contains one variable “w”, declared with a value of 4 and then there is another function (axp = axp.replace\(/t/g,'2'\);), which will replace character “t” with value 2. So the first integer of the array will become (29.5*4) = 118. When we substitute the whole array with values of “t” and “w” we can create the final simple JavaScript code:

Image

 

 

 

We will now decode the above simplified code using Malzilla. The decoded content is shown below:

Image

 

 

 

The decoded content contains malicious heap spray code, shellcode and code for attacking different Adobe vulnerabilities. However, we have to yet identify what this malicious code does once it exploits the vulnerability? What payloads does it use for the exploit? For this we need to identify the shellcode used. Here is what the shellcode looks like:

Image

 

 

 

The shellcode used, is in %u Unicode-encoded format. We will convert this code into byte code or executable code for further reversing using IDA pro or OllyDbg. For this, we will use favorite online tool Shellcode 2 EXE. We will copy and paste the shellcode bytes from the variable, which will generate a sample “.exe” file to analyze. Here is the screenshot:

Image

 

 

 

Now, we have executable file to analyze. So let’s open in IDA pro first to look at the strings used inside the payload. Here are the strings found,

Image

 

 

 

The string shows that this payload is going to download additional files on the system. Now let’s open this file in OllyDbg for obtaining the malicious URL used inside the payload.

Image

 

 

 

The shellcode starts with NOP instructions followed by another loop which will decode the malicious code. Look at the instructions above, inside the highlighted box. Those are the instructions which are used to decode everything. By stepping through the code, we come to know that there is an instruction that will compare the value with E9 to exit and another, which is XORing byte with a value of 31. We will put breakpoint at the RETN instruction. The code will successfully run and we will be presented with the decoded content, which contains more interesting strings.

Image

 

 

 

Look at the highlighted string above in the dump area. This URL will be used to download another binary from the server. Now, we have identified this malicious payload and the URL used. For reference, here is the result from ThreatExpert for the same shellcode.

 

That’s it for now.

 

Umesh

form submtited
Merci d'avoir lu l'article

Cet article a-t-il été utile ?

dots pattern

Recevez les dernières mises à jour du blog de Zscaler dans votre boîte de réception

En envoyant le formulaire, vous acceptez notre politique de confidentialité.