Darkcomet Hacking the hacker

Before I begin this post let me get the following statements out of the way.

I Am NOT A Lawyer. The use of the Tools and Techniques discussed in this post may not be legal in your country.
The original credit for the discovery belongs to Shawn Denbow and Jesse Hertz. All I did was expand on their POC.

Back in July 2015 I presented a talk at Security Bsides London titled “DarkComet from defence to offence. Identify your attacker.” You can view the slide deck here or watch the video below.

This post is simply to cover a few of the points I made in the presentation. The main focus is to gather intelligence that can be used to either remediate your environment or to identify the attacker, either for intelligence or to aid a lawful investigation.

From the Binary

The binary file contains a lot of information that can be used to identify the campaign, this can then be tied back to the attacker:

  • Domain Name / IP
  • Port Number
  • Traffic Encryption Password
  • FTP UserName
  • FTP Password

There are also several other sections such as campaign ID that can be used to correlate groups and campaigns but they don't have any real impact on what we are doing here.

There are plenty of writeups on extracting this information from a sample, there are also a series of tools I have released in order to extract this information from a binary sample. https://kevthehermit.github.io/RATDecoders/ has a standalone decoder you can use against samples to extract information.

Many of these decoders have also been integrated with Viper Malware Analysis Platform and the same information can also be collected using my online service https://malwareconfig.com which will also extract this for you.

With the Domain / IP we can start to find some information.

The first example, a2cb205be5800aa6ada65d2a37f4550a, shows a domain name. ‘jakeztrainer.no-ip.biz’. no-ip is a well-known Dynamic DNS provider that made the news in July 2014 when Microsoft Seized control of the domain names for hosting malware.

More interestingly In the first example we also have FTP Credentials for ‘terrorb @ ftp.drivehq.com’ which is a free FTP host i have seen used a lot in RATS. The FTP function is designed to upload KeyLogs that have been captured from the victim, but you can imagine what other files or data could be stored in the FTP.

To see what kind of information was exposed I created myself a free account and infected a VM with my own darkcomet server. As expected all the Keylogs are visible. The FTP logs will show you all keystrokes logged on victim machines.

Under the DriveHQData folder is an EventLog Directory. This contains a series of CSV files that list access to the FTP. From this information we can make a reasonable assumption that FTP entries are victims, and the Web Entry is our bad guy as DarkComet is not likely to be accessing the Web panel.

All this information was retrieved by simply possessing the Binary that the attacker sent to his victim. But what if we are not in possession of the binary?

From The Web

Due to the way DarkComet identifies itself it is a trivial matter to scan the internet for active DarkComet Clients. (The Client is the attackers controlling interface).

If you attempt to connect to a DarkComet client on a port DarkComet will identify itself by sending an encrypted banner. Since we know the ID type, the encryption method and more importantly the default encryption keys we can successfully identify default installations using the following banners:

  • DC_2 - 8EA4AB05FA7E
  • DC_2_PASS - C4A6EB42FC74
  • DC_4 - B47CB892B702
  • DC_4_PASS - 00798B4A0595
  • DC_42 - C7CF9C7CD932
  • DC_42_PASS - 61A49CF4910B
  • DC_42F - 155CAD31A61F
  • DC_42F_PASS - 82695EF04B68
  • DC_5 - 1164805C82EE
  • DC_5_PASS -; 2ECB29F71503
  • DC_51 - BF7CAB464EFB
  • DC_51_PASS - DACA20185D99

Attackers that change the default password can not be detected using these banners, But if you know the password or extracted the password from a binary as shown in the prior section you can generate your own banners to scan for.

With this information we can head over to Shodan Searching just for the Latest version with no password set - BF7CAB464EFB shodan revelas 212 Active DarkComet Clients. That is 212 Attackers who are actively running a known bit of malware.

Searching for all the banner combinations reveals an additional 72 Clients using other versions or password combinations.

Going Offensive

What follows is the section that if used could land you on the wrong side if the law. I am not a lawyer and don’t wish to be dragged in to a legal / moral debate. So I will simply say that if you’re not a law enforcement agency of some description I advise against using these tools and techniques outside of a lab environment.

Ok so what exactly can we do with the information we have gathered so far? Whether it’s from the binary or from a Shodan search we have the 3 key pieces of information we require.

  • Domain Name / IP
  • Port
  • Password

Traffic Load Testing - AKA DOS

With this information and an understanding of the DarkComet network protocol we can create a series of packets that mimic an initial connection string. DarkComet uses UUIDs to track unique connections instead of IP’s so one IP can generate enough traffic to render the attackers GUI useless by filling it with fake connections. (Around 16:20 in the Video)

This may cause the bad guy to lose his ability to interact with the victims, and if sustained could force him to switch Domains / IP’s which would also mean he looses all his infected hosts as they will no longer be able to update to the new C2 information. But it doesn’t really give us any information on the attacker himself.

Remote File Read

Full credit for this vulnerability and exploit goes to Shawn Denbow @sdenbow_ and Jesse Hertz @hectohertz who discovered and published their findings in 2012 here.
So what did they find? You can request any file from the DC Client machine with two restrictions:

  • You can only read / access files in the context of the user running the client.
  • You need a full path or a path relative to the main DC executable that’s running.

I’m not going to look at the technical details the report covers that aspect, I’m going to look at the kind of information that can be extracted.

comet.db
The comet.db SQlite file is where dark comet stores all the connection information it gets from connecting servers. Including all the keystrokes in intercepts. This is stored in the same folder as the DC main executable so is trivial to retrieve using the exploit.

I wanted to show you some real data without doing a live engagement. Turns out Script Kiddies don’t know much about opsec and since DarkComet is no longer available they share their own versions, in hack packs, which include their comet.db files. These often end up on VirusTotal where researchers can get copies of them as well.

For a more detailed look at the data contained in these comet.db files read my post A Look Inside A Dark Comet Campaign

I have created a python script that will parse a comet.db file and extract the information including decoded keylogs. You can find the link at the end of the post.

Other Files

From here it is kind of use your imagination but some interesting files that can produce some valuable intelligence include:

Linux passwd / shadow files have the usernames and passwords for accounts, Coupled with an IP you can now potentially SSH / SCP on to the attackers box and browse files at will.
Command history files
Browser History files show a scary amount of information. Browser password stores may protect the passwords but the usernames / email accounts / urls are all in the clear.
Log files for VNC / FileZilla etc can identify other infrastructure
You can see some examples of this in the demos on the video.

Linux / Kali

If you’re a bad guy and your running your DarkComet Client on a linux distribution like Kali then you have just turned your malware platform in to a Remote Forensics platform. Assuming your running with the right account, which in the case of Kali is root anyway. I can access:

  • /dev/sdx - This is your Drive
  • /dev/mem - Memory
  • /dev/kmem - Kernel Memory

This is everything! Every file included deleted files, Usernames / Credentials / SSH keys this is everything a forensic examiner needs to identify everything the attacked did and is doing. (Around 37:00 in the Video)

DC Toolkit

All the scripts I demo are available on my GitHub https://github.com/kevthehermit/dc-toolkit There are some basic instructions showing how to use them.

My final thing is to remind you that you are responsible for your own actions, and use of these tools in a live engagement may not be legal.