DarkComet Rat's used in Syrian Conflict?
On February 17th the CNN published an interesting article, where some Syrian’s regime opponents claimed that the government was using a Trojan to monitor and disrupt the protestor’s network. Apparently the regime has been using a well-known social engineering technique: impersonate a trusted person then attack from the inside. It is not possible to confirm the story but this is what is being told by the opponents of the regime: apparently one of the protestors was brought to jail and promptly forced to hand over his passwords. Those passwords were used later on to access his Skype account and infiltrate the network of protestors, spreading via chat a program containing some malicious code. In other cases the same file was delivered as a Facebook Chat security update, together with a Facebook icon, while some other people claim that it was also sent by mail. Whatever the means, the common sign among all the stories is that this file, after being opened, did simply nothing and even the antivirus didn’t complain at all.
Preliminary Analysis
We don’t have a lot of elements for the analysis; but we can speculate just a bit: first of all the malware wasn’t delivered through an exploit but as a plain executable file, so apparently we are not dealing with a high-profile attack. Then in one case the malware file wasn’t even embedded with another application, thus reinforcing the hypothesis that the attack, after all, might have been setup in a quick and dirty way. It wouldn’t be too unrealistic to assume that the malware wasn’t even coded by the government but acquired from the “black market”, or even worse on the internet as a commercial or free tool. Fortunately TrendMicro was able to gather two different samples delivered to the opponents of the regime, they found out that both of them were different versions of the popular DarkComet RAT. The first was a DarkComet v5 plain executable, the second one was DarkComet v3.3 embedded into a decoy MAC Changer application. This might also indicate that the government started monitoring the contesters from the very beginning of the uprising; in fact DarkComet v3.3 was released at the end of April 2011, just a month after the demonstrations begun. Did the government really choose DarkComet to fight the opposition? Apparently so, and for us it’s a good opportunity to dissect this program to gain a deeper knowledge, and possibly to be able to detect and remove it.
DarkComet v5
First of all we need to download DarkComet from its website: , it comes as a package, no installation is required, simply unpack it somewhere and run DarkCometRAT.exe. Clearly we’ll have to split the configuration in two parts: the client and the server, optionally we can also configure the downloader module, that’s the main vector used to grab the custom executable from the web, and apparently it’s the same module that’ been used in Syrian attacks, so it may be worth to take a look at it. It might also be a nice idea to run all the components inside a Virtual Machine… You know, just in case…
Configuring the Server Module
After opening the client just click on the main menu and open the Server module section:
This is the place where we’ll setup the backdoor; we are going to use a plausible configuration. So first of all set your password, it will be used to encrypt all the traffic, and this is really important. Generate the names used by the backdoor for the mutex and server id, then, just to make our reverse engineering session more interesting, activate the FWB. Choose the network IP address where you want the data to be sent by the infected target, the port (885 in our case), and then configure the Module Startup parameters:
You’re allowed to choose among several predefined locations: documents directory, favorites folder, desktop, windows directory, cookie path etc… In this case the path and final filename are not important, we’re not doing forensics and we know exactly what to look for, so for your own convenience you can use something easy to remember. Just don’t forget to check the Persistence Installation option. Decide whether or not you want to show a message upon backdoor’s startup (I decided not to) and jump to the Module Shield section:
We want to make the backdoor as widely usable as possible, so we’ll enable just the first three options. In a real configuration I wouldn’t mess up with the firewall, UAC and AV notification, that would probably be too “noisy” and any user with just a little bit of knowledge about what he’s doing will understand that something is wrong. After setting up everything we like, we can just jump to the keylogger configuration:
The ftp server is optional and only required if you want to transfer keylog data via ftp. If you like, setup your FTP (just use FileZilla Server if you don’t have one already running) and fill the credentials, my password is the same used to encrypt the traffic: quepassword. Decide if you want to change the icon or mess up with the victim’s hosts file and go to the Build Module section. We’re not using the file binder because it wasn’t used in the original attack, anyway should you be curious, what you have to know is that it’s a simple packager that starts one file and drop the other in the %tmp% directory, running it at the same time. That’s what you would use if you want to bind the backdoor with another legitimate file.
Choose if you like your final executable packed or not and finally build the server!!
Configuring the Downloader
This is the easy part: simply go back to DarkCometRAT and choose Edit Server Downloader, you’ll have to just setup the web server address where your backdoor is stored:
Configuring the Client
Open the Client Settings option and don’t forget to setup your password if you want your target to connect back to you:
Any other option is up to you and most probably not needed for your analysis. Get back to DarkCometRAT and setup a socket and a port where you want to listen for connections; don’t forget to forward this port to your computer if you’re behind a NAT, or to enable UPnP:
I’ve used port 885, the same used for the attack reported by the Syrian protesters, it really doesn’t matter which one you choose, just be sure to setup the same port both on the server and client part. Finally we are ready to proceed with the fun part.
Detection Rate
These are the detection rates reported by VirusTotal for the download and the backdoor:SHA1: 3ac42898ae92e106b8002929d50eb51b6a3dbec7
File size: 3.0 KB ( 3072 bytes )
File name: downloader.exe
File type: Win32 EXE Detection ratio: 28 / 43
SHA1: 42d85163e18f35fd435b5f96a0bce10b8336b440
File size: 745.0 KB ( 762880 bytes )
File name: server.exe
File type: Win32 EXE Detection ratio: 34 / 43
The downloader is detected mostly as a Generic.Downloader, mainly that’s what it is. The server is detected as Finlosky or W32.SpyBot by most antiviruses, sometimes I really wonder about the names given by the various companies. Surprisingly enough TrendMicro, the first to analyze the malware used in Syria, didn’t detect any of them at the time of writing. Probably even more surprising should also be the fact that a public tool doesn’t get a 43/43 detection rate.
Downloader Analysis
Fire up your preferred disassembler and let it crunch our tiny downloader, as you will see the code is really simple:
It just loads the binary patched url from the resources, downloads the executable file and runs it, simple enough. Just by owning this file we can simply retrieve the original malware, as you can see from this hex dump:
Filename and URL are not scrambled/encrypted in any way.
Server Analysis
Retrieve the malicious file from the url pointed by the downloader and take a clean snapshot of your Virtual Machine, a Windows 7 32-bit in my case.
Before running the file we may want to take a snapshot of the registry and of our documents and tmp directory in order to understand which files and registry entries are created/dropped. For this purpose we can use the handy RegShot application (http://sourceforge.net/projects/regshot/):
Take the first shot before running the file, and the second one after running it, from this comparison we’ll understand that a couple changes have been brought to our system, first new files have been created:
C:\Users\Quequero\Documents\MSDCSC\darkcomet.exe
C:\Users\Quequero\AppData\Local\Temp\dclogs\2012-03-09-6.dc
Then a new registry entry has been added:
The original file hides itself after being ran. This is not a stealth behavior; normally the files you run don’t disappear, so unless your backdoor is started by another file from a temporary directory, auto removal is not the brightest idea. We can also monitor the process using SysAnalyzer in order to find out what are the processes created, from this analysis we see that the backdoor uses several system executable:
The Internet Explorer process is most probably created in order to bypass the firewall. So we can strongly suspect that the backdoor’s code is injected into that process. Let’s now run GMER, a popular rootkit detector, on our system. GMER is pretty advanced and implements a variety of techniques that are able to spot many common rootkits, let’s see what happens:
Indeed nothing is detected by GMER, this either means that DarkComet is not using any rootkit technique or that it’s so advanced to even fool GMER. At least by using GMER’s file manager we see that the original file is still on the desktop but hidden to the view:
C:\Users\Quequero\Desktop>attrib server.exe
A SH I C:\Users\Quequero\Desktop\server.exe
Should you be curious, RootkitUnhooker and even Volatility are not detecting anything suspicious here… DarkComet’s coder wins hands down on this.
So far we have just a few clues that DarkComet is running on our system, let’s perform some checks on our network traffic. For this purpose we run Wireshark:
As you can see DarkComet traffic is pretty noticeable, let’s try to follow the stream:
Apparently it’s just a bunch of data, most probably the traffic is encrypted, so wear your Samurai belt and turn on your preferred Debugger, we have an algorithm and a key to find!
Diving into the Debugger
We need to attach to the backdoor, but you’ll soon find out that the FWB option prevents the backdoor from working correctly if the debugger is active. We are not going to disable the option because we are pretending to be analyzing a real malware, thus we’ll kill the backdoor and run it from the debugger. Just above we have seen that DarkComet probably runs from inside Internet Explorer process, so simply kill it, the backdoor (with my surprise) won’t respawn. Then point your debugger to the installation path and run it. For this task I’ve used OllyDbg v2.0-alpha4 (www.ollydbg.de) and the backdoor file installed in my Documents directory. Start your process and step a few instructions after the entry point, until you get here:
DarkComet loads the password from the binary and uses it for the encryption engine. Trying to find the password in the executable will get you nowhere, for the simple reason that the original password is encrypted. That’s definitely a good idea and we’ll delve into the encryption scheme just in a moment, for now we can step a bit further until we retrieve some more information, like the C&C server address:
In this case it’s 192.168.150.129 on port 885, we can also recover the full installation path:
And in the very same way also the ftp address, port, password, user and everything we’ve setup during the building phase. All of these options are string-encoded into the final binary and encrypted, as an attempt to avoid disclosing “sensitive” data and to protect the user. This is a smart move, of course, and we want to better understand the encryption algorithm and the original key used. In this way we’ll be able to decrypt the network traffic of an infected machine and even to take control of an already infected target, in order to remove the malware from it.
Restart the malware from the debugger and start tracing the first call that loads the “PWD” resource from the file:
Keep following it and you’ll eventually arrive here:
You’ll find two interesting strings, take note of their values and proceed a bit further into the same function until you’ll get here:
This loop is particularly interesting for several reasons: first of all there’s a big buffer that is continuously rearranged and then a xor that uses the values extracted from the buffer. We are definitely dealing with some kind of encryption algorithm, but which one? I had to go back to pen&paper&IDA to find it out, and even though I’m pretty quick to recognize an encryption algorithm from the disassembly, this one took me some minutes. So, what is it? The good old RC4! Only with a few optimizations introduced by the compiler that add entropy to the pool, making it just a bit harder to recognize on first sight. To avoid any doubt just reconstruct it from the Disassembler (IDA in this case):
There you go, it’s RC4 for sure and this is the first step of the permutation initialization. Then we have the algorithm:
RC4 is an algorithm loved almost by everyone. It’s a stream cipher, so you won’t have to deal with padding, easy to understand, short and fast. The downside is that it’s tremendously easy to use in the wrong way, but this is another story. Apparently the algorithm is initialized with a fixed key “#KCMDDC5#-890″ and this key is used to decrypt a string: “2955B175B3D8DFAFF28DFF”. To check if I was right, I wrote a helper application that implements RC4, this was the result:
./rc4 –k “#KCMDDC5#-890″ –d 2955B175B3D8DFAFF28DFF
output: quepassword
oh look! This is the password we’ve setup during the configuration step! So to avoid storing the password in clear-text it’s been encrypted with a default password hardcoded into the binary. The same key is also used to decrypt all the other settings, later on you’ll find other strings:
./rc4 –k “#KCMDDC5#-890″ –d 1C638B4887FFE980B0AEEE23
output: DC_MUTEX-Que
But if you try to use the same password to decrypt the network traffic, you’ll just end up with a bunch of garbage. To understand why you’ll have to hook into one of the threads that are used to communicate with the C&C server:
Trying to follow the function that encrypts the traffic, you’ll find out that the algorithm used is the same (once again: RC4) but the key used is created by concatenating the hardcoded password with the one we chose at the moment of setup, in our case:
#KCMDDC5#-890quepassword
If you try not to use a password, the traffic will still be encrypted:
This time with the hardcoded: “#KCMDDC5#-890″. Trying to decrypt part of the above dump with the right key, will lead you to the clear-text commands:
SERVER
GetSIN192.168.150.137|243968
Keylogger
An interesting function is the keylogger of course, as we have seen above a file is created into the user’s temporary directory:
C:\Users\Quequero\AppData\Local\Temp\dclogs\2012-03-09-6.dc
Opening it will reveal keylogger’s data:
It’s not clear why this file has been left visible and in clear text, anyway the data will be appended here and sent via ftp, if enabled, when the logfile reaches a given size in kilobytes (FTP_SIZE variable into the executable):
EDX points to the size, shown in the above picture, with the ASCII value of 0×31 that means “1″ Kb. But how’s keylogging performed? Since no driver has been loaded by the backdoor we have to assume that it does something in userspace, and indeed this is the case, in fact the keylogging thread will simply call SetWindowsHook to receive the keyboard notifications:
What I marked as hookProc takes care of keyboard data processing, there’s a big switch that identifies every single keystroke, including special keys:
Every keystroke is processed consequently and then logged into the directory shown above:
Injection
To bypass a firewall that might be in use into the victim’s system, DarkComet uses a simple but effective trick: it simply injects the communication code into a process that’s allowed to pass through the firewall, in this case it’s Internet Explorer, thus confirming our suspects. The injection takes place in this way: first of all Internet Explorer is identified, opened in background, suspended, then some “extra” memory is allocated into the process and DarkComet’s code copied inside this new buffer, following that the process is resumed. The routine that takes care of the injection is, in part, the following:
A confirmation that Internet Explorer is used to send the traffic can be obtained simply by inspecting the “hidden” process with ProcessExplorer:
Also in the same way we can identify the backdoor’s mutex:
During the analysis through the disassembler you won’t be able to find references to the entire API used by the binary, this is because a lot of them are resolved directly using GetProcAddress and then stored into pointers available to the backdoor:
To find where they are resolved, simply look all the X-refs to GetProcAddress and follow them one by one, to give you an idea that’s what you’re going to find:
It won’t take long to give a name to every pointer and it will be of great help, should you decide to proceed by yourself with the analysis of the binary.
Detection & Clean up
Detecting DarkComet, in some situation, can be non-trivial. We have examined just one possible case, the backdoor can be stored anywhere, with any name, packed with any packer. The best solution would be to use DarkComet Removal Tool from the home page of the RAT, anyway if you don’t totally trust the author on that there are still come clues you can catch:- Monitor the traffic, KEEPALIVE messages are always sent in clear and the traffic patterns are pretty constant in time
- Check for FTP data, keylogger can be configured to deliver keystrokes this way, in clear
- Check for hidden instances of iexplore.exe, use ProcessExplorer to see if it’s making traffic
- Check for unknown values in HKCU/Software/Microsoft/Windows/CurrentVersion/Run/
- Check for unknown values in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\ into the “Userinit” key, this is another path used by the backdoor to run at startup
- Check for an empty link into the programs\startup section in the start menu
- Check for the existence of %tmp%/dclogs/ directory, that’s where you’ll find keylogger’s data
Detecting the keylogger might not be that easy, you’ll have to walk down the hook chain to find it. This is fun but out of the scope of this article, maybe we’ll analyze some keylogging detection techniques in a future article.
Once you have identified the threat remove the registry entries, kill the hidden iexplore.exe, remove the logs directory, remove the executable (you can retrieve the installation path directly from the registry) and reboot. Don’t foget that with the knowledge acquired so far you’ll also be able to extract the password from any DarkComet sample. This way you’ll be able to dump the configuration and understand exactly what the Trojan is doing on a given system and where it is sending the data.
Click:Download
Click:Download
0 comments:
Post a Comment