CloudSorcerer APT uses cloud services and GitHub as C2 (2024)

In May 2024, we discovered a new advanced persistent threat (APT) targeting Russian government entities that we dubbed CloudSorcerer. It’s a sophisticated cyberespionage tool used for stealth monitoring, data collection, and exfiltration via Microsoft Graph, Yandex Cloud, and Dropbox cloud infrastructure. The malware leverages cloud resources as its command and control (C2) servers, accessing them through APIs using authentication tokens. Additionally, CloudSorcerer uses GitHub as its initial C2 server.

CloudSorcerer’s modus operandi is reminiscent of the CloudWizard APT that we reported on in 2023. However, the malware code is completely different. We presume that CloudSorcerer is a new actor that has adopted a similar method of interacting with public cloud services.

Our findings in a nutshell:

• CloudSorcerer APT uses public cloud services as its main C2s
• The malware interacts with the C2 using special commands and decodes them using a hardcoded charcode table.
• The actor uses Microsoft COM object interfaces to perform malicious operations.
• CloudSorcerer acts as separate modules (communication module, data collection module) depending on which process it’s running, but executes from a single executable.

Technical details

Initial start up

The malware is executed manually by the attacker on an already infected machine. It is initially a single Portable Executable (PE) binary written in C. Its functionality varies depending on the process in which it is executed. Upon execution, the malware calls the GetModuleFileNameA function to determine the name of the process it is running in. It then compares this process name with a set of hardcoded strings: browser, mspaint.exe, and msiexec.exe. Depending on the detected process name, the malware activates different functions:

• If the process name is mspaint.exe, CloudSorcerer functions as a backdoor module, and performs activities such as data collection and code execution.
• If the process name is msiexec.exe, the CloudSorcerer malware initiates its C2 communication module.
• Lastly, if the process name contains the string “browser” or does not match any of the specified names, the malware attempts to inject shellcode into either the msiexec.exe, mspaint.exe, or explorer.exe processes before terminating the initial process.

The shellcode used by CloudSorcerer for initial process migration shows fairly standard functionality:

• Parse Process Environment Block (PEB) to identify offsets to required Windows core DLLs;
• Identify required Windows APIs by hashes using ROR14 algorithm;
• Map CloudSorcerer code into the memory of one of the targeted processes and run it in a separate thread.

All data exchange between modules is organized through Windows pipes, a mechanism for inter-process communication (IPC) that allows data to be transferred between processes.

CloudSorcerer backdoor module

The backdoor module begins by collecting various system information about the victim machine, running in a separate thread. The malware collects:

• Computer name;
• User name;
• Windows subversion information;
• System uptime.

All the collected data is stored in a specially created structure. Once the information gathering is complete, the data is written to the named pipe \\.\PIPE\[1428] connected to the C2 module process. It is important to note that all data exchange is organized using well-defined structures with different purposes, such as backdoor command structures and information gathering structures.

Next, the malware attempts to read data from the pipe \\.\PIPE\[1428]. If successful, it parses the incoming data into the COMMAND structure and reads a single byte from it, which represents a COMMAND_ID.

Depending on the COMMAND_ID, the malware executes one of the following actions:

• 0x1 – Collect information about hard drives in the system, including logical drive names, capacity, and free space.
• 0x2 – Collect information about files and folders, such as name, size, and type.
• 0x3 – Execute shell commands using the ShellExecuteExW API.
• 0x4 – Copy, move, rename, or delete files.
• 0x5 – Read data from any file.
• 0x6 – Create and write data to any file.
• 0x8 – Receive a shellcode from the pipe and inject it into any process by allocating memory and creating a new thread in a remote process.
• 0x9 – Receive a PE file, create a section and map it into the remote process.
• 0x7 – Run additional advanced functionality.

When the malware receives a 0x7 COMMAND_ID, it runs one of the additional tasks described below:

All the collected information or results of performed tasks are added to a specially created structure and sent to the C2 module process via a named pipe.

C2 module

The C2 module starts by creating a new Windows pipe named \\.\PIPE\[1428]. Next, it configures the connection to the initial C2 server by providing the necessary arguments to a sequence of Windows API functions responsible for internet connections:

• InternetCrackUrlA;
• InternetSetOptionA;
• InternetOpenA;
• InternetConnectA;
• HttpOpenRequestA;
• HttpSendRequestA

The malware sets the request type (“GET”), configures proxy information, sets up hardcoded headers, and provides the C2 URL.

The malware then connects to the initial C2 server, which is a GitHub page located at https://github[.]com/alinaegorovaMygit. The malware reads the entire web page into a memory buffer using the InternetReadFile call.

The GitHub repository contains forks of three public projects that have not been modified or updated. Their purpose is merely to make the GitHub page appear legitimate and active. However, the author section of the GitHub page displays an interesting string:

We found data that looks like a hex string that starts and ends with the same byte pattern – “CDOY”. After the malware downloads the entire GitHub HTML page, it begins parsing it, searching specifically for the character sequence “CDOY”. When it finds it, it copies all the characters up to the second delimiter “CDOY” and then stores them in a memory buffer. Next, the malware parses these characters, converting them from string values to hex values. It then decodes the string using a hardcoded charcode substitution table – each byte from the parsed string acts as an index in the charcode table, pointing to a substitutable byte, thus forming a new hex byte array.

Alternatively, instead of connecting to GitHub, CloudSorcerer also tries to get the same data fromhxxps://my.mail[.]ru/, which is a Russian cloud-based photo hosting server. The name of the photo album contains the same hex string.

The first decoded byte of the hex string is a magic number that tells the malware which cloud service to use. For example, if the byte is “1”, the malware uses Microsoft Graph cloud; if it is “0”, the malware uses Yandex cloud. The subsequent bytes form a string of a bearer token that is used for authentication with the cloud’s API.

Depending on the magic number, the malware creates a structure and sets an offset to a virtual function table that contains a subset of functions to interact with the selected cloud service.

Next, the malware connects to the cloud API by:

• Setting up the initial connection using InternetOpenA and InternetConnectA;
• Setting up all the required headers and the authorization token received from the GitHub page;
• Configuring the API paths in the request;
• Sending the request using HttpSendRequestExA and checking for response errors;
• Reading data from the cloud using InternetReadFile.

The malware then creates two separate threads – one responsible for receiving data from the Windows pipe and another responsible for sending data to it. These threads facilitate asynchronous data exchange between the C2 and backdoor modules.

Finally, the C2 module interacts with the cloud services by reading data, receiving encoded commands, decoding them using the character code table, and sending them via the named pipe to the backdoor module. Conversely, it receives the command execution results or exfiltrated data from the backdoor module and writes them to the cloud.

Infrastructure

GitHub page

The GitHub page was created on May 7, 2024, and two repositories were forked into it on the same day. On May 13, 2024, another repository was forked, and no further interactions with GitHub occurred. The forked repositories were left untouched. The name of the C2 repository, “Alina Egorova,” is a common Russian female name; however, the photo on the GitHub page is of a male and was copied from a public photo bank.

Mail.ru photo hosting

This page contains the same encoded string as the GitHub page. There is no information about when the album was created and published. The photo of the owner is the same as the picture from the photo bank.

Cloud infrastructure

Attribution

The use of cloud services is not new, and we reported an example of this in our overview of the CloudWizard APT (a campaign in the Ukrainian conflict with ties to Operation Groundbait and CommonMagic). However, the likelihood of attributing CloudSorcerer to the same actor is low, as the code and overall functionality of the malware are different. We therefore assume at this point that CloudSorcerer is a new actor that has adopted the technique of interacting with public cloud services.

Victims

Government organizations in the Russian Federation.

Conclusions

The CloudSorcerer malware represents a sophisticated toolset targeting Russian government entities. Its use of cloud services such as Microsoft Graph, Yandex Cloud, and Dropbox for C2 infrastructure, along with GitHub for initial C2 communications, demonstrates a well-planned approach to cyberespionage. The malware’s ability to dynamically adapt its behavior based on the process it is running in, coupled with its use of complex inter-process communication through Windows pipes, further highlights its sophistication.

While there are similarities in modus operandi to the previously reported CloudWizard APT, the significant differences in code and functionality suggest that CloudSorcerer is likely a new actor, possibly inspired by previous techniques but developing its own unique tools.

Indicators of Compromise

File Hashes (malicious documents, Trojans, emails, decoys)

Domains and IPs

Yara Rules

MITRE ATT&CK Mapping