Hello again fellow readers and security enthusiasts.

The last post was filler and I’m sorry for that. Today we’re going to go over some typical malware, start to finish. Exploit to C&C communication.

We start with our exploit file. Java of course. Most of the time when I encounter a java file, it’s heavily obfuscated and uses reflection to bypass Anti-Virus & IDS systems. This is a rare exception – no reflection or obfuscation. Maybe the guy delivering it didn’t know?
In case you don’t know, here is what a typical piece of obfuscated / reflection based java code looks like:

As you can see, I usually have to fart around with a eclipse to get an idea of what’s going on, but not this time:

In this case, the item being exploited is apparent. The SecurityManager vulnerability.

The other class is of more interest:

How nice of them to leave the link to the binary in the open as well as the means to reach it (user agent strings).

The program downloads the file into the machine’s temp folder and executes it.

So let’s take a look at the file:

Typical memory packed exe colluding with a CreateProcess() call right after unpacking itself.

By the looks of the thing, its an MFC app.

Since its MFC, that means when we debug the thing, we have to step into the higher addresses to progress through the app and find the entry point:

If you’re lazy / smart, you’ll set break points on the interesting functions we saw in IDA:


This skips the BS of having to step through MFC classes and other non sense.

Running the app to this breakpoint, we make a revelation:

What the hell is ‘wuauclt’ ? Windows updates!

Let’s run the app some more and see what happens.

By the looks of it, its referencing that wuauclt utility, but its in the wrong place. Its supposed to be in the system32 folder. But instead its in another folder in %appdata%.

Stepping through a few more procedures we see the following:

Seems pretty cut and dry now. The malware is launching an alternative version of windows update.

Comparing the malware’s version of ‘wuauclt’ with the unchanged version we see they are very different both in size and contents:

The MD5’s check out as being non malicious on VirusTotal. I think the spawned / dropped version of Windows Update is fine. Here’s where shit gets weird. There were 2 other files in the wuauclt directory in the user appdata folder. ‘wuauclt.dat’ and ‘clbcatq.dll’. The dat file doesn’t contain anything recognizable as it may just be encoded / encrypted, but the ‘clbcatq.dll’ file is what’s interesting. This file contains the goodies.

Peeking inside the DLL file we see calls known for VirtualAlloc, VirtualProtect, and Sleep().

Sleep for 1000 hours? Weird.

There’s another sleep call more in context with the appdata folder. A shorter sleep – only 5.5 hours.

Assuming we wait the 5.5 hours for the dll code to do its thang, we are then taken to the following code, our all too familiar VirtualProtect / VirtualQuery calls responsible usually for unpacking of memory packed data by setting sections of memory as readable / writable / executable:

How can I prove this? I’ll have to edit the dll binary’s exe code so that I don’t have to wait 5.5 hours. A hex editor can be used for this, but I prefer to use Immunity for this:

Syncing up data structures in hex editors, alignment, and all that BS sucks. When I patch ELF binaries, I have to use a hex editor. On Windows, life is slightly easier.

Now we merely replace the dll file, launch the program, and start listening for that C&C traffic. That was fun!

Now for crazy speculation and theories:
I think the windows update manager stored within the pulled down malware isn’t actually malware, instead it contains a broken call to LoadLibrary which allows a program to invoke a dll of their choosing to be run in the context of the new windows update exe program. Sound far fetched? Check this:

The wuauclt.exe file has a special loadlibrary function. Then one of the strings in the binary pulled down from the malware site was ‘/ShowWU’, one of the command line argument switches for ‘wuauclt.exe’. Maybe this switch holds some significance with the rogue dll?

Just an idea. Just a typical day.

With these details alone, I was able to determine the good guys at sophos had already done the same work for me. Thanks guys.

If you want to play around with the files, I’ve included the IDB files, patched and unpatched binaries here for study (pass is ‘infected’).