Malware Analysis - Dark Comet RAT
Post By Asad Ullah
A Remote Administration Tool (otherwise known as a RAT) is a piece of software designed to provide full access to remote clients. Capabilities often include keystroke logging, file system access and remote control; including control of devices such as microphones and webcams. RATs are designed as legitimate administrative tools, yet due to their extensive capabilities are often seen used with malicious intent.
When a RAT is identified as the payload in a malicious infection, typical malware analysis will resolve all the capabilities being provided to the attacker. However, the attacker may not be using all the capabilities provided; they may only be using the keylogging facility, or using the backdoor to install further tools onto the infected host. To make a full impact assessment, this detail is necessary and may only be available through analysis of the commands sent to the host by the attacker. However, access to the command and control traffic is limited as most RATs implement encryption or obfuscation to hide data sent over the network.
In this blog post I will take a look at a RAT called Dark Comet. I will run through the capabilities provided by the tool, examine the associated network traffic, identify the encryption algorithm and show how the key can be identified with a little analysis of an infected host.
DETAIL
Dark Comet RAT has been available for a few years and is now at version 4, with over 70,000 downloads to date. The RAT appears to be regularly updated with bug fixes and new features.
Dark Comet provides many very similar features to other commercially available RATs and implements the same Client-Server architecture as shown in the diagram below. Servers are built on the Client machine and deployed to as many remote hosts as required, once deployed they will make a connection back to the client and await commands. The Client-side provides an administration console to manage all incoming connections, allowing full command and control capability and file system access. Multiple server ‘profiles’ can be maintained from a single client, and the servers may be updated or uninstalled remotely.
The screenshot below shows the main administration console running on the client where servers are built and all incoming connections controlled:
DEFAULT SERVER SETTINGS
When a server is created via the administration console, a number of settings are required. The following table shows the default settings used for server creation with a version 4 client and may be commonly used.
Bold indicates a regular expression
In addition to the basic settings above, a series of options are provided during the server build process. These options affect how the server will act on the host, such as autostart locations and provide additional capability such as keylogging and host file modification. The range of options available are shown below.
Module Options- Melt server executable after initial execution
- Change file creation date (if selected, the date is set to 16/04/2007 unless specified otherwise, no option is available for time change)
- Persistence installation (Various persistence methods have been seen including use of the HKLM Run Key and Userinit Keys)
- File attributes (select multiple, default none): Hidden, System, Archive, Temporary, Read Only
- Path attributes (select multiple, default none): Hidden, System, Archive, Temporary, Read Only
- Hide startup key from msconfig (32bit only)
- Hide stub from explorer and related file management tools
- Hide parent stub from explorer and related file management tools
- Explorer Injection is also available in a specific “FWB” (Firewall Bypass) version
- Disable Task Manager
- Disable Registry
- Disable Windows Firewall (XP SP3 to Windows 7)
- Disable Windows UAC
- XP SP2 or earlier:
- Disable AV Notify
- Disable Security Center
- Disable Windows Update
- Disable Control Panel
- Active offline keylogging from startup is disabled by default, however live keylogging can be enabled post infection. The keylog created by offline keylogging can also be sent via FTP (disabled by default).
- Hosts file (system32\drivers\etc\hosts) modification can be included in the server build so that the modification takes place on server startup, prior to any attempt to establish a network connection. Note that modification of the hosts file is also available remotely from the console once the communication between the server and client has been established.
- No packing by default, however two packers are included: UPX and MPRESS (.NET PE32+)
- No default filename for the module.
ANALYSIS OF NETWORK TRAFFIC
Initial Connection
The server attempts to connect over TCP to the chosen port on the chosen IP/domain. If a connection can be established, command and control traffic begins, encrypted using RC4-256.
If no active command and control traffic occurs, the network connection is maintained with a series of TCP requests [PSH, ACK] containing the word ‘keepalive’, followed by a string of digits. This sequence, as well as the initial command and control conversation in its encrypted form, is shown below:
Encryption Details
All command and control traffic is encrypted with a form of the RC4-256 algorithm. The default encryption key for version 4 is#KCMDDC4#-890, and for version 3 is #KCMDDC2#-890. If a security password is provided during the server build stage, the password is appended to the default key. Therefore, for version 4 with the default password enabled, the encryption key would become:#KCMDDC4#-8900123456789.
The table below shows the traffic from the example above, decrypted.
Client Says: IDTYPEServer Says: SERVER
Client Says: GetSIN192.168.93.130|120826718
Server Says: infoesGuest16|192.168.93.130 / [192.168.93.130] : 1604|XP-CLIENT / Administrator|120826718|0s|Windows XP Service Pack 2 [2600] 32 bit ( C:\ )|x||US|Program Manager|b4c7d186b435fc77626a5ae904879815|275.65 MB/511.48 MB [235.84 MB Free]|English (United States) US / -- |9/22/2011 at 2:58:57 PM
BINARY ANALYSIS
In order to decrypt the traffic, knowledge of the encryption key is required and can be found through analysis of the binary. If the binary is not packed, details including the key and remote IP/domain may be found within the executable in plaintext. However if the binary is packed, such details would not be visible due to obfuscation. When the malicious process is running (either as its own process [default] or injected into other processes [dependent upon server configuration options]), these notable pieces of information can be found in memory.
Finding the Encryption Key
The location of the encryption key is stored in the EAX register at offset [Imagebase + 00003104]. In the disassembly view of the unpacked binary shown below, the command is located at offset [0040310B], equivalent to offset 3104h from the base address 00400000:
If we take a look at the debugged view of the running process shown below, a breakpoint has been put on offset [13143104], equivalent to offset 3104h from the base address 13140000, revealing the location of the encryption key the value of EAX. Note that at various stages of execution, EAX at this offset is also used to store the location of other details such as the IP or command responses:
Alternatively, it is possible that the key can be found manually in the allocated memory space, by searching for the Mutex which can be pulled from the properties of the running process:
Network Detection
Snort signatures for Dark Comet are available. The one shown below has been taken from a recent Emerging Threats [1] signature release. The signature attempts to identify the encrypted command and control traffic; the string of bytes it detects are those seen during the initial connection with the version 3 default key. The signature will match traffic to/from version 3 clients, with no security key configured. If a security key is used or if a later version of the client is used to build the server, the encrypted traffic will differ, and will not be detected by these signatures.
During analysis of the network traffic, a series of common strings were sent to and from the remote hosts; the ‘keepalive’ string. This string was consistent for all versions tested and independent of the security key configuration. Based on this analysis, I wrote the following two signatures to detect the keepalive string:
CONCLUSION
In this blog post I have shown how a combination of reverse engineering and traffic analysis has enabled better detection of targeted malicious activity. Reverse engineering was used to understand the encryption in use and identify how the password can be extracted from an infected host. It is now possible to decrypt the network traffic and clearly see the actual commands used by the attacker during the attack; this enables impact assessment and attribution. In addition, analysis of the network traffic identified can be used to detect future instances of this and similar attacks thus provide future protection.
Remote Administration Tools like Dark Comet are frequently seen used in targeted attacks and research like this allows us to understand the threats, detect them early, and understand the impact to the client. Context continues to invest research efforts into the analysis of new and existing threats used within targeted attacks.
REFERENCES
[1] - Emerging Threats - http://www.emergingthreats.net[2] - Emerging Threats Rules - http://rules.emergingthreats.net
About the Author
0 comments:
Post a Comment