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

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

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

hooking for fun and profit 2 - logging function calls

Well... I've hooked the function calls to log my calls to system()... but wait... what does system() do?

Let's create a simple program that runs argv[1] as system(%s) and run strace on it :

 We can see that we don't see a real call to any *exec* functions. But that's not true isn't it? We're missing something.... Clone() is like a fork, let's see what it does by following it with "-f"

Looks much better... now let's look at the bottom of it:

YES! finally! An execve function had been called! We wanted to see how it was called!
But that's a bit boring, isn't it? Let's create a function that hooks the execve function, as-well as system function, and start a new shell and we'll trace what happens from the time you click on bash (with all the init scripts..), till the end of its execution...

Hooking the function of execve and system :

Let's create that file using echo "" > /tmp/system_calls.log and let's compile it using
gcc -shared -fPIC -o libexechook.so sys_exec.c -ldl

Now! It's the fun part! Let's do the following command to start the hook :
export LD_PRELOAD="./libexechook.so"; bash



Let's run what happens at the start of the bash :

(all except the last command...)

I hope that now you're less afraid of hooking functions. It's very profitable for some purposes.
The reason I've decided to post this, is because I haven't seen much of hooking examples which are not using parameters / or only one. Might be useful to someone, one day.
Enjoy.

Linux functions hooking using LD_PRELOAD - for fun and profit

 Well... I had to log some calls for a specific function which calls some binary.
So, instead of doing it in the proper way, I've replaced the binary to call another binary and then to switch between them. It did work, 90% of the time, but some race conditions sometimes made it not effective.
That's when I've decided to use LD_PRELOAD and do a proper hook instead of binary replacing with shell script, which caused race conditions in about 10% of calls to that binary.

Well? It's sort of the same for any function. Take the function and its variables from the declaration do whatever you want and call the original function (if you want to have the original functionality).

Easy to write, and much better solution

Here's a piece of example

taken from : http://www.technovelty.org/code/c/override.html. Life saver!


Lesson learned, don't be lazy, do a proper hooks to avoid race conditions :)