WellMess malware: analysis of its Command and Control (C2) server

In July, the National Cyber Security Centre reported that threat actors had been using malware known as WellMess to target organisations involved in COVID-19 vaccine development.

We previously published analysis of the WellMess malware, including details of its capability and functionality. During our investigations, we identified another binary from shared Program Database (PDB) paths, which is highly likely a first stage Command and Control (C2) server used to pass data to a second stage C2. This analysis details the capabilities and limitations of the first stage WellMess controller, with a more in-depth report available from our private intelligence reporting services.

WellMess server

The WellMess server is written in Go and imports two packages, lumberjack and garhttp, that are not part of the standard Go packages. The lumberjack package is an open source logging module, which is available on github. The garhttp package is not available in open source and contains the functionality used to communicate between the server and WellMess binaries.

The WellMess server uses the lumberjack package to create a development.log file in the current directory. This file is used to store information about all the connections made to the C2 and what ports and actions were taken. In addition, if the server encounters any errors then the log file will contain the Go error type and related call history that led to it. An example log file with errors is shown in Figure 1.

The server uses folders in the current directory to store information sent and received from WellMess backdoors and the folder layout is shown in Figure 2. Additionally, the server uses a private key and certificate located in the current working directory during mutual TLS connections.

Based on strings in the binary, the folder names likely stand for Answers, Garbage, Questions and Secure. When the server receives communications from a WellMess backdoor in HTTP mode it will use the A folder to store the data received from the malware. It uses the Q folder to store questions or queries that it is ready to send to the WellMess malware and optionally moves the files from the A and Q folders to the G folder once the data has been sent.

The S folder contains another set of the A, G and Q folders that are used when the server receives and sends data via the HTTPS communication protocol.

When receiving HTTP commands, the WellMess server is setup to receive POST requests that contain RC6 encrypted cookies. The server decrypts the cookies using a hardcoded RC6 key and expects the decrypted data to contain no more than four tags. As the RC6 key is hardcoded and the server does not have any functionality to modify it at runtime, it is unlikely that the threat actor behind WellMess would change the WellMess malware’s RC6 key after initial access as that would also require changing the server software.

The four tags correspond with the format previously reported on in the WellMess backdoor with possible tag names being:

• head;
• title;
• service; and,
• body.

Table 1 - Title tag details

The WellMess backdoor supports the a:\d{1,}_\d{1,} and rc commands, as the initial beacons use the title tags a:1_0 and a:1_1 and the request for a command from the server is sent using the rc command. The other values do not appear to be used by the WellMess backdoor and, based on the functionality, are likely used to manage the operation of this intermediate C2 server.

When the server receives a a:\d{1,}_\d{1,} tag, it creates a folder with the path (relative or absolute) in the head tag. It stores the received information in a file called tmp1_0.tmp with the numbers in the filename being taken from the numbers in the title tag.

As an example, if the initial beacon had a cookie of:

Then the title tag would be used to name the file as tmp1_0.tmp and the head tag of MD5_hash/p would be used to create the directories to store the received data.

The information stored in this file contains newline separated information of the RC6 encrypted and base64 encoded cookie, the IP address and port combination that the POST request came from, the MD5 hash of the received encrypted POST data and the received encrypted POST data. An example is shown in Figure 3.

On receipt of a message with rc in the title tag it will check the Q folder to see if there is a folder with the same name as the hash that is in the head tag of the rc message. If there is, then it expects there to be a subfolder which contains an arbitrary amount of *.tmp files.

The *.tmp files are expected to have contents with newline separated data of:

• A base64 encrypted cookie; and,
• An obfuscated string to be sent as the content of the 200 OK response.

The obfuscated string has the same format of character replacement and splitting into space separated chunks as described in our previous reporting[5] and is either random data or AES encrypted data depending on the command specified in the cookie.

If there is only one *.tmp file in the Q subfolder, then the server will send it with the command specified in the encrypted first line as the Set-Cookie content and the data in the second line to be sent as the body of the POST request. If there are multiple files in the subfolder, then the server will instead send the files as part of a chunked C command.

The rs command checks the A folder to see if there are any directories containing .tmp files and if it finds any then sends all the .tmp files in the first folder found. It uses the first line of the found file as the Set-Cookie data as in the rc command but also RC6 encrypts and obfuscates the file path of the file that is being sent and puts it at the start of the content of the POST request, along with the remaining lines of the file to be sent.

The rsc and rcc commands do the same operations as the rs and rc commands respectively, but they also allow the service tag to specify the file path that is to be used to read data from.

The del command takes a file path in the service tag as the location on the server of a file to delete. If after deleting the file, the folder it was in is empty, then the folder is also deleted.

In HTTPS mode the server has a hardcoded Certificate Authority (CA) certificate that it uses to verify any certificates that connect to the server. In practice, the certificates of both the server and anyone communicating with it will need to be signed by the same CA. This is due to the fact that the embedded CA certificate in this sample has details, described in Table 2, that match the CA certificate details used in the WellMess backdoors.

Table 2 - CA details

When receiving HTTPS commands, the server has a subset of commands available to it. The rcc and rsc commands are not supported and the commands for sending files to be stored in the Q and A folders have tags of just q and a rather than the regular expression as in the HTTP commands.

When data is saved into the A and Q folders in HTTPS mode, the server creates two files – fileBody.tmp and filemd.tmp – rather than one. The fileBody.tmp file has the contents of the POST request placed into it verbatim and the filemd.tmp file contains the encoded cookie and IP/port combination of the backdoor the message came from.

The rs command also has slightly different functionality, as it moves the first pair of files in the A folder into the G folder and then sends the data back to the requestor. The response from the server contains two Set-Cookie headers with the first having a name of Cookie1 and the second having a name of Cookie2. The first cookie contains a base64 encoded string of the command received in the POST request for this file and the second cookie contains the metadata of where the file is located in the server, along with an MD5 hash of the POST request contents and the IP and port that the request came from.

Multiple rs commands will continuously return the data in the G folder if present and only return new files if the G folder has had its contents removed.

Attribution

The NCSC has publicly attributed WellMess to the threat actor we track as Blue Kitsune (a.k.a. APT29). Although we cannot definitively tie the WellMess malware to a particular threat actor based on current information, the WellMess backdoor does share some design similarities with a previous Blue Kitsune tool called Seaduke.^[1][2]

The operation of this WellMess server as an intermediate C2 fits the Seaduke model of using compromised third-party websites or infrastructure to host C2 servers that act as a staging environment to store commands and responses between the threat actor and the backdoor. The implementation details of Seaduke also have some similarities to WellMess, as both use encrypted cookies to transfer metadata about the data being sent and use obfuscated base64 data in HTTP requests as the contents of communications. These techniques are not unique to Blue Kitsune but provide an interesting correlation between the WellMess backdoor and Blue Kitsune tools used since 2015.