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.
16 pushstring "4657530825060000300A00A000
0C03034411080000004302..." // truncated very long string
18 coerce String
21 pushstring "4657530825060000300A00..."
23 coerce String
79 pushstring "4657530825060000300A00..."
81 coerce String
83 setlocal 12
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::Capabilities
95 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"
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.
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
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.
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 ;-)
The "CSI:Internet" series was originally published in c't magazine starting with issue 13/2010. The first episode was "Alarm at the pizza service". For other episodes please refer to our CSI:Internet HQ page