Some months ago I analyzed some PDF exploits that I received via SPAM mails. They contained the vulnerability CVE-2013-2729 leading to a ZeuS-P2P / Gameover sample. Back in June I received more PDF exploits, containing the same vulnerability, but in these cases it was a bit more difficult to extract the shellcode because the code was obfuscated. This is what we can see taking a look at the file account_doc~9345845757.pdf (9cd2118e1a61faf68c37b2fa89fb970c) with peepdf:

It seems that they used the same PDF exploit and they just added the obfuscation, because if we compare the peepdf output for the previous exploits we can see the same number of objects, same number of streams, same object ids, same id for the catalog, etc. After extracting the suspicious object (1) you can spot the shellcode easily, but some modifications are needed:

PPDF> object 1 > object1_output.txt

We can see two “images” encoded with Base64:

And then an interesting array ("bhf"), which seems to contain a shellcode. I say that just guessing, after taking a look at the second pair of characters (EB), a JMP instruction in x86 Assembler:

If we look for references to that array ("bhf") we find this:

var hKrM = Pript1.P6W(Pript1.kQNt1(ezJ.bhf));

The function "kQNt1" converts our array in a unique string of escaped unicode characters, which is then passed as argument to the function "P6W". This other function is defined here:

After two months from this campaign, there was another campaign, dropping Dyre / Dyreza and NewGOZ (new Gameover ZeuS without P2P). In that case there was one more level of obfuscation, the shellcode array was not visible. I mentioned above that there were two “images” encoded with Base64, they contained the ROP offsets and other variables needed for the exploitation. In this new campaign there were two encoded “images” too, but not with Base64 this time, too easy ;p

hCS(sRi(xfa.resolveNode("Image10").rawValue));

Here the function "sRi" is the important one, being "hCS" the "eval" function. The function "sRi" decodes the “images”, but it contains obfuscated variables, so it is a bit annoying performing the static analysis. However, following a bit the execution flow and doing some changes in the code we obtain this clean version:

After decoding the first image we quickly see the shellcode variable again:

If you want to learn how to do this type of analysis, you can come tomorrow to my workshop at Black Hat Europe (this Friday at 9:00). I will be there two hours demoing different exercises, really practical! ;) How good are you? Check it on Friday! :)