Seasons greetings from your fellow hacker cracker, AverageJoe.
Tonight I’d like to go over some malware I spent the better part of November going through off and on. Its a part of the payload delivered by an exploit kit called Neutrino. Perhaps you’ve heard of it?
Anywho, let’s get down to business.
First things first, when I plucked the file from the infected asset, one thing stood out – the date time stamp.
What the hell? This is a primitive form of hiding files – pc techs are taught to look for files recently created / modified, so by adjusting the date time stamp, it looks inconspicuous. I’ve already gone over this before, it’s just odd to see malware doing it. Maybe they read my blog?
Let’s dive right in with IDA. Here we show ‘WinMain’. It’s not what IDA identified as the entry point, but it does get here eventually and judging by the graph contains the meat and potatoes of the app.
Initial introspection – Anti debugging code right at the beginning of the main function with calls to GetTickCount(), a comparison, and a long jump to exit the program. Crude, but effective against noobs. In fact, this malware makes use of this API in spades.
Luckily however, the ‘hidedebug’ python script that comes with immunity debugger supports patching of this API.
After some fucking around, I found the right entry function responsible for decoding the exe, unpacking, etc. The malware placed its code in the ‘atexit’ function. FYI, the ‘atexit’ function is a C++ specific call back function executed when a program exits. See http://www.cplusplus.com/reference/cstdlib/atexit/ for more info. So ‘atexit’ calls a function ‘onexit’ which then calls another function ‘__onexit_nolock’ which when disassembled by IDA looks a little something like this:
See the calls to Encode/DecodePointer()? MSDN says “Encoding globally available pointers helps protect them from being exploited. The EncodePointer function obfuscates the pointer value with a secret so that it cannot be predicted by an external agent. The secret used by EncodePointer is different for each process.” I guess this is a more advanced form of anti-debugging, but not a very good one since the code WILL look different when run as opposed to being static:
In this case, the actual code is a process checking loop that checks to see which processes are running, likely more anti-debugging counter measures. Suddenly this malware got 10 times more interesting.
Single stepping takes for fucking EVER, so I decide to let it run and wait for something interesting to happen:
I noticed the CPU usage spiking so I paused execution. The IP was set to code outside of the normal section:
Stepping through the code, I encountered a CreateThread() call that didn’t make any sense:
This actually threw me off for a little while as the newly created thread had no handle associated with it, and immediately after the malware called ExitThread(), the malware would run inside another thread and leave my debugger useless.
Eventually I decided to use the ‘EBFE’ method to get around this. I set a break point on the CreateThread call and replaced the entry point pointed to by CreateThread() with the bytes x\EB\xFE (jump to self), then re-attach my debugger.
Once I had control of the app again in the debugger, I continued execution. The malware copied itself to the appdata directory and attempted to call itself. Typical malware behavior. This was followed by a call to cmd.exe presumably to a batch file to delete itself.
Just by looking at the strings, we see references to the start-up registry entries along side our ‘svchost.exe’ entry in the all users folder.
After connecting, I hit the wsaaccept break point. Remember that the WSAAccept function conditionally accepts a connection based on the return value of a condition function. Inspecting the call stack I come across the following:
Referring back to my telnet window, I see a remote shell. The malware opens port 8000 on my box, waits for something / someone to connect and opens a cmd shell. I ran tasklist and it was fairly receptive.
This malware employed various techniques I hadn’t seen before and coupled them with other things I had seen, some common, some not. Changing of the date time stamp, using a common process name, deceptive meta data, encoding pointers, etc. All good stuff. I learned a lot and you can too, download the backdoor here. The password is infected. I left my original jumbled notes that make sense to me and probably a handful of other people as well:
I apologize for taking so long to release this, but I’ve been busy. I still have tools to finish and figure out what i want to talk about this year for the cons.
Edited due to censorship