Aurora .sys file used in the attack - External file analysis

First of all, I'd like to thank MalwareIntelligence where I write as a researcher for getting me this precious file.

In the Aurura attack, 1 .sys file had been used, called : msconfig32.sys.

I was pretty curious about what does this driver do, and why no one else in the world had analyzed it.

It had been a terrible journey to get the file. No one had it. No one wanted to share it. I was pretty lucky to group up with MalwareIntelligence and they had the right connections to get this file.

Like I've told to large number of people, there are lots of reasons to use drivers in this kind of attack, but it's pretty clear the attackers weren't about to hide itself or its connections. The only thing I could have think of is writing a driver to get information about the physical status of the screen (Because the attackers used patched version of VNC, a driver could query the status of the screen, and if it's shut/stand by it's safe to work, also, this kind of driver could have saved restore points of the computer before the attacker started to look for files inside of the computer and once the screen is up, restore everything to its original state - more of this idea is on my presentation on ihackbanme.com.

But it appears that this is not the case. That's what I was looking for. That what I've been trying to search for, but it had been there the whole time. The .sys file, wasn't a driver.

Let's first take a quick look at the file (.sys file is a PE):

Well? what's that? why are there 0x20 all over the file? it's supposed to be 0x00 in those areas.. It's obviously a XOR. It does have a base like a PE, but it sure does look different, XORed or some kind of anti-reverse engineering on it. That's the first look.

Let's take a look at +- same size of other, valid, Microsoft driver :

Can you notice the difference? Where's it's usually 0x00 there are 0x20. Weird. Let's look further in the msconfig32.sys file :

Wait?!@@#$ Why are there .dll files mentioned after the Resource mark? Havn't seen that in a driver before... Let's again take a look at a valid driver again :

We don't see that kind of stuff, yet we continue to see 0x20 instead of parts where there should be 0x00...

Weird. Maybe it's an exe instead? Let's not give up! Let's try to load it and see if the driver can be loaded as-is. I've chosen to use SCM (Service Control Manager) built in mechanism to load drivers, instead of writing a loader myself. Driver can be loaded in lots of ways, including replacing other sys file, quick registration in windows registry or other ways (You can find some more information in the Rootkit - Subverting The Windows Kernel book - page 40 : The quick and dirty way to load a driver, or pages 46,47. Enjoy).

I've decided to use SCM, and load the driver using SC. So let's do it :

First I've done a re-check, to see that I havn't changed the file, The file I needed was msconfig32.sys from Aurura attack with the following md5 : 7a62295f70642fedf0d5a5637feb7986), After I've done that, I've written a sc command to load the driver from : c:\msconfig32.sys.

The command and the checks are attached in the following picture :

The specified driver is invalid?! How about that? The file is certainly not a valid sys driver (as is, it might be changed a bit to be fit as a .sys file). So what is it?

Trying the regular approach of opening the file in PEExplorer/IDA/Olly/PE Parsers/... wouldn't work, as the file is quite damaged in a way the headers are totally corrupted and the way the file behave something is under there, but it's not a regular .sys file.

So... Let's try to mess with it a bit, maybe XORing again with 0x20, gave nothing. Other ideas I've tried (tried so many I can't even write them all), didn't go well. The file appeared to be curroupted.

Trying to load it as a dll, or opening it under .exe failed as-well.

I did try to play with it a bit more, and found that CERT had issued an advisory in which they have written the following stuff :

ad_1_.jpg

MD5: CD36A3071A315C3BE6AC3366D80BB59C Byte Size: 34816

Appears to be packed executable. Significant portion of file is XOR'd 0x95

There's another file, with .jpg, and he's not a jpg. The file is XOR'd with 0x95. Does it ring a bell? Yes it does. I think it's the same kind of method used, but this time, they have called their file .sys instead.

Or, The file was being downloaded, step after step, and till they finish the download they first create a file, filled with 0x20s and they overwrite it with the real file. That could have explained the size of it (4kb).

So I've checked, is the file compressed? How can I check without knowing what kind of compression is used? The easiest thing is to take the payload of the PE file, and write it to another file. After I've done that, I tried to compress it again, and guess what? The file, after compression, was bigger then the original. Meaning the payload-part was compressed.

Still couldn't figure out what it contained. I will continue to research it and hopefully soon I will find something :). Too bad it wasn't a real driver though...

I hope you liked my external analysis, because I couldn't examine the file (as it was "corrupted" or at-least not in a valid format). sometimes it's all that can be done. Although, now we know that this file wasn't a real driver (but still, might have contained one within - compressed).

Itzhak Avraham
Malware Researcher in MalwareIntelligence