In the Aurora 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 MalwareInt 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 and can be downloaded here
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). (*on another note, if you have the ad_1_.jpg file, please send it to me, I'm really looking for this file and can't really find anyone who has it*).
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).
Cheers.
Itzhak Avraham
Posts
4 comments:
Obviously something went wrong during the file transfer and nulls were replaced by these 0x20s (maybe some douche-bag copy-paste it or something). Try replacing 0x20 with 0x00.
The intention of this post wasn't fixing the file for the attacker. This file was found, as-is, at the compromised computer of Google.
Replacing the 0x20 with 0x00 would still wouldn't work as header would be corrupted and still the file doesn't look like a driver (like mentioned in the post above) - Which was the whole point of analyzing it (that's what made me interested in the file at the first place). Those 0x20 weren't there un-intentionally, you can see the CERT advisory and see another file, not in his role (jpg which is a PE) which was XOR'd in 0x95, well, significant part of it, but not all of it, which makes sense here as-well.
Thanks for your insights, although those methods had been tried as one of the first approaches to file.
Try to get new copy of that file from Windows CD, (installed copy of windows). And then compare it with this one or replace 0x20 with 0x00 since the headers of new file are not courrpted.
Dear Ali,
Which file you want me to get from a fresh copy?
Please be more specific since I do like new ideas? :)
Post a Comment