\nIn case you don’t know, here is what a typical piece of obfuscated \/ reflection based java code looks like:
\n
![\"typical_jar_sploit\"](\"http:\/\/www.gironsec.com\/blog\/wp-content\/uploads\/2013\/11\/typical_jar_sploit.png\")
<\/a><\/p>\nAs 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:<\/p>\n
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). So let’s take a look at the file: Typical memory packed exe colluding with a CreateProcess()<\/a> call right after unpacking itself.<\/p>\n 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: Running the app to this breakpoint, we make a revelation: Let’s run the app some more and see what happens.<\/p>\n By the looks of it, its referencing that wuauclt utility, but its in the wrong place. Its supposed<\/i> 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. <\/p>\n 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. <\/p>\n Peeking inside the DLL file we see calls known for VirtualAlloc, VirtualProtect, and Sleep().<\/p>\n Sleep for 1000 hours? Weird. <\/p>\n 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: Now we merely replace the dll file, launch the program, and start listening for that C&C traffic. That was fun!<\/p>\n Now for crazy speculation and theories: Just an idea. Just a typical day. <\/p>\n With these details alone, I was able to determine the good guys at sophos had already done the same work<\/a> for me. Thanks guys.<\/p>\n If you want to play around with the files, I’ve included the IDB files, patched and unpatched binaries here<\/a> for study (pass is ‘infected’).<\/p>\n<\/a>
\nIn this case, the item being exploited is apparent. The SecurityManager<\/a> vulnerability.<\/p>\n
\n<\/a><\/p>\n
\n<\/a>
\nThe program downloads the file into the machine’s temp folder and executes it.<\/p>\n
\n<\/a><\/p>\n
\n<\/a><\/p>\n
\n<\/a><\/p>\n
\n<\/a>
\n<\/a>
\nThis skips the BS of having to step through MFC classes and other non sense. <\/p>\n
\n<\/a>
\nWhat the hell is ‘wuauclt’ ? Windows updates!<\/a><\/p>\n<\/a><\/p>\n
\n<\/a><\/p>\n
\n<\/a><\/p>\n
\n<\/a><\/p>\n<\/a><\/p>\n
\n<\/a><\/p>\n
\n<\/a><\/p>\n
\n<\/a>
\nSyncing 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.
\n<\/a><\/p>\n
\nI think the windows update manager stored within the pulled down malware isn’t actually malware, instead it contains a broken call to LoadLibrary<\/a> 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:
\n<\/a>
\nThe 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<\/a> for ‘wuauclt.exe’. Maybe this switch holds some significance with the rogue dll? <\/p>\n