Exploding the DanBot code to hunt for Hexane’s cyber weapon

// Introduction

DanBot is a piece of malware written in .NET; It’s a backdoor used by a threat actor named by security community “Hexane” (aka Lyceum). Recently the industry has focused its attention on this threat actor tracing back the beginning of its activities to April 2018.

Generally speaking about the communication capabilities of this RAT, it’s able to communicate with command and control servers through two main application layer protocols: HTTP and DNS.

Hovewer, the DanBot version under analysis uses exclusively the DNS protocol (I mean, HTTP protocol support and all related routines has been removed).

Since this post will be exclusively focused on some technical details about this toolkit, for further information on this APT group and where it operates we can refer to the following URLs:

1. https://www.secureworks.com/blog/lyceum-takes-center-stage-in-middle-east-campaign

2. https://dragos.com/resource/hexane/

// DanBot Payload

As already said, DanBot is written in .NET and is mainly comprised of two components: a primary executable binary file and an embedded commands handler library (DLL).

Once launched into the victim system, the main payload provides for some startup checks oriented to verify that the current one is the only running instance of the malware.

This is done by checking that the name of its process is the only one running.

Following an extraction of the relevant code:

If the malware does not find conditions to exit the workload, it begins to create files and directories useful to support its malicious activities. For this task, it relies on the internal function called Build_Dir().

Within this function, the DanBot version under analysis goes to verify the presence of the of the folder \Files\ under the startup path. Inside this, it exepects the presence of three additional folders named through the using of system function aimed at creating new GUID values. If it doesn’t find them, it creates them.

Following a snippet of the code in question:

It’s possibile immediately to note that the malware provides for adding the hard-coded characters at the end of the strings destined to be the names of the created folders.

DanBot uses this mechanism to quickly identify the type of folder in relation to its malicious workload.

To better clarify this concept, I created a numbered summary about the relationship between the appended characters at the end of the folder name and its meaning:

4b : This folder is intended for containing the command handling DLL. The final path would be WorkingDir\Files\<GUID_BASED_DIRNAME>+”4b”\RunCal.dll (ref. Dll_Path)

8s : This folder is intended for containing data to be exfiltrated (ref. Upload_Path_Dns)

g8 : This folder is intended for containing files downloaded from the C2 server (ref. Download_Path_Dns)

Completing this task, DanBot writes a file named confs.ini under the working directory. This file is expected to contain the following information:

• URL for HTTP communications
• Host for DNS communications
• Victim ID (from MAC address)

Following, a fragment of code related to the writing of this file using the function “saveconfig”:

In this case, “host” is a static string equal to “excsrvcdn.com”. Configuration data are then encrypted in AES CBC using the key “2@$#%jyth98@4q” and “$1*#rt5^&ds12fp=” as initialization vector.

// Data Exfiltration

DanBot is able to communicate to the outside world and to exfiltrate information by creating and using special DNS requests sent to the nameservers of the host listed in the confs.ini file. These NS operate as command and controls centers. As far observed, these requests usually are DNS A type ones and are addressed to the resolution of specially crafted sub-domains.

Each of these sub-domains are generated in such a way as to contain communication information and data to be sent to the CnC directly in the strings that compose them.

Extracting the DNS requests from a dynamic execution we can obtain something similar to the following image:

The DNS request

“h4aeq_23062123439344237343846334243434510000.excsrvcdn[.]com”

is a good example of how a DanBot crafted sub-domain appears.

In the following image it’s possible to further explode it by summarizing the meaning of the strings that are composing the generated sub-domain during the sending of data to the command and control servers:

Note that the Victim ID is set to “0000” because it’s a first time run. Within the TransferDNS class it’s possibile to have a look to the commands that the backdoor is able to execute and the corresponding pieces of code:

1. id == “0000” so it’s the default at first run. Likely it’s intended to provide a sort of “hello” to command and control server.

2. Likely it’s intended to provide a sort of registration of local ip to command and control server

3. It sends “online” status to command and control server. It can be considered a sort of beaconing function.

4. Transmits the name of .dat file to be uploaded to command and control server

5. Sends data of files under the Upload_Path_Dns folder to command and control server

6. OK for data upload

7. Write tasking files under Download_Path_Dns

8. Remove tasking file under Download_Path_Dns

// Commands Handling DLL

For the DanBot version under analysis, the module aimed at command handling results embedded into the main executable. This module is copied locally during the first run under the path WorkingDir\Files\<GUID_BASED_DIRNAME>+”4b”\RunCal.dll. The payload representing this DLL is stored within a base64 data blob, according to the following code extraction:

DanBot stores commands within files located under Download_Path_Dns. It is able to read, parse and handle commands provided via downloaded files from command and control server.

Under the Download_Path_Dns path, commands are saved in the form of xml files and the backdoor looks for them searching files starting with “0C*” and ending with “.xml” and parse them in order to read the encrypted content within the tags <Data> and </Data>. The following code frame represents a piece of what just reported:

Commands are then extracted and compared with fixed code values in order to determine the action that the malware must perform. The following are the commands extracted from the variant under analysis:

• ChangeH: Change the command and control server in the file work_dir/confs.ini.
• Proxy: Write proxy settings in the file work_dir/Con_f.ini.
• ChangeD: Change the working directory in the file work_dir/confs.ini.
• =>Uploads: Copy a file to be exfiltrated into Uploads directory.
• =>Dir: Copy a file from DownloadsPath to another directory.
• =>Move: Move a file from a directory to another.
• =>Copy: Copy a file to a directory to another.
• Kill: Clean the malware installation
• =>Update: Payload update command.
• DLL Dir: Executes a DIR command within the working directory of the command handling DLL.
• Bot Dir: Executes a DIR command within the working directory of original payload.
• Uploads Dir: Executes a DIR command within the Uploads directory.
• Downloads Dir: Executes a DIR command within the Downloads directory.

// Hunting for Hexane-Lyceum infections

DanBot sends information and data to command and control server through specially crafted DNS requests. According to the behavior observed, by default these are trasmitted using DNS A record requests to malware-composed sub-domains. Indeed, although the use of DNS as exfiltration protocol is probably used as a less detectable alternative to the communication protocols that malware uses most often (HTTP / HTTPS above all), in this case a significant DNS noise was observed in the IT perimeters of victims. For sure, logs of local DNS server could be useful in order to hunt infections derived from these types of DanBot variants.

For example, if we have a look at the following network dump

we can quickly imagine a SNORT rule that would help us:

alert udp $HOME_NET any -> $EXTERNAL_NET 53 ( \
msg: “DanBot DNS Hello detected”; \
pcre:”/[A-Za-z0–9]{1,57}[-|_][0–9]{38}\x09/”; \
classtype:trojan-activity; \
sid:1000571; rev:1;
reference:url,www.emanueledelucia.net;)

For the fs side, a strings based YARA rule for the analyzed sample could be the following:

rule APT_Hexane_DanBot_83276_078 : IRAN THREAT GROUP {
meta:
description = “Detects DanBot DNS Capable RAT”
author = “Emanuele De Lucia”
tlp = “white”
malware_family = “DanBot”
actor = “Hexane-Lyceum”
strings:
$ = “\\Libs.dll” fullword wide
$ = “\\\\RunCal.dll” fullword wide
$ = “GetHostAddressesDelegate” fullword ascii
$ = “Mozilla / 5.0(Windows NT 10.0; WOW64; rv: 63.0) Gecko / 20100101 Firefox / 63.0” fullword wide
$ = “\\RunCal.dll.dat” fullword wide
$ = “GetHostEntryViaIPDelegate” fullword ascii
$ = “FileUploader” fullword ascii
$ = “GetHostEntryDelegate” fullword ascii
$ = “getproxy” fullword ascii
$ = “readhost” fullword ascii
$ = “readconfigpart” fullword ascii
$ = “getproxy_Credential” fullword ascii
$ = “setheader” fullword ascii
$ = “ipconfig /flushdns” fullword wide
condition:
(uint16(0) == 0x5a4d and filesize < 200KB and 6 of them)
}

In SIEM terms we can think, for example, about something that goes to keep trace about the writing of significant files in the victim system.

Having the following SIGMA rule as a reference

we can obtain the following event monitoring example rule

(source=”WinEventLog:Microsoft-Windows-Sysmon/Operational” EventCode=”11" TargetFileName=”*\\Files\*4b\\RunCal.dll”)

// Tactics, Techniques, Procedures

· Actor uses DNS requests to exfiltrate data and information.

· Actor uses speacially crafted sub-domains of the same domain to exfiltrate data over DNS.

· Actor uses XML files downloaded from the C2 in order to get and decrypt commands to be executed.

· Actor uses scheduled tasks in order to achieve persistence.

· Actor uses macro-armed XLS files in order to deliver the payload.

· Actor embeds and extracts further executable components from main malicious payload.

// Indicators of Compromise

[FileName][Artifact]: HPServerManager.exe

[FileName][Artifact]: AdobeReport.exe

[FileName][Artifact]: RunCal.dll

[SHA256][Artifact]: 11c52732d7fde12f5f4c6431f8be876ffd73acdd725c4b908b257be1b007a290