DiamondFox - Bank Robbers will be replaced
August 10, 2020 - Reading time: 43 minutes

DiamondFox Kettu is the newest addition to the DiamondFox family. In this post, I will be analysing and discussing how it functions, its encryption, and how it achieves its modularity.

Foreword

First, I would like to give a huge thank you to Casperinous for his amazing help with the config decryption, and to Steve Ragan for editing and reviewing this analysis. This post has taken some time to write due to my desire to create an in-depth look at this piece of malware. For updates and information about my work follow me on twitter @fr3dhk.

Overview

DiamondFox is a well known family within the commodity malware market. The creator has been working on it for a while, and has iterated through quite a few different names and versions. The previous version had the codename "Renard" which is French for fox, this version's codename is "Kettu".

DiamondFox is sold in many blackhat communities by a user named edbitss, along with his other piece of malware, GlitchPOS. A large selling point of DiamondFox is that it's a modular piece of malware. It has been developed so it supports the ability for the user to add plugins into the panel, which will then be executed by the malware. Because of this modularity, the seller has decided to sell different parts of his malware for different prices. 

Prices:

  • Botkiller - 100$
  • Jabber notifier - 50$
  • Cookies grabber - 100$
  • UAC bypasser - 100$
  • Hidden ammyy admin - 150$
  • File stealer - 150$
  • Stealers (browsers, IM, FTP, RDP and web history) - 100$
  • Persistence - 100$
  • Keylogger - 100$
  • Remote console - 100$
  • Crypto hijacker - 100$
  • Bolt - 200$
  • USB spread - 100$
  • Bot - 600$
  • Video recorder - 200$
  • Wallet stealer - 100$

As you can see, this is a somewhat pricey piece of code. It is also a very capable piece of malware with lots of different plugins. The malware is controlled through an HTTP command and control server (C2) which is written in PHP, I'll be discussing the C2 at the end of this post. DiamondFox is written in VB6 and the main part of the malware provides some commonly found features, here are some of them.

  • Encrypted C2 communications & namecoin support
  • Unicode
  • Screenshots
  • Small binary size around 90kb
  • Anti-analysis
  • Native binary
  • Persistence & self-destruction

DiamondFox bases its initial functionality on a config that is set during the building of the binary. This is encrypted so we will need to decrypt it before we proceed with the rest of this analysis.

Configuration & Decryption

Due to the malware being written in VB6, we can use certain tools to decompile the malware into p-code, and then within the same tool, export a pseudo representation of the control flow of the malware. Because the tool does not support analysis functions such as being able to rename functions, and variables, I have had to export the entire pseudo code representation into a text file and then open it in my favourite text editor. In the following screenshots you will see the code that I have analysed and renamed, please take some function names with a grain of salt as I may have given them a generic name. 

Encrypted Config

In the above image you will see the function named EncryptedConfig. This function contains 8 encrypted strings that it proceeds to combine into one long string which is then returned. We can determine that this is the encrypted config as it's one of the first functions called within main.

Decrypt Config

In main we see the first first use of the EncryptedConfig function. Before the malware decrypts the configuration it will first use a different decryption method to decrypt a string. This string encryption is used throughout the malware to evade analysis. Looking at the DecryptString function we see the following.

Decrypt String VB

I have rewritten this function in python (link) so that I can decrypt the rest of the strings within the malware. Now I can go back and decrypt the string before the config decryption. We can presume that the newly decrypted string is our cipher key for the config decryption as it is passed as a paramater to the decryption function.

Decrypt Function

After going through the malware I realised that the malware base64 decodes the config and then uses AES to decrypt the config. Knowing this I then started looking for an IV which made me come across the source code (link) for the class the malware author has used. This source code made it clear that the AES method is ECB and that the malware author also uses encoding to inflate and deflate the configuration. I used the previously decrypted cipher key and plugged it into a recipe (link) I have cooked up in CyberChef (link) to recreate the config decryption process.

CyberChef

The config will determine the following. 

  • C2 URLs
  • User Agents
  • C2 Encryption keys
  • Timers
  • Antis
  • Installation
  • Startup

The key for the decryption of the config will be different per build along with other parts of the configuration. Once the configuration is decrypted different globals will be set so that the malware can determine its functionality.

Installation & Evasion

Before the malware begins with its persistence and evasion mechanisms it will first begin by checking if the anti-analysis options are enabled within the malwares config. If it is enabled then there are a bunch of different if statements that will call some anti-analysis methods. The important methods we see employed by the malware is the checking of DLLs.

Anti-Analysis method

The malware will attempt to load a few different libraries that are commonly found within VM installations. Along with this check the malware attempts to turn off windows defender if the user is an admin.

Anti Windows Defender

If these checks pass and the malware determines that it isn't running within a virtual machine it will then proceed with the installation and persistence of the malware. Persistence begins with DiamondFox determining its installation path from its configuration. Once this directory has been determined the malware will check the location of where it is currently running and compare it with this install location. If they do not match DiamondFox will create the installation directory and then use the following commands in powershell to copy itself to the installation directory.

Drop & Start

Once the malware has copied itself using powershell and the newly copied malware has been started then it will proceed to 'melt' which is a term for deleting itself. This is again done with powershell 

Melt

The malware exits once this command has been executed and we move our analysis to the newly started malware in the installation location. To achieve startup persistence the malware will first check if this functionality is enabled within its configuration. If it is then DiamondFox will again make use of powershell to create a shortcut file and place it within the startup folder for the user.

Create Startup

Command & Control Communications

DiamondFox's command and control communications are done over HTTP where they are encrypted and sent from the malware to a web server running PHP. Before the malware can begin communications it must first resolve the C2s domain. A feature that sets DiamondFox apart from competing malware is the ability to use namecoin domains. To achieve this the malware makes use of the following (link) to be able to easily query namecoin domains. Once the C2 domain has been resolved the malware can then make its first connection to the C2. The malware then checks each of the gates within the config to be able to find the correct one. 

Check Gates

The malware iterates through each gate and then requests it with a unique user-agent that has been specified in the configuration. Along with this the malware has a decryption key that will be verified with the C2. Once a C2 has been verified it will then be set into a global and be used as the main gate. Now that the malware has the correct gate to use, it will then begin by collecting some system information through WMI. 

PC Info

Along with this information we also see the malware collecting running processes and installed programs. On top of DiamondFox collecting basic information about the infected computer it also includes some windows environment information. 

More Info

DiamondFox communications are encrypted with 128-bit AES, this time the first 16 bytes of the connection key is used as the AES cipher key. The malware determines a field to use within the POST request which is determined by the following logic to create a unique field.

Gate Check-In

Now that DiamondFox has the correct gate to use and has collected all of the relevant information about the infected computer it will send a POST to the gate with the information encrypted within the uniquely generated field. Our encryption key for this piece of malware is 'aadd2492be4f9f28' and the generated field is 'a98' which you can see below.

Gate Post

The C2 will receive this post and handle it. Then if the user of the malware has created a task to download and execute malware the POST request will be replied to by the C2 with the file that needs to be downloaded and executed. Retrieving the payload is done in two ways, if the malware is being hosted on the C2 then the malware will request the gate with the gf URL parameter containing the files name. This stands for get file and will return the file requested. If the file is a remote file then the malware will request the gate with the grf (get remote file) URL parameter and the C2 will then proceed to use CURL to proxy the file to the malware. Once the malware has dealt with the download and execute task it'll then proceed to report this to the C2.

DiamondFox is also able to exfiltrate different files, the first file that is uploaded is a screenshot of the infected host. Once the screenshot has been taken the malware will send a POST request to the C2 with the screenshot in the POST body. The gate also uses another uniquely generated URL parameter named slots. This parameter is generated from the first 3 characters in the communications' encryption key. Because our encryption key is 'aadd2492be4f9f28' then the slots URL parameter will be 'aad' as seen below.

Screenshot Upload

The C2 determines what the uploaded file is by its extension. Here is the list of the extensions and their meaning.

  • jpg - Screenshot
  • log - Keylogger logs
  • hst - Web history
  • pw - Stealer logs
  • ftp - FTP logs
  • ins - Software instances
  • ml - Email logs
  • rdp - RDP logs
  • cc - RAM scraper logs
  • wallet - Wallet stealer logs

DiamondFox will also ban IPs that seem to be attempting malicious things. These include trying to enumerate information through the C2 and connecting to the gate with the incorrect user-agent. 

Plugin System

DiamondFox has an extensive plugin system which is one of its main selling points. These plugins are distributed by the seller in the form of an encrypted DLL with the extension .pack and a codename. The pack files can then be uploaded to the C2 and their functionality can be changed accordingly within the control panel. DiamondFox handles plugins by first requesting the C2 gate with the URL parameter 'pl=1' which stands for plugin list. The C2 responds with a comma separated list of all the plugin ids that are enabled. 

Decrypted Plugin List

The malware will receive this text and split it into an array of plugin ids. For the first 6 possible plugins the malware will iterate through the array and check if any of the first 6 plugins are enabled. If a plugin is enabled within these first 6 then it will be retrieved using the URL parameter of 'p' which is equal to the plugin id.

Retrieve First 6 Plugins

Each plugin is uniquely encrypted with its own AES 128-bit cipher key. Once DiamondFox has retrieved the plugin with the 'p' URL parameter it will then proceed to get the plugin password using the 'gpp' URL parameter which will return an encrypted cipher key. This cipher key is then used to decrypt the retrieved plugin. Here is a list of all the plugins along with their codenames, decryption keys and other important information.

Plugin List

Within this MySQL table we see a column named 'install', this refers to whether the plugin should be constantly run or just run once. The first 6 plugins are not installed and are all credential stealers, hence why they are done seperately. Each of these first 6 plugins will write their stolen credentials to a log file in the malware install path with the name scheme of their id + '.log'. The malware will execute the DLL and wait until this log file is available to be sent to the C2. This upload is again done with the slots parameter which in our case is 'aad'.

Upload Stolen Credentials

Once the malware has handled the first 6 plugins it then continues onto a different system where it requests the C2 with a URL parameter of 'lp' which will return a list of a comma separated array of all the plugin ids that are enabled and have install enabled. These can be seen in the table above. 

Get Install Plugins

The malware will then iterate through each of the plugins returned by the C2 and call the HandleInstallPlugin function so that each of these plugins can be ran. 

All installed plugins are kept in a directory named 'modules' within the installation directory. If this directory does not exist then it will be created. Plugins are written to this directory with the name scheme of their id + '.dll'. When the HandleInstallPlugin is called on a plugin then it is first checked to see whether it already exists within the 'modules' directory. If it doesn't then the malware will retrieve it from the C2 and decrypt it. The plugin is retrieved with the URL parameter 'gpb' which is assigned to the plugin ID.

Most of the installed plugins have a configuration that also needs to be retrieved. The configuration file name is retrieved with the 'pcn' URL parameter which is set to the id of the plugin (pcn standing for plugin config name). The C2 will then respond with the filename of the plugin config to be written to within the install folder.

File Stealer Config Name

If the C2 returns a config filename for the plugin then the malware will proceed to request the config from the C2 with URL parameter 'lpc' (load plugin config) which is equal to the plugin's id. This is then written into the plugin's configuration file. Here's an example of the configuration returned for the file stealer plugin.

File Stealer Configuration

The configuration for each malware will vary but parameters are always split by pipes. The plugin's password is then retrieved from the C2 with the already seen URL parameter of 'gpp'. The malware then loads the decrypted DLL and runs it. The output of the dll is then written to a log file and the log file is uploaded to the C2. I'll now concentrate on some interesting plugins but there are too many to cover in one post so I'll just be giving an overview of some of the interesting ones. Here's a table summarising.

URL Parameter URL Example Description Example Decrypted Response
pl http://c2.com/gate.php?pl=1 Enabled plugin list 1,2,3,4,5,6
p http://c2.com/gate.php?p=2 Retrieve encrypted plugin DLL Plugin DLL
gpp http://c2.com/gate.php?gpp=2 Get plugin password a4d54e4e6a1e87c4
lp http://c2.com/gate.php?lp=1 Install plugin list 9,10,11,12,13
gpb http://c2.com/gate.php?gpb=9 Retrieve encrypted plugin DLL Plugin DLL
pcn http://c2.com/gate.php?pcn=9 Retrieve plugin config filename search.conf
lpc http://c2.com/gate.php?lpc=9 Get plugin config *.wallet|ALL|100|200

And here is what the install folder looks like after these plugins have been ran.

Install Folder After Plugins

In the above image you can see the configuration files for different plugins and the folder that will contain videos for the screen recorder plugin. Here's the contents of the modules folder.

Modules

Above is the encrypted DLL modules.

Hidden RDP

DiamondFox offers a hidden remote control of an infected computer as one of its many plugins. Although this is named as hidden RDP it does not make use of the windows RDP service and instead will utilise the remote access tool called Ammyy Admin (link). Ammyy Admin is commonly used in tech support scams and is also the base for the FlawedAmmyy malware (link). Unlike other plugins DiamondFox will only trigger this plugin if the user has created a task for an infected computer to start the hidden RDP process. When opening Ammyy Admin you will be greeted with the following. 

Ammyy Admin works by creating a unique ID and password for your computer that you can share with someone else who will then proceed to be able to connect to your computer using these credentials. But this would create issues for DiamondFox as it must run Ammyy Admin without notifying the user whilst also being able to pass the client ID and password back to the C2 for malicious users to exploit. So to combat these issues DiamondFox uses the following exploit (link) to hide the GUI, set a specified password and also know the location of the infected user's ID in memory. Here's main where we can see the plugin making use of this exploit (I have renamed functions for clarity).

HRDP Main

We initially see a mutex being created so that the plugin isn't running twice. Then the malware will make sure that the 'ID.txt' file does not exist in APPDATA as this is where it'll write the infected user's Ammyy Admin client ID. The malware will then create a directory in the 'ProgramData' directory named 'AMMYY'. Once this directory has been created then the malware will write the authentication bypass files to this folder. The malware will then proceed with process injection into Windows Media Player.

Inject Ammyy Admin

The process injection is done by first locating where the Windows Media Player binary is located and then loading the Ammyy Admin binary from resources. The Ammyy Admin binary is then injected into a newly started Windows Media Player process. The process injection will also make use of the -nogui exploit within the injected process so that Ammyy Admin does not display anything to the user. The malware will then proceed with another process injection.

Start Loader

The malware loads another binary from resources which is responsible for reading the client ID from memory and then writing it to the 'ID.txt' file in APPDATA. The ID.txt file contents is then uploaded to the C2 for the user to then be able to connect to the infected computer.

Remote Console

If the user wants to start a remote shell for their infected computer then they can do it through the remote console plugin. This plugin allows the user to be able to command a remote command-line instance on the infected computer. Like the hidden RDP plugin this plugin is only triggered upon user trigger. Here's what this looks like for the user.

DiamondFox Remote Console

When the plugin is triggered we see the same process of DLL loading. Once the DLL is loaded the plugin begins by creating a mutex and then proceeding with checking in with the C2. This is done by setting a URL parameter of 'cmd' which is equal to a base64 encoded string of the infected computers HWID + '|Connected'. Let's take a look at the plugins main.

Shell Main

We see the main loop which will request the C2 looking for commands. If it gets a run command then a file will be dropped to the disk and then run using powershell. Other commands will be ran through a hidden command-line with width and height set to 0. Standard input output will be used to enter and retrieve commands from this hidden CMD process and the output will then be sent back to the C2 to be displayed by the user.

Persistence

To keep the infected user from being able to kill the DiamondFox process the developer has created a plugin to watch the DiamondFox process and restart it if it has been stopped. The plugin begins by determining if the infected computer is using a 32bit or 64bit architecture. If the victim is using 32bit then the malware will get the x86 program files directory or if the host is 64bit then it'll get the program files directory. Once it has a directory to use it will iterate through the sub directories and find the first directory that contains an executable. When an executable has been found the malware will load another binary from resources and inject it into the chosen executable.

The injected executable will proceed to copy the main DiamondFox binary and watch the process of the malware. If the process stops then the malware will use powershell to restart the process. If the file is deleted then the plugin will drop the copied binary and start the process.

UAC Bypass

To give the malware a stronger hold on the infected computer DiamondFox makes use of User Access Control (UAC) bypasses to be able to gain higher privileges. When the plugin is loaded it begins by querying two registry keys.

UAC Checks

These checks will query the registry keys that determine if any attempts at elevation of privileges will create a visual prompt for the administrator of the infected computer. If the attempts will create visual prompts then the plugin will exit. If not then the UAC bypass plugin will then query the windows product name and if the version of windows is not supported then the plugin will exit.

UAC Product Name Checks

I'm not going to reiterate all the different bypasses DiamondFox uses as they have been described in more depth elsewhere. Here are the bypasses it uses as of writing this analysis.

C2 & Panel

Here are some screenshots of the inside of the panel. 

Login

Dashboard

Clients

Client

Statistics

Reports

Settings

Plugins

Task Manager

Epilogue

DiamondFox is a very capable piece of malware with many features and plugins. Although some plugins seem to be very basic the malware comes together as a very dangerous piece of kit. This analysis took longer than I had planned so I have left out a few of the plugins. I may come back to write about these if I see it as necessary. I hope that this was a beneficial analysis and until the next time, goodbye & thanks for reading!

IOC

Categories

Links