Microsoft just published an advisory about a critical security vulnerability in all versions of Internet Explorer (apart from 5 – but no one has that around anymore, right?).

While all versions of Internet Explorer are affected, the risk for everyone running Internet Explorer 8 is lower since it has DEP (Data Execution Prevention) enabled by default. DEP makes exploitation of this vulnerability more difficult so as a temporary workaround you might want to enable it for older IEs (keep in mind that it might break some add-ons).

Microsoft says that so far they only saw exploits against Internet Explorer 6. In a related post (here) McAfee said that this vulnerability was (one of those) used to compromise Google. So, it appears that it was maybe even a cocktail of 0-day exploits used (IE + Adobe).

The Dragon Research Group is a volunteer research organization dedicated to further understanding of online criminality and to provide actionable intelligence for the benefit of the entire Internet community.

About the distro:
The Dragon Research Group (DRG) Distro is a Linux-based Live CD platform. It forms the cornerstone of much of DRG's ongoing research, analysis and development efforts. The goal of the DRG Distro is to build a DRG Network of pods that can securely and anonymously help provide actionable intelligence to the Internet security community. The DRG Distro can act as a passive data collection facility for many common applications such as HTTP servers or if expressly permitted, can help actively monitor malicious Internet activity. It also includes a number of tools that when combined with the DRG Network help provide real-time, usable intelligence to the local pod partner.

Just when you think they couldn't possibly go any lower ... The bad guys behind the Rogue AV scam (see my old diary at http://isc.sans.org/diary.html?storyid=7144 about Rogue AV) are heavily using SEO techniques to make links to their sites appear high on search engines. For example, when using Google to search for "haiti earthquake donation" top 6 hits (!) lead to compromised web sites which in turn check the referrer (they verify if you are coming from a search engine) and, if that is true, redirect you to another web site.

At the moment they are redirecting to scan-now24.com which appears to be taken down.
As posted on numerous places yesterday – if you plan on donating be very careful about sites you visit.

I'm pretty sure that some of our readers had enough of malicious PDF for last couple of weeks. Adobe finally patched the last outstanding vulnerability yesterday (although the automatic installation process on my laptop horribly failed) and on the same day we had a very concerning announcement by Google.

Couple of days ago we received another malicious PDF from our reader Richard. Initially we thought that it's JAOP (Just Another Obfuscated PDF), which it, at the bottom line, is, but it turned out to be much more. So, in this diary I will go through this malicious PDF document (and I promise not to bug you with PDFs any more, unless it's something really interesting). The document I analyzed has MD5 of 12aab3743c6726452eb0a91d8190a473 and the original document name was Us-J-India_strategic_dialogue.pdf.

First thing to check when analyzing such malicious documents is if they contain JavaScript. As mentioned before, Didier's PDF Tools are very handy here. Pdf-parser.py can find JavaScript automatically and in this document it was in object 6. Pdf-parser.py will display the following info for object 6:

That's a bit weird – looks like there are two object 6 in the document, both first generation (trailing 0, obj 6 0). The first one looks pretty weird too – I highlighted the original filter descriptions, notice how obfuscated they are (#NN is hexadecimal ASCII value that can be interspersed with normal text in PDFs). Also, notice that the first object uses two filters: FlateDecode and ASCIIHexDecode. More about the second object below.

Now pdf-parser.py will not automatically unpack this correctly. Depending on the version of pdf-parser.py, it might even only pick the second object since Didier added support for ASCIIHexDecode later, so make sure you have the latest version of pdf-parser.py. My version prints something like this:

We can see that pdf-parser.py printed both objects, but only unpacked the second. In other words, we have to uncompress the first object ourselves. That's relatively easy to do – we can take the binary blob, apply deflate to it (zlib.decompress) and then just ASCII hex decode it.

After unpacking the stream we can finally see obfuscated JavaScript. It tries to exploit two vulnerabilities, util.printd and the latest doc.media.newPlayer vulnerability. In both cases it executes the supplied shell code, which contains more interesting stuff. The shell code is Unicode encoded and, by some coincidence, it even looks like Chinese characters. However, thanks to @binjo and @iamyeh from Twitter I know it's junk ?.

The shell code itself is XORed with 0x67 which makes it easy to find even if you extract it directly from the PDF document by using some of analysis techniques documented by Daniel in his diaries. However, the second stage binary is encoded differently. In order to figure that out I had to debug the shell code. After some tracing it turned out that the second stage binary is (of course) embedded in the PDF document. However, it's not XORed, as is the case typically with such embedding but instead it is RORed! The following code shows the deobfuscation part:

Why did the attacker do this? Well, maybe no special reason, but maybe he's reading our diaries and noticed how Daniel user XORSearch to find embedded binaries (maybe the AV vendors do something similar). This way he made sure that using utilities such as XORSearch will not find the embedded binary.

Besides the 2nd stage binary, there is another thing embedded in the PDF document: another PDF document (hence the diary name PDF Babushka – see this Wikipedia entry if you don't know what a Babushka is). The original shell code that gets executed by the exploit, after starting the 2nd stage binary extracts this second PDF document (which is benign) and uses Adobe Reader to display it. So, similarly to the PDF document I analyzed last week, this one shows a benign PDF document as well, but this time it directly calls Adobe to open it (that previous document dropped another binary). This also explains why pdf-parser.py sees two object 6 – the second one belongs to the second, embedded PDF document. Amazing how much garbage Adobe Reader can eat and ignore.

Back to the second stage binary. This binary is a downloader with some interesting functions. The downloader connects to hxxp://at.epac [dot] to/album/index.htm. This page looks benign, but the first line of the HTML source shows something interesting:

<!-- DOCHTMLhttp://at.epac.to/image/UPDATE.CAB -->

It's a hidden downloader command. While analyzing the downloader I noticed that it also checks for other two keywords: Tuichu and Xiumau – no idea what these are (maybe author's names/handles?).

So, finally, the UPDATE.CAB file drops another executable that injects a DLL into Internet Explorer. This DLL tries to connect to for.toh.info, on port 443 (SSL) but when I tested it the port was closed (or my IP address was filtered – I just got a RST packet back).

And this ends our journey through this malicious PDF document. Regarding AV detection, it is still far away from perfect and shows how we must not rely *only* on AV. The PDF document is detected by only 8 out of 41 AV scanners on VT (here), the second stage dropper is detected by 11/41 (here) and the downloaded UPDATE.CAB file is detected by 8/41 again (here). Sad, isn't it.