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.
Typical memory packed exe colluding with a CreateProcess() call right after unpacking itself.
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.
Seems pretty cut and dry now. The malware is launching an alternative version of windows update.
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.
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’).