Who ordered spam? New trick in PDF malware uncovered

PDF icon Over the past month SophosLabs has been monitoring a particular spam campaign with attached PDF malware (Troj/PDFJs-RD, Troj/PDFJs-RE and Troj/PDFEx-EK).

The spammed-out emails had message bodies like the following:

Guten Tag, XXX XXXXXXXX,

Wir danken Ihnen fur Ihre Bestellung und teilen Ihnen mit, dass Ihre Bestellung in Arbeit genommen ist und moglichst schnell abgeschickt wird. Die Nummer Ihrer Bestellung ist 974838-387291. Die Lieferzeit betragt ca. 2=855 Tage. Bitte merken Sie sich, dass wir in den meisten Fallen bestrebt sind, Ihnen Ihre Bestellung so schnell wie moglich zuzustellen.
Sie konnen sich auch jederzeit im Ihrem Account auf unserer Website einloggen und den Stand der Bestellung uberprufen.

Wenn Sie noch Fragen haben, schreiben Sie uns per E-Mail [email protected] . Sobald Ihre Bestellung abgeschickt ist, werden wir Sie uber ihre Beforderung bis zum Lieferzeitpunkt informieren.

Wir mochten uns noch einmal fur Ihre Bestellung bedanken und werden froh sein, Sie unter unseren Stammkunden zu sehen.
Informationen uber Zahlung und Zustellung sind in der zugefugten Datei zu sehen.

Mit freundschaftlichen Gruben
Luci Smith

and

Thank you for ordering from Puremobile Inc.

This message is to inform you that your order has been received and is currently being processed.

Your order reference is 123456789.
You will need this in all correspondence.
This receipt is NOT proof of purchase.
We will send a printed invoice by mail to your billing address.

You have chosen to pay by credit card.
Your card will be charged for the amount of 1234.00 USD and "Puremobile Inc." will appear next to the charge on your statement.
Your purchase information appears below in the file.

Puremobile Inc

Attached to these messages were PDFs that have names like “Order_123456789.pdf” or “OrderN25031176.pdf”. When run under Adobe 8.1.1 or Adobe 9.3 they would connect to a remote site and download more malware (often Spyeye, ZBot or FakeAV).

The PDFs did not seem to be using any exploit that I could see and yet they were downloading malware.

/Filter [ /FlateDecode ] /DecodeParms [<< /Predictor 12 /Colors 1 /BitsPerComponent 8 /Columns 1 >>]/Type/EmbeddedFile

All the samples contained a stream with that had the above properties.

Here’s the deflated stream:

013c023802f10208020302fc02f50213
02f102bb025802f502ff0202020502ca

After scratching my head for a while I asked Adobe what was going on, They replied that the files were exploiting the CVE-2010-0188 vulnerability (fixed in their APSB10-07 patch) and I was surprised because we have detection for that as Troj/PDFJs-II and Troj/PDFJs-JN.

Files exploiting the CVE-2010-0188 vulnerability normally use an XML file to encapsulate the TIFF file and this weird deflated stream has a 0x3c character (ASCII: <) which is the opening of an XML stream the rest looked like binary garbage.

So, I searched the PDF documentation for DecodeParms and found a clue in Adobe’s reference material:

"Some filters may take parameters to control how they operate. These optional parameters shall be specified by the DecodeParms entry in the stream’s dictionary"

– Source: PDF 32000-1:2008

Basically, the stream uses a PNG byte difference compression algorithm to encode the data.

In this case, Predictor 12 mean PNG UP method, BitsPerComponent 8 means the largest value is 2^8 (256 or 0x100) and Columns 1 means we split the data into rows of column width 2 i.e.

013c 0238 02f1 0208 0203 02fc 02f5 0213 02f1 02bb 0258 02f5 02ff 0202 0205 02ca

The 0x01 and 0x02 bytes can be stripped off and the decoding routine is:

Up(x_i) = Raw(x_i) + Up(x_i-1)

So:

0x3c == < 0x3c + 0x38 = 74 == t 0x74 + 0xf1 = 0x165 (modulo 0x100) = 0x65 == e 0x65 + 0x08 = 0x6d == m 0x6d + 0x03 = 0x70 == p 0x70 + 0xfc = 0x16c (modulo 0x100) = 0x6c == l 0x6c + 0xf5 = 0x161 (modulo 0x100) = 0x61 == a 0x61 + 0x13 = 0x74 == t 0x74 + 0xf1 = 0x165 (modulo 0x100) = 0x65 == e 0x65 + 0xbb = 0x120 (modulo 0x100) = 0x20 == <space>
etc.

Maybe you’ll find it simpler if I spell it out:

<template<space>

While decoding this properly is advisable, an invariant property of the algorithm is that that the last n-1 of a string length n will have the same byte difference no matter what is before the start of the string.

The ‘unction’ from ‘function’ will always have the byte difference: