I detected this piece a while ago, but didn't have time to get deeper into it. The detections of the malware sample are quite generic, so for the purpose of this post I'll name it "n3nmtx", based on the mutex it creates at the beginning of the execution. More details on the name at the end of the post.
This sample caught my attention because of the huge number of anti-analysis tricks it deploys. Actually, some of them are stolen from pafish, which makes me feel really bad and forces me to do the proper analysis.
Basically we will need to comply with some conditions to make the malware run. At the beginning of the execution, it will sleep for 0x2710 (10000), then it will do a call to 0x400, which is the function that contains all anti-analysis tricks. If that procedure doesn't complain, it will check for internet connection. If it can't connect, the execution will come back to the beginning of the loop procedure.
So, instead of patching the whole system to run it, we will patch the malware itself (:D), and radare2 will help us!
To patch the sleep time, the best we can do is going to the value and change it for something smaller, let's say 0x05. So we copy the binary and open it with r2 in write mode:
$ r2 -w original_patch.exe
Let's seek the address of the sleep value:
[0x0040a3fa]> s 0x00004f32
And in visual mode (V), using the cursor, we can +/- the push value.
We do the same with the other sleep, and we're done.
radiff2 is quite handy to confirm the changes:
$ radiff2 original.exe original_patch.exe
0x00004f32 1027 => 0500 0x00004f32
0x00004fb7 1027 => 0500 0x00004fb7
Great, no more sleeps.
The anti-analysis procedure is just a call, and it doesn't check any return value. If it would, we could patch the conditional jmp, but as it doesn't, we will just put some NOPs there.
Open the file in write mode again, knowing where to put the NOPs and how many of them ...
[0x0040a3fa]> wx 9090909090 @0x00004f0d
And in visual mode we can confirm that the procedure will never be executed, and also that we didn't mess up the opcodes.
At this moment, the malware will run instantly in any system, including sandboxes!
To stay alive after reboots, it creates some entries in the registry, common stuff.
Communication with CnC
The communication with the CnC is done via HTTP requests. It will basically send pings and ask for tasks to do.
The task delivery is interesting because the server will answer with a 404 response, but at the end of the content we can find the command sent to the bot in base64.
The commands accepted by the bot are:
Most of them are self-explanatory.
I want to keep this short because while I was redacting the post, I found some public information about the piece.
You can check this McAfee post for more detail on the anti-analysis techniques.
This bot seems to be part of a Neutrino botnet, Kafeine also wrote about it, but hashes and CnC are different.
My hashes are:
8130f713b2464c77c6500d5d8d37a4b3e3c0e98f2607ca4262a87ee6ae0e88c3 <- the sample used for the post
You can find them in VT or in our beloved Zoo :)