I figured it out that there are some strings or function like “this.numPages” used inside the code and because of that, Malzilla was unable to decode it. If you observe, this is the first key (i.e. l46bQ8A) which is used to XOR with the original variable (i.e. e208xh). I changed the variable which was using the “this.numPages” function manually to integers such as 1, 2 etc. and tried decoding it once again. Finally, Malzilla started decoding it but the output was still not legible – I’d clearly missed some additional decoding routines. I then realized that there were 2 keys being used for XORing - one was hard coded with value “189” while the other was taking a value from the “this.numPages” function. This function returns the number of pages present inside the PDF file. That means whatever values I was passing to the variable manually, wasn’t correct and the script was unable to decode it. I re-opened the PDF file to search for object which contained the number of pages used inside the PDF and found the exact count,
The exploit was targeting 3 different vulnerabilities.
1) mediaNewplayer CVE-2009-4324
2) collectEmailInfo CVE-2007-5659
3) CollabgetIcon CVE-2009-0927
The detection for this PDF file remains very poor. Here is the Virustotal result for this file – currently, only 6 of 42 AV vendors detect it. This is a really interesting case as the “key” is actually a component of the PDF file and this is deliberately used by the attacker so that the manual decoding becomes difficult for researchers. Even Webpawet failed to decode it properly. This time attacker has used “number of pages” inside the PDF as a key to decode the malicious script code. I expect that we’ll see similar tricks going forward.
What’s your key?