Little disclaimer for the reader:

Introduction

At time of writing, Abaddon might be the first RAT using Discord as a C2 to carry out attacks and execute commands on infected machines.

While this might not be a big threat to companies (assuming that you already blacklisted any discord domains since it doesn’t make any sense to be allowed on a corporate network), it does expose regular discord users to data theft and possibly victims of a ransomware attack.

Fortunately, the sample got caught by threat intelligence analysts while still being under development and, as far as we can say, this exact non functional sample doesn’t pose any threats, yet.

We believe that similar attacks might be something to be taken seriously since all communications are done through discord servers, making it really difficult, or nearly impossible, to filter malicious traffic.

Functionalities

• Stealing cookies and cached credentials or credit cards.
• RAT capabilities through Discord.
• Encrypt / decrypt files asking for a ransom.
• Establishing remote code executing.

Techincal analysis

Before diving into the code, we wanted to better understand the sample’s behaviour and network activity, so we used Any Run, Cape, Hybrid Analysis and Intezer Analyze to gather additional details.

The sample had always failed to execute on any protected environment, leading us to think that there are some anti-debug and anti-sandbox techniques being used.

Only later we discovered that 2 libraries were missing from the sample and some methods were incomplete, causing the immediate crash of the sample.

The only interesting thing we manage to find was thanks to Intezer:

Discord as a Command & Control server

The technique of using Discord as C2 is still emerging, but as more malware authors pick up on the perks of using Discord as a C2, it is sure to become more widespread.

All communications are TLS encrypted, and can’t be distinguished from normal Discord traffic.

Besides all the traffic being encrypted, using Discord as a C2 also enables quick setup of new / free infrastructure, i.e the threat actor can create a new server per campaign, and host any files needed for the malware using Discords CDN (Content Delivery Network), all without spending any money.

One downside to using Discord as C2 is the need to use a token, which, if extracted from the malware, can be used to take over any server where the Discord bot resides.

This can be somewhat mitigated by encrypting the token, and only decrypting it with a key that is obtained during runtime.

We believe that HERA (one of the missing libraries), was used to operate on encrypted data without the necessity of decrypting it, avoiding to leak the server’s token to any analysts who are analysing the sample.

Replicating the C2 server

A member of our group managed to replicate some similarities of this sample and here’s what the attacker might see on his end:

Available commands

In order to execute a command on a given machine, the attacker needs to know its hardware ID (GUID).

Here’s a list of all the available commands:

• GetFile
• GetDirectory
• GetDirectoryRecursive
• GetDeviceTree
• Shell
• ReportBack
• Ransom
• RansomDecrypt

Stolen information

Upon execution, the sample tries to extract information from the following applications:

• Steam
• Chromium (multiple variants)
• Discord

Discord

The sample will try to find the token in Discord’s log files and tries to validate it through Discord’s API (https[:]//discord.com/api/v8/users/@me).

And extract any useful information it has, including the victim’s MFA code:

Finally, before sending the token back to the C2, it will try to validate it through Discord’s API:

Steam

The following function will read any session Steam files to obtain the username, installed apps, cookies and password if it has been saved:

The sample will also try to use any Steam related cookies it might have obtained, to send a GET request to Steam, in an attempt to validate the cookies it has gotten.

If successful, it will send back the cookie, email associated with that account, username, and balance in Steam wallet:

Chromium

Like a lot of other “stealers”, this malware will try to extract the following data from Chromium DB:

• Cookies
• Credit cards
• Logins

The way it does this, is simply by running SQL queries on the Chromium DB:

Exfiltration method

The main way of exfiltration for the malware is through Discord, here it will send the result of all commands.

This exfiltration method is actually quite convenient, and what might attract more malware authors to use Discord as a C2 in the future.

All connections are TLS encrypted, and they blend in with all the other traffic, nothing in the traffic indicates it is a bot communicating with Discord.

However, when exfiltrating files, the malware opts to use AnonFile (an anonymous file hosting service), where it will upload the files, and send the URL back to the Discord C2.

Missing libraries

The malware seems to have been compiled without the correct libraries, specifically it seems to be missing the Discord.NET and HERA library.

This results in the malware not being able to execute properly.

While we tried different available Discord.NET available projects on GitHub, none of them seemed to be working and match the methods used by the sample, letting us believe that the author might have added custom code.

HERA library

Homomorphic encryption refers to encryption schemes that allow the cloud to compute directly on the encrypted data, without requiring the data to be decrypted first. The results of such encrypted computations remain encrypted, and can be only decrypted with the secret key (by the data owner). Multiple homomorphic encryption schemes with different capabilities and trade-offs have been invented over the past decade; most of these are public-key encryption schemes, although the public-key functionality may not always be needed […]

For more information, read this academic paper and Microsoft’s github project.

Ransomware capabilities

The malware uses standard 128 AES to encrypt files, with a random IV, which the malware appends to the start of the file.

If no masterkey is supplied, it will choose a random 16 byte key, and proceed with encryption.

For the decryption part, it will replace the extension it appends when encrypting (“.abenc”).

After that, it will read the first 16 bytes of the file (the IV needed), then decrypt the file using the masterkey supplied as an argument.