I've arrived at a theory – the
SceneCount exploit aims to get the program to jump to the middle of the JPEG image and execute the code concealed there.
Crikey! It's a quarter to two already – but I'll get no peace until I get to the bottom of this. So if this is code, a disassembler should be able to interpret and display it as such. I extract the 336 bytes of the data block into a file and fire up IDA Pro. This should work even with the free version installed on this computer.
On opening the file, IDA starts by complaining that it has been unable to find a valid PE header. It is consequently missing the entry point defined in the header which tells it where the actual code starts, so that it doesn't know where to start disassembling. I tell it myself, place the cursor on the first data byte – the
0xAA – and press 'C'.
Bingo – we've hit shellcode. The chances of getting something so obviously meaningful when disassembling pure data is pretty slim. There's a bit of garbage at the start, but then there's a short NOP slide. The exploit's author either needed to fill a few bytes to reach a specific block limit or he wasn't quite sure exactly where his circuitous jump would land.
What follows is unmistakeable – FS:30 code for determining the base address of kernel32.dll (see also The image of death). The leading XOR and the attempt to access
ecx+30h prevent it from being detected by simple signatures which are triggered by any reference to
FS:30h. The code then works its way through the kernel32.dll export table to determine the relative virtual addresses (RVAs) of various functions recorded there.
In doing so, the author makes use of a popular ruse – rather than searching for the name of a function in plain text, he generates hash values from the names in the export table and compares these with a stored hash value. If the two are the same, he has found one of the functions he's looking for.
This hash comparison is, first and foremost, more compact than a string comparison. Space can be at a premium in shellcode – it's not uncommon for the properties of a security vulnerability to limit the number of bytes available for exploit code. Secondly, it also avoids filling the shellcode with tell-tale strings, thus reducing the risk of discovery.
The shellcode in our Flash clip sniffs out
urlmon.dll->URLDownloadToFile() and then continues on its dastardly way, probably downloading and installing spyware or a bot from the web.
On this occasion it has failed, as the exploit only works on older versions of Flash containing this security vulnerability. I check
about:plugins in Firefox to reassure myself that I'm running the latest Flash plug-in. Naturally there was nothing to see in the purported video. But as I turn round to explain it all to her, I realise that she went to bed hours ago. (ju)
In our "Crime Scene 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. In the next episode, Sergei faces an even more sophisticated Flash exploit.