- Folder structure
- Configuration file
- DNS communication
- DNS communication actions
- DNS communication flow
- HTTP/S Communication
- FL*.xml files format – Commands
- VBS Scripts
LYCEUM is a threat group first identified by Dell SecureWorks, which appears to be interested in organizations with ICS such as oil and gas companies in the Middle East. The group may have been active since as early as April 2018.
The group’s activity has similarities to other groups such as COBALT GYPSY (which is related to OilRig, Crambus, and APT34) and COBALT TRINITY (also known as Elfin and APT33), which FireEye, Microsoft, and others have attributed to being supported by the government of Iran.
In this blog post by Section 52, CyberX’s IoT/ICS threat intelligence team, we go beyond past research by reverse-engineering:
- The malicious macro used to deliver the DanBot malware executable
- Specific commands used in DNS tunneling and HTTP/S communication with its C&C server
- Directory structure of the malware
- Visual Basic scripts contained in the malware
- Other technical details
During our investigation, we witnessed multiple XLS files that are responsible for distributing the DanBot malware. Although we have no indication about their method of arrival, we assume they were sent as part of an email spear-phishing campaign.
Here are three examples of lure documents used in this campaign. The first two are more generic, where the third is more ICS focused, and appears to target Arabic speaking victims. The title of the document is “Engineering, security, safety and oil and gas technical programs,” which may indicate that one of the victims works in the oil and gas industry.
In order to activate these documents and run their malicious payload, the user needs to activate the malicious macros, as described in the section below.
The macro is responsible for dropping the main executable payload, named DanBot.
It achieves this by decoding a base64 payload from one of the cells in the sheet., The decoded data is the DanBot payload and its configuration. The payload is being written to the hard drive where different paths are sometimes used.
These are some example of the paths:
Persistency of DanBot is achieved through creation of a scheduled task, which is also created in the macro. The scheduled task is triggered upon user login; or if the user goes idle, newer versions of the macro will run the task every 60 minutes.
This is illustrated in the screenshot below:
The main component uses the configuration file from the same working directory; additionally it creates a temp folder where it stores more data. Under the temp folder, it will create five directories, which may look completely random at first. The folders name consists of <8 random characters><2 meaningful letters>, as illustrated below:
Each folder is used for specific purpose.
|The last 2 letters||Purpose|
|9f||Store uploaded files by HTTP|
|d3||Store download files by HTTP|
|h1||Additional DLL modules|
|4j||Store files to be uploaded by the DNS channel|
|8v||Store downloaded files by the DNS channel|
The config file is encrypted with a hardcoded AES key. After the decryption and after using base64 to decode, it will contain the following string:
The configuration file can be updated during runtime, where fields such as the Bot ID will be set during the communication with the server.
The code will then start communicating with its C&C server.
The DNS communication channel contains the necessary functionality for a full functioning backdoor, which means that file download/upload and execution can be performed solely via the DNS communication channel.
The DNS communication works by tunneling the data through unique subdomains, meaning that the data sent by the backdoor will be part of the subdomain, and the server will answer accordingly, encoding its answer into the IP field of the response.
The bot flushes the DNS regularly, using the command to avoid filling the local DNS cache:
The subdomain DNS query looks like this:
- random – Random 10 chars
- time – Current time
- data – Based on which command is sent
- botid – Unique ID for the victim
The DNS communication channel supports both IPv4 and IPv6.
While IPv4 supports file upload and download, IPv6 only supports file download.
Some of the responses to the DNS queries have special meaning, not just data. Following are the answers:
er (Error, usually failed command) – IP 220.127.116.11
ok (Success, or no change in state) – IP 18.104.22.168
del (Delete, usually instructs the bot to delete temp file) – IP 100.101.108.32
The bot authors used the open source library https://github.com/ghuntley/Heijden.Dns and renamed it to Super.speed to avoid signature detection.
1 Register for new Bot ID
This is the initial request that’s responsible for retrieving the Bot ID, which provides the mac address.
2 Send IP
This action sends its IP to the server, where the IP is encoded as hex. This will happen after Action #1 is executed successfully.
3 Online (keep alive)
This action sends the string “online” encoded as hex, resulting in either “ok” or a number that indicates how many requests are needed to perform a file download, using the Action #7.
4 Upload start
This action sends the file name to be uploaded (encoded as hex) and receives a File ID, which will be used later instead of the Bot ID.
5 Upload continue
This action sends the file data of the uploaded file, where the File ID identifies file association. The File ID received in Action #4.
6 Upload end
This action sends indication that the upload transaction is complete. The File ID received in Action #4.
7 Download file
This action asks the server for the chunk of the file that is being downloaded. The data is decoded from the IP fields as is.
8 Remove file ack
This action notifies the server that the file has been removed successfully.
z Notify file size
This action sends the server the number of chunks in a file. Chunk size will be 15 bytes.
0 Get file pointer
This action receives the offset in the uploaded file for a specific File ID. This offset indicates how much data was uploaded to the server, so the server can resume the upload in case of interruption.
DNS communication flow
Register and poll for commands
The flow starts with registering the bot with Action #1 and #2, then continues polling for a command/file with Action #3.
If Action #3 returns something besides “ok”, the bot needs to download a file. The file might contain instructions and commands from the C&C, and it will be created under the folder “info” and will be called “Prt.xml”. It does by using Action #7.
The unpacked files in the 8v folder will be xml files in the format of “FL*.xml”, which are instructions for the bot. In a case where the unpacked file is with a dll extension, it will be moved to the h1 folder and used as a module.
All the files from the folder 4j will be compressed and uploaded to the server.
There is also IPv6 DNS tunneling, which is mostly the same except it prepends “v.” to the DNS query.
In addition to using the DNS channel, DanBot has the ability to communicate over HTTP. We suspect this is used when a more reliable and higher throughput channel is required, such as when uploading big documents.
In order to communicate with the C&C server, it first tries to use the credentials u3er:POIQWE)(*[email protected]#lkjasd inside the basic authorization header. If everything goes well, it will start communicating over HTTPS.
It also uses hardcoded headers:
user-agent: Mozilla/5.0 (Windows NT 10.0; …) Gecko/20100101 Firefox/64.0
The communication is mainly with the following 4 URLs:
Example of received data from live C&C server:
FL*.xml files format – Commands
These files are received from the DNS and HTTP communication channels, and are stored in folders d3 and 8v (the download folders). They contain commands for execution and their output is saved in the folders 9f and 4j (the upload folders).The naming pattern will be 0C*.xml.
Before executing commands, it uses regex to replace them with a few patterns based on local variables:
- /\”*[email protected]\”/ – will be replaced to relevant download folder, d3 or 8v
- /\”*[email protected]\”/ – will be replaced to relevant download folder, 9f or 4j
- /\”*[email protected]\”/ – will be replaced to the main working folder
- /\”*[email protected]\”/ – will be replaced to the dll module folder, h1
The FL*.xml will be parsed and each command executed; these are the available commands:
As usual, a multi-layered defense is the best course of action, including using:
- Multi-Factor Authentication (MFA) to prevent threat actors from compromising corporate accounts, using password spraying or brute-force attacks, to send phishing emails.
- IOCs to identify compromises based on past activity by this threat actor, recognizing that adversaries often change their TTPs to avoid detection.
- Continuous IoT/ICS network security monitoring, to immediately identify suspicious or unauthorized behavior targeting IoT/ICS devices. The vast majority of IoT/ICS attacks begin with an initial compromise of corporate IT endpoints, from which attackers pivot into operational networks. Behavioral anomaly detection (BAD) will also alert on changes in DNS traffic activity indicating potential DNS tunneling.