Deep Dive into the Lyceum Danbot Malware

[MalBot]

INTRODUCTION

LYCEUM

• Phishing methods
• Malicious macro

DANBOT MALWARE

• Folder structure
• Configuration file
• DNS communication
• DNS communication actions
• DNS communication flow
• HTTP/S Communication
• FL*.xml files format – Commands
• VBS Scripts

RECOMMENDATIONS

IOCS

• “Worst Passwords” phishing documents
• “Top 10 Security Practices”
• Arabic ICS
• DanBot
• C&C domains

INTRODUCTION

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

LYCEUM

Phishing methods

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 illustrated in the picture below.

Malicious macro

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:

• C:\Users\Public\PublicLibs
• C:\Users\Public\Public_Files
• C:\Users\Public\PublicPics
• %TEMP%\.Adobe
• Etc…

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:

DANBOT MALWARE

Folder structure

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

Configuration file

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:

http://www.<malicious_domain>/$.<malicious_domain>$0000$000000000000$30$80000

The string will be split by the character ‘$’, which will lead to these 6 fields:

• http://www.<malicious_domain>/ - HTTP C&C communication address
• <malicious_domain> - DNS C&C communication address
• 0000 – Bot ID, this value is updated by the server
• 000000000000 – Victim Mac address
• 30 – DNS sleep interval, sleeps between polling the DNS C&C
• 80000 - HTTP sleep interval, sleeps between polling the HTTP C&C

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 sample creates mutex “Global\\{{{<GUID>}}}”. The GUID is taken from the .NET assembly metadata and is used to ensure that a single instance is running.

The code will then start communicating with its C&C server.

DNS communication

The DNS communication channel contains the necessary functionality for a full functioning backdoor, which means that file download/upload and execution can be preformed 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:

ipconfig /flushdns & exit

The subdomain DNS query looks like this:

<random>_<time><data><action><botid>.<malicious_domain>

• 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 101.114.32.32
ok (Success, or no change in state) – IP 111.107.32.32
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.

DNS communication actions

1 Register for new Bot ID

This is the initial request that’s responsible for retrieving the Bot ID, which provides the mac address.

<random>_<time><mac>10000.<malicious_domain>

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.

<random>_<time><hex ip>2<botid>.<malicious_domain>

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.

<random>_<time><online (6F6E6C696E65)>3<botid>.<malicious_domain>

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.

<random>_<time><file name (hex)>4<botid>.<malicious_domain>

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.

<index_of_part_uploaded>_<time><data>5<fileid>.<malicious_domain>

6 Upload end

This action sends indication that the upload transaction is complete. The File ID received in Action #4.

<random>_<time><file name (hex)>6<fileid>.<malicious_domain>

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.

<random>_<time><chunk index (hex)>7<botid>.<malicious_domain>

8 Remove file ack

This action notifies the server that the file has been removed successfully.

<random>_<time><RemoveFile (hex)>8<botid>.<malicious_domain>

z Notify file size

This action sends the server the number of chunks in a file. Chunk size will be 15 bytes.

<random>_<time><file size/15>z<botid>.<malicious_domain>

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.

<random>_<time>< fileid >0<botid>.<malicious_domain>

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.

Download files

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 data inside “Prt.xml” is in the format of “<filename>;<data>”, where data is base64 encoded. It will take each row from “Prt.xml” and unpack it into the 8v folder.

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.

Upload files

All the files from the folder 4j will be compressed and uploaded to the server.

IPv6

There is also IPv6 DNS tunneling, which is mostly the same except it prepends “v.” to the DNS query.

HTTP/S Communication

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)(*!@#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
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Enconding: gzip,deflate,br
Accept-Language: en-US,en;q=0.5

The communication is mainly with the following 4 URLs:

1. Download/Upload File - <malicious_domain>/api/IOSet?id=<botId>
2. Delete - <malicious_domain>/api/SetUpdate?id=<botId>&p=<file_name>&t=1
3. Configuration - <malicious_domain>/api/Tik?id=<botId>
4. No upload - <malicious_domain>/api/Response?id=<botId>

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:

• /\”*D@\”/ – will be replaced to relevant download folder, d3 or 8v
• /\”*U@\”/ – will be replaced to relevant download folder, 9f or 4j
• /\”*BOT@\”/ – will be replaced to the main working folder
• /\”*DLL@\”/ – will be replaced to the dll module folder, h1

The FL*.xml will be parsed and each command executed; these are the available commands:

Command	Description	Return value (Stored in upload folder)	Example
Version	Protocol version	In our case 3.0.2	Version
ChangeH	Update HTTP host (Configuration)	Changed or NotChanged	ChangeH <domain>
Tik=	Update DNS sleep interval (Configuration)	Changed or NotChanged	Tik=<value>
Proxy	Create and write the data into ConfP file at the main folder	Proxy Saved or NotChanged	Proxy <domain> <port> <username> <password>
ChangeD	Update DNS host (Configuration)	Changed or NotChanged	ChangeD <domain>
Uploads	Upload files to server	Copied File By Name <full path> or File Not Exists	<filepath> =>Uploads
Dir	Copy file from download folder to other location	Copied File or File Not Found	<source path>*<destination path> =>Dir
Move	Move file to other location	File Moved or File Not Found	<source path>*<destination path> =>Move
Copy	Copy file to other location	File Copied or File Not Found	<source path>*<destination path> =>Copy
Kill	Execute kill VBS		Kill
Update	Execute update VBS		<VBS filepath> => Update
DLL Dir	List files under h1	Content of dir list	DLL Dir
Bot Dir	List files under main folder	Content of dir list	Bot Dir
Uploads Dir	List files under 4j	Content of dir list	Uploads Dir
Downloads Dir	List files under 8v	Content of dir list	Downloads Dir
Raw cmd command	Execute via cmd	Output of execution	<shell command>

VBS Scripts

Kill scripts:

VMWares.vbs

On Error Resume Next
Dim fl
Set fl = CreateObject("Scripting.FileSystemObject")
fl.DeleteFile “<working_dir>/VMWares.vbs”
Dim shell
Set shell=CreateObject("WScript.Shell")
shell.CurrentDirectory=”<working_dir>”
shell.Run "cmd /k VMWares.bat",0,True
Wscript.Quit 1

VMWares.bat

schtasks /delete /tn vmware-authd /f
schtasks /delete /tn vmware_authdTSK /f
rmdir /s /q <working dir>
del /f /q “<working_dir>/VMWares.bat”
exit

Update scripts:

VMWares.vbs

On Error Resume Next
Dim fl
Set fl = CreateObject("Scripting.FileSystemObject")
Dim shell
Set shell=CreateObject("WScript.Shell")
shell.CurrentDirectory=”<working_dir>”
shell.Run "cmd /k VMWares.bat",0,True
Wscript.Quit 1

VMWares.bat

del <path to current file>schtasks /delete /tn
vmware_authdTSKTSF /f
copy <file_name> <path to current file>
schtasks /run /tn:<current process name>
exit

Raw commands:

The commands executed through the raw cmd command are saved under temp folder as <guid>.bat, and contain:

echo off
cd\\&echo on
<command>

RECOMMENDATIONS

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.

IOCS

“Worst Passwords” phishing documents

d6d8ea065e55a623ac542a76be2c00d89f7a00ae6254cd8689b07f7aff4dd2c3
0da8032bede8aa92c42fa7d7ea2b9397e5ec5c02faaa7b8f7c01424885978d64
d6f7b6d8203986b702ed70e0d4db2dd0698af4ef8c635dda63c9cffdccc7457b
79142958db41c421df96f6db5487939bfb996a3166f4f89c6d9a8cddce9fe64b
88ee0327df7b5ec6e3521a8ad5e9d3b8e1320f79cc928af594a3a55d0f95c5b4
e2e59decef4ad004c4160359fdb15fdad0b7d4cc5b585bd315e17d1959afe7d9
ec95229e0310c9b6c81be9d9cb7f8e98e6df3b43e586848cbbb815f61955bfaa
308673b70f7966b41b6fb84334f571d2e6c61e8658358ec1efbef38387050119
a36b8f5bb616c40adc2b3c60d5d0706f8ce12d5c6f29257bd7d956556cb76eb5
18fbe86687134090eef2fbfec358c256bef64e310d3814f7f91263d4257df60c
2d38d46440ea3dfd6c820bd4d06a9e4812d5cef8e930cc05bea8ffce3188cb4c
dd2d493238a513d288fd077a97aa5cb7e388f8ee09245b11ed2d0c084982df93
a3b25928dbfd93ff1333f6d3557e75622d6885441dc8f4ac40feeda8fec01153
14760a9f85e9586c64d936ce4fcbc2ddd68b44d014a7d7d16a72fa2df484b566
610204e0c8c5605e766636880a526d264dc7992fb6f633d75310b3251c9fe7b4
cb8b53bb788758786fe40811136967df2130c356c0f3eb4d23e9b67ab42e7439
17d8f73474aed5c8f0c9569ecd0c842d756097f18a2ec8b01ff42961fbf6c67b
130a167de132dedee9f2e893dfbb9e0de4c74d5614552aecd3297d110bc3a294
0cf9fd6dd259739e6f3e04a6ae303ba0978480e8374ba28ae7ea623ecec15959
f57f2bcac17f2ad861e09c2a46909f5b838cda0d78a54c9c1717cb94ee86ebf0
d5256a0b238b4072ff47fc9c6342399718def2a37085e48487c78a3ce976abdd
06853f7f8f67bd6ee83c46f8c0d8c1c1490218afd9c997ac690634ebf199ad00
c160bebea1440d13e997d08181a93e6310e57dd450589e9ce068cfd7eb3d458b
66d68dcd56c9c6b82dfd859e24c877724b3f3e85eaf16365912d642611674884
a846c86ecfc36717f72341ef79d5d5f7bddcb4a03732d021f75513514293598f
6582ed657dd9cd073cd6a45e8099100abe576fb0426589df1f06228524cda3f6
6c3e2bd77c9799d7e94f57e7f487af073d70aaadff742a052987ef7a77d4e4d6
a0a6b54166ce8b25a296762cb2cf25688205ec0fddbeb03bc8532390f2e7bba5
6d7dff50cce977317df65a0bbde1bbff6831c1d500c9c15a88a02b3efa1843b4
ae7f19235e6705979282e6c324b615be05edd3c413bfca5de8fb89d840a79181
6873d3a8ac87a78ce15ff5c873d45b7a569e0fe9ffa0c49a57c46a8bd7e6cbe4
66a0874a909994f98b78278c25ee8ff39a3a0d5aceee176befd579e16ad3ddd6
112b8593d0300d21050e977aba3385b8a00fdaea051bd151cda33452e56fbb8c
d6643c4e9c424754742d587bd235e5418eefabb2df0794c286adf9550c197516
09a7de7e6a6128e4929c08f5f727555379f122df747630a2af474be022c6d156
8bed5bbb85d88e5f4ad45069788bd29c3b488968e0c2d17ee459c649f47af5a9
7a0fa20c19751d6e769a238253e20efc567a201a93b5e7d62395c9a82fbf3fbb
4a812cd5eaa46f6ea5f6dba8342f9932ca83b4b1eb78a82c76448d48ab61e5c7
9bb5923b3907a83050a0430d0b4f138124fe52fba944c6fa9374ae3ea639c636
307281b56f6ec375ae0ae835821e60a374d29c7d7be8403cc50ce2116ee4e6f9
0069d7589319ee99eabc346ed742d08243fc96459a5c3d1770aa984fea4e5c78
2fdee65c29c233ba02584f16554fed069fb04e3653106261c09465f2dda76230
caa88640979b914cb1dc43442d36dc9fe689089f5f938a6199ca051e86d8557b
50037205dfd335da7f0592fad1a2635275d7acca9b330654e606bad886222b18
a925c692d675783ebc948f67410987d05624070c6b230fcba635d970fdc5e156
14d1eb81a5775fe17462d0b82c0ac15f3c8bb88d32b38ec94dd767ad804faba0
5c0a3f7abab8c7dd74116e04f41c61b39b8f508339dfc3ea650eeb7d1b0c6055
db769cdee96acdd379f2e82ad24ea8c664ac1cda44d805838d16f5f2e5c2a129
e536282421723fd40b3ee69e03b5dac810052bdabf837de2433a4557d9271989
0b5afb306e413db0e1835d865c4aea8f6bbf9774d0541a7617eb4e68716808df
93047bd6893fc0a7d601da19b8f501736786ea196cce7eaac28dad93757c64bb
e565e7d62f564a8a7c0951e5e07da1867b068c98f3a2f30473337283b8f13ecb
38c844152e74579ed22ae907886aba82b730edffd19be44fa9afde3ecd10d131
ec234ab68ccad3ec53ede9ef3145b7b60ab66a98dc66b177259d070f25bd9aaf
90ec639cc8b68ccdd3d643f0e07f517a4d02ee93ec14c233807887402421e253

“Top 10 Security Practices”

e42d49a9660071b69f0bec2ecb5dcc0aa36a1d87ff4f3083ffb5fb1150cef34a

Arabic ICS

7272eb4ebc63240d7746f459f28b9e81d2637c37aec476840a6aa11cbd3f73f8
43ef6f87e2abc6551943557df7f345aeaf50c881772d953317fc7250b211ff9b

DanBot

aa7ef56643d294b442d60137f5a8de15cd8472ecabdad09c9fd7cf64446a35c0
7d3d1701d84bcc088bdd893cd8b7d137c65a38c8af95f6e4c390d48bf96f535a
b767daab16272144f09db405eec72e42f986e7683753a2c1e143cdbe385818e2
148e49964b8cb783b413d832f6ec53cfe07d54abe97d0fd9bb9244bc18f5c3a1
3588d6a0837409035b4e2ae28fd27224bd487fc8ddf7ed8bf6898a3ff3df275f
d6c7872e9a8c921c6027a089d2e96424c3846de08e9522319cad1e190b42291d
30eb4698adb0bb690f3b0f8911cede411f99356e1b56d9d8a882ddde105ad83f
ceedc02e6338c7027d82b4a3a4a43ad971a0342a6f8fa27c47a2520d00bc1a1e
33b02de47f18e6602aa0d5b681048d0a402c4afd3ae7fdde049fd8856e2bf4ca
5768d9d503d01331182b980b41b8fb02a269825e89d3e33e08e6de6f5ffa2024
11c52732d7fde12f5f4c6431f8be876ffd73acdd725c4b908b257be1b007a290
30eb4698adb0bb690f3b0f8911cede411f99356e1b56d9d8a882ddde105ad83f
4c4cc3473e050b83943e58548a71c72603a934b2daba6d57fd75908323d32776
28d8dd812f6b5f1e6e96ff9824054d2141a715ff65b2d7e15e9407bc376b55ed
6f3bcde8f6cfab07587de8bfba5b6bf77397adbe1e8c1a099299d51b404cce1d
72f78276ea06649556c3beaa5a53f1b3faa5e4b2fe094f1e84cc959c70139c02
10d0d53f5e5f34c424431492fa4ee95eb2fa4fe6327455384cf508c586dd2851
aec5a94e21d3a2934593921419c476a8f1a36b875d7356e1d0a00be726bc9488
aa9c1564c7efd80ae61a4b53ffe11f4a0b9b1a6d21b7073985fb7aa87d9e553a
6fccb31da9193e0d9787171b85b0ee28ab7a42bb24a41b3a7636a0263302a100
4c7002a2949c865c0a47ca02b8bfee37c1b40f6d26b478b9c8a23b2e63e6c982
3d222195ef7c1537e0d7d4303f73fb66467c55e0b03c52d4a29ae1ea1881fb73
36e41f4e7c8d71020eb845329b096d267ac95f31334d5881c20f24f23821f2a4

C&C domains

• cybersecnet[.]co[.]za
• excsrvcdn[.]com
• cybersecnet[.]org
• online-analytic[.]com
• web-traffic[.]info

The post Deep Dive into the Lyceum Danbot Malware appeared first on CyberX.

Article Link: https://cyberx-labs.com/blog/deep-dive-into-the-lyceum-danbot-malware/