Services

The dirty dozen

So it's "Do not pass go and do not collect £200!" – but I'm going to get you anyway. However, first I need a cup of coffee. When I take the opportunity to explain to my wife that it looks like the iPhone video isn't going to happen and that I will probably block the computer for a while yet, my wife first insists "Sergei, go to bed dot com" but then softens, "Yes alright, go for it – I'll see you in the morning..." Oh well, that's fine by me.

When I take a first obligatory look in the hex editor, the CWS at the beginning tells me that this is a compressed Flash file; of course, abcdump digests it without difficulty regardless. Several pushstring instructions already catch my eye when I first browse through the abcdump listing.

This means twelve rather long character strings are being pushed onto the stack. Only when taking a second look do I realise that the strings vary at least slightly in the details they contain further down the line. Next, the P-code identifies the current Flash player version:

93 getlex flash.system::Capabilities95 getproperty version

and then even differentiates between a browser plug-in such as those used by Mozilla etc

103 pushstring "PlugIn"105 ifne L2

and an ActiveX control

192 pushstring "ActiveX"194 ifne L8

which points towards Internet Explorer. I know where this is going. And bingo – the code is comparing version numbers. It is willing to accept exactly six strings:

"WIN 9,0,115,0"

"WIN 9,0,16,0"

"WIN 9,0,28,0"

"WIN 9,0,45,0"

"WIN 9,0,47,0"

"WIN 9,0,64,0"

Six versions of Flash on two platforms makes twelve!

When this master exploit encounters one of these twelve combinations, it will unpack the string by interpreting it as a hex-encoded byte sequence, and then reload this code as a Flash file via loader.loadBytes(). I don't believe it: A Flash file which is decoded dynamically and then loaded proceeds to load another dynamically created Flash file from a repertoire of twelve strings. But it's true. When I copy the first string into my hex editor, I can clearly detect the structure of a, this time uncompressed, Flash file.

That's what I call professional! The various versions of the Flash environment differ to such a degree that exploits which rely on specific addresses only cause the Player to crash, which doesn't serve the attackers. Therefore, they either have to write very generic shell code – which is quite difficult, or they arm themselves with an arsenal of very specific exploits and then choose the one that fits the respective Flash Player. Quite obviously, our little criminal has chosen the easier way and is carrying a whole arsenal of weapons.

It's already 1 am and I should really be going to bed – but I want to inspect at least one of the exploits beforehand. So I start IDA Pro and launch the disassembler. Right at the beginning, there is a little decryptor designed to unpack the rest of the code.

The instruction call $+5 pushes return address 0xF0 onto the stack and jumps right to the next instruction. This instruction uses pop EBP to shift the return address to the base pointer register and then moves the pointer on by 20 bytes. As a result, the pointer points to the beginning of an encrypted data block. The ECX register receives the value 395, which is the number of bytes to unpack, and AL receives 0x3D, which is the value of the XOR mask.

This is child's play for the decoding functions of IDA Pro, and a few moments later I've unpacked the code, saved it, loaded it again and disassembled it.

And – surprise! – the shell code looks almost identical to that of yesterday evening. It ultimately downloads a file from the attacker's web server and executes it to gain control of the system.

I should have known that it isn't a good idea to click through the search engine results of a topic as hot as this. Criminal gangs have long had their own search engine experts who continually monitor Google trends. When a new topic emerges, they use their legions of compromised systems to push their own pages with their web exploits to the top of the list of search results. However, it does surprise me just how successful they are with hijacking current topics.

And that malware authors now use the obfuscation strategies already known from conventional Win32 malware in virtual environments such as Flash is bad news for the anti-virus vendors. Because it ultimately means that AV vendors will from now on also need to emulate the run-time environments of JavaScript, the .NET framework and Adobe Action Script to reliably detect malware. Oh, it's a bad world – and high time for me to go to bed and pull the blanket over my head. (ju)

About CSI:Internet

In our "Crime Scene Investigation:Internet" series, experts examine suspicious files using every trick in the book. Watch over their shoulders as they track down malware – because all this really could have happened. All the malware samples shown in CSI:Internet have been used in real attacks and have been analysed using methods including those described. The accompanying narratives are inspired by real incidents. ;-)

The author of this episode, Sergei Shevchenko, has more than 10 years of practical experience in analysing malware. He is the author of the automated threat analysis system ThreatExpert, offshoots of which include behavioural detection system Threatfire. Sergei works as Leading Malware Analyst at PC Tools in Sydney, Australia. This episode concludes the CSI:Internet series for the time being. However, should we receive a sufficient number of requests, we might be persuaded to publish a second season ;-)