Introduction
"NeXuS" is a new bot being sold on Hack Forums. The thread originally drew a lot of attention after the seller refused to reveal who coded it or prove that the code was not ripped. He even tried to convince people who had managed to swipe a copy of the executable that they had a fake one and the real one was in fact 4KB (impossible). We still aren't sure who the actual coder is, but what we are sure of is the seller is a complete blithering idiot. Here is a picture of the thread:
The analysis
After extracting the binary from the encrypted package which may or may not be part of the project we are met with this.
The program works through a variety of check to detect antivirus and research environment. The actual checks aren't worth showing as they're your typical checks a non creative coder would find from googling "anti sandbox". What is interesting here is that all the checks are made from the same function and called one after the other, a single JMP instruction is all that is needed to bypass all of them.
Once past the research environment checks the program loads all the required libraries, it does this by a call to LoadLibrary for every library needed. This method is not very optimized and could be easily replaced by a simple loop, of course loops are far too mainstream for this guy. After the libraries are loaded the program then proceeds to the installs phase.
During the install phase a function is called to decrypt most of the strings the program will need. Because loops are too mainstream for this coder, we have about 50 different calls to the same decryption function (one for each string). The above code is only a small snippet of the function which carries on like that for an entire page.
After decryption of strings, the program attempts to open a handle to the mutex "oieg029egkdjgkwdg3oi" via OpenMutexA, if the call fails signifying the mutex already exists the program waits for the mutex to close and then exits. If the mutex does not exist, the program continues installing. If the program has not been run from its install location (appdata) it will copy itself there, and run again. In addition to dropping to appdata it will create 2 keys at SOFTWARE\Microsoft\Windows\CurrentVersion\Run one under HKCU and another under HKLM.
The program then injects itself into explorer using functions like NtAllocateVirtualMemory, NtWriteVirtualMemory and CreateRemoteThread (age old injection method detected by nearly all anti-viruses). After the injection into explorer the current process will create the same thread that was injected into explorer, then the main thread will sleep until the newly created thread terminates.
 |
| How real hackers handle threading |
Rather than creating a new thread and having the old one wait for it to finish, the coder could have just done what he wanted on the current thread, why they didn't is beyond me.
Once inside explorer the program injects into every running process and then creates a few threads in explorer, I'm going to run trough this last bit quickly as I'm short on time.
here is a list of threads created in explorer and what they do:
USB Thread - Listens for USB devices and infects them with an shortcut based spreading mechanism.
Registry Persistence Thread - Creates an event to listen for key changes on the programs start up key.
Inter Process Communication Thread - Allows the program to send messages to instances of itself that are injected into other processes.
IRC Thread - For Command and Control via IRC.
![]()
USB Thread - Listens for USB devices and infects them with an shortcut based spreading mechanism.
Registry Persistence Thread - Creates an event to listen for key changes on the programs start up key.
Inter Process Communication Thread - Allows the program to send messages to instances of itself that are injected into other processes.
IRC Thread - For Command and Control via IRC.
The "Rootkit"
This isn't an actual rootkit but a pseudo one that uses a bunch of documented functions in abusive and sometimes silly ways. The actual file for the program isn't hidden any deeper than calling SetFileAttributes with the hidden flag (Setting windows to show hidden files will evade this). Both the File and the registry key are protected by using documented windows functions as opposed to hooking low level and undocumented ones.
The File protection is done by the injected code inside every process creating a thread that calls LockFile on a 1 second loop (me thinks the coder didn't read the documentation properly).
This code will cause the registry key to be rewritten every time it is changed. It is a very simplistic method but will stop most basic computer users from removing or overwriting the key.
The End
As I am running out of time that will be all for now, I will do an analysis of the bot killer, IRC function and form grabber at a later date. The seller is likely going to try and claim that since I wrote this analysis, the bot has change hugely and gone from being a piece of beginner work to a TDL4 successor, but we all know the truth. I do not usually do much documented reversing and this is my first analysis, that will be all until next time.
