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:
Check the registry window:
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 
2:49 PM
Unknown
![[Image: BCXFD.gif]](http://i.imgur.com/BCXFD.gif)
![[Image: ywccU.gif]](http://i.imgur.com/ywccU.gif)
![[Image: dhn43.gif]](http://i.imgur.com/dhn43.gif)
![[Image: yJxc2.gif]](http://i.imgur.com/yJxc2.gif)
![[Image: untitled24.JPG]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh0W8WPILV_uQjLQN3FdIzKVgpeE-yhqOzA_x7E3gKcOiz3X0_1VS-fkTrPxEiLLx_Pyc44GdD3-EywPxxSd-XFZWeMGe5PzNMwNYDSvSIB-bmw4v5RbhZwXuLzM3By3BbZ61HIi2ruMSMf/s400/untitled24.JPG)
![[Image: untitled22.JPG]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiP2n35rCDXofJGh-nNU8_gk4w8AGlNLOGGoZaZ0O1QYODer_2D2bq6Ton841PsWZZYTeLRtBmtmc2p5FXvmP7RyBT4CBAA-M3cO37LB0DObc5C749P1QFze-K33cGc74Jra5ZyqhXnacqW/s400/untitled22.JPG)
![[Image: untitled23.JPG]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjJDLZxQOHR6fToeDTsFhULwmQuWLIuaGAKX3PGC-omMy-GRHCyLqiKP-IsaCCjPWT24lBeyl9nciHPVFe2tDqVjx_LfG_klNY0nT-rcbesplZCW6P6zhK-dzoEOlvvjsOyJFoX_mcnSZBl/s400/untitled23.JPG)
![[Image: untitled26.JPG]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgaWStxBMKdwouxHrtD8h7C8-4DtzTQjn-WyLnPbz7sx6kNTEWjPhK8fQWhoxRaINuD0yzk899VtW4ZgUp8KnnbouMD4Af1fVp_K4xk20dCfj19k2_mEYggxBQOWpvP5w7xcnfKDyWv4OPL/s400/untitled26.JPG)
.jpg)
BSQL
Hacker aims for experienced users as well as beginners who want to
automate SQL Injections (especially Blind SQL Injections).
One common method for performing a Denial of Service attack is called
flooding. By rounding up a large number of computers, and telling them
all to send or request a large amount of data from a server
simultaneously. The purpose of these requests are not to gather large
amounts of information; rather, the intent is merely to overwhelm the
capabilities of the server. In a situation like this, a server could
fail because of the bandwidth restrictions of the internet service
provider, the memory limitations of the server, the lack of hard drive
space to store the data being sent, or the inability of the CPU to
process the data fast enough. The common thread between these four
issues is that these are finite resources that have been given to the
server. PyLoris is different from this form of attack because it does
not prey of any physical resource; instead, it overwhelms an artificial
resource--connections.
![[Image: shelasd.jpg]](http://img706.imageshack.us/img706/5315/shelasd.jpg)
![[Image: md5pw.jpg]](http://img15.imageshack.us/img15/2383/md5pw.jpg)
![[Image: neasd.jpg]](http://img707.imageshack.us/img707/9820/neasd.jpg)
![[Image: 124124g.jpg]](http://img267.imageshack.us/img267/3403/124124g.jpg)
![[Image: 12412412414.png]](http://img834.imageshack.us/img834/244/12412412414.png)
![[Image: unlednzl.jpg]](http://img20.imageshack.us/img20/8752/unlednzl.jpg)
