Remote Backdoor Malware Writeup

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?

Now let’s inspect the meta data:
KSP Exception External Diagnostics Utility? It’s like they just jumbled a bunch of tech jargon together. Clever girl.

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. p4
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 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:
process checking maybe

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.

Continuing my single stepping, I get to this:
user profile svchost
It appears as though the malware copies itself into the all-user’s folder under the name ‘svchost.exe’.

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:
p9 - extra thread not visible
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.

Restarting and going back to the same place, I see a phantom thread:
p10 - phantom thread
Weird stuff.

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.

p12 - break point on createthread

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.
kernel32 code again

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.

Allowing the code to run again, we see a new loaded module – ws2_32.dll (winsock). Now what could that be for?

Continuing to run the program, I noticed something odd. The firewall alert went off on my xp vm. Clicking allow and checking process explorer, we see a newly opened port:
port 8000

I restarted the program and placed a break point on one of the winsock function – wsaaccept: wsa_accept

I then telnet to localhost on port 8000 and wait to see what happens:
telnet 8000

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.

How does it spawn the shell? I observed a CreateProcess() call shortly after connecting to the port.
createprocess call

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:
p11 - notes

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.

Stay safe!
Edited due to censorship

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.