APT Cloud Atlas: Unbroken Threat

Introduction

Specialists at the PT Expert Security Center have been monitoring the Cloud Atlas group since May 2019. According to our data, its attacks have been targeting the government sector of the following countries:

• Russia
• Belarus
• Azerbaijan
• Turkey
• Slovenia

The goals of the group are espionage and theft of confidential information.

The group typically uses phishing emails with malicious attachments as the initial vector for their attacks.

In the third quarter of 2022, during our investigation we identified a phishing campaign targeting employees of Russian government agencies. The attackers used targeted mailing based on the professional field of the recipients, even though we found no publicly available information about them.

We first knew about the attackers back in 2014, when Kaspersky researchers published a report. Since then, their tools have not changed much (you can find more about them in the “Malware analysis” section). However, there has not yet been a detailed analysis and description of the functionality of these tools.

In this report, we’ll discuss the main techniques of the Cloud Atlas group, and take an in-depth look at the tools they use.

Analysis of the documents found

As in previous years, the group begins its attack by sending phishing emails, using current geopolitical issues that are directly related to the target country as a bait text. An example of an email with malicious content that was sent as part of the campaign in 2022 is shown in Figure 1. Pay special attention to the sender’s address: the attackers disguised themselves as the news portal Lenta.ru, well-known in Russia and the CIS. However, email addresses with such a domain can be created with Rambler (Figure 2).

Most often, the text is taken from the media or from publicly available official documents. Also, for example, in a 2019 attack aimed at Azerbaijan, a text related to the “Indestructible Brotherhood 2019” training exercises in Tajikistan was used, while in the 2020 attacks on organizations in Belarus, the emails contained a text related to the presidential elections.

Figure 3 shows an example of a document which downloads a malicious template (here is a link to the page with the document’s contents).

In all cases, the malicious attachment was a document (in either DOC or DOCX format) that implements a Template Injection attack. In such attacks, the document does not contain macros or any other malicious code, and, in most of the observed cases when the DOC format was used, it may not be flagged by static analysis tools such as antiviruses (see Figure 4).

The document contains only a link to the template, which is located on a remote server. When the document is opened, the template is automatically downloaded from the remote server.

It’s the template that may be malicious, containing a macro or exploit. This download method is a legitimate function of Microsoft Office, but attackers can take advantage of it. For example, the same technique is used by the Gamaredon group in their attacks.

In most cases of a successful connection, an empty document was returned in response. However, in some attacks, we managed to detect the download of a malicious template in the form of an RTF file containing an exploit for the CVE-2017-11882 vulnerability.

Researchers at Palo Alto discovered a similar malware delivery chain in 2018. In these attacks, the downloaded RTF templates contained an exploit for the CVE-2017-11882 vulnerability, as well as a simple PowerShell backdoor, which was dubbed PowerShower.

We paid special attention to the DOC documents used in this attack: a characteristic feature of all the documents containing a malicious download was a link to malicious content inside the 1Table or 0Table stream (Figure 9, highlighted in green).

After studying the DOC format and comparing malicious documents with regular ones, we found a number of patterns in the infected files.

First, the DOC format requires the 1Table or 0Table stream in any document, along with the mandatory WordDocument stream (Figure 6).

Second, each document contains a special FIB (File Information Block) structure—in Figure 7, the fragment is highlighted in yellow—in which there is a base.fWhichTblStm parameter. Setting this bit to 0 or 1 determines which of the given streams should be used in the document.

Figure 8 shows the structure of an FIB taken from the documentation. Particular attention should be paid to the structure highlighted in red. The G bit interests us here the most (highlighted in green). This is the base.fWhichTblStm parameter.

Finally, the last thing that we discovered: links to malicious templates are always located at approximately the same offsets relative to the hex strings in the Table stream. (We were not much interested in the format of the stream itself yet.) In Figure 9, the strings of bytes are shown in yellow and red. Using these, we calculated various malicious template link offsets. This allowed us to quite effectively detect the use of this technique in a specific implementation.

Attack chain analysis

In the course of our research, we identified several attack chains (Figure 10), which differed in the number of stages required to load the main functionality, as well as the tools used at each stage. Nevertheless, the use of these chains is not new for this group.

The first thing we noticed was a remote template downloading an RTF document with an exploit, which in turn downloads and launches an HTA file. An example of the contents is shown in Figure 11.

An examination of the document and its contents revealed that a vulnerability in Equation Editor was used to launch the exploit payload. The shellcode (highlighted in red in Figure 12) is located inside one of the document’s objects and is executed in the context of the EQNEDT32.EXE process.

The bulk of the shellcode is stored in encrypted form and decrypted after control is transferred to it.

Figure 13 shows the decrypted shellcode, with the first 13 bytes responsible for decrypting the main part of the shellcode (the loop statement is decrypted at the first iteration). For decryption, XOR is used with a two-byte key embedded in the code.

The direct link to the HTA file (through which the loading is performed) is stored in the body of the shellcode (Figure 14) and is additionally XOR-encrypted with the one-byte value of 0x12.

As seen in Figure 11, the HTA file is designed to create on the disk the VBS scripts with the payload for subsequent stages, as well as an LNK file with the main payload containing the code for loading binary modules. Thus, the main task of the VBS macros (in our case, both macros had similar names: unbroken.vbs and unbroken.vbs.vbs) is to deobfuscate the contents of the LNK file (shown in Figure 15) and transfer control to it, after which the payload which was downloaded by the LNK file code is launched (we will discuss this in the “Malware analysis” section).

It is also worth noting that malicious documents which exploit the same vulnerabilities in Equation Editor and contain identical object names (for example, “weaseoijsd”,highlighted in red in Figure 16) in RTF documents were analyzed by Cisco Talos Intelligence specialists and attributed to the Bitter APT group.

The second chain that we found is downloading malicious PowerShell scripts via remote templates (Figure 17), which in turn download malicious components (mostly Base64-encoded).

We also encountered cases of an intermediate .NET loader that downloaded a payload from a remote server and transferred control to it.

This .NET loader is decoded from Base64 and launched by a PowerShell script (Figure 18).

The export (Figure 19), activated from the loader, takes all the necessary parameters for network communication, including the connection encryption key (highlighted in yellow in Figure 18).

The communication is encrypted with a simple XOR operation with the transferred key (Figure 20).

Malware analysis

Initial module

The main task of the initial stage is to decrypt the loader of the main functionality and transfer control to it. We should mention that all such samples that we discovered are quite large and also obfuscated. The loader, in turn, is stored exclusively in the process memory and is not present on the disk at all. The loader is decrypted in parts, via single-byte XOR with different keys (Figure 21). It is also striking that the decryption code is “diluted” with various operations. This is obviously to make searching for and identifying data decryption procedures more complicated.

We also noted that almost all of the functions that decrypt the loader contain a large amount of polymorphic code. This performs various operations with strings located inside the image, stack strings, as well as with their individual elements (Figure 22 shows an example). However, these operations do not have any effect on the decrypted data itself. They are used to calculate various variables and constants that affect the decryption parameters (data size, offsets, and so on), as well as to complicate the analysis process. The decrypted data is copied to a pre-allocated memory area as a valid PE image, after which control is transferred to it.

Main loader

The loader, in turn, is responsible for reading the data from the file containing the main payload, as well as for its decryption and unpacking.

First, the loader decrypts the configuration located in its body. The decryption algorithm (Figure 23) is single-byte XOR with an embedded key. After decryption, the configuration is validated.

We noted that the configuration has not changed since previous studies—it contains the same data and parameters (Figure 23).

Next, the loader reads the file created at the initial stage of the installation, after which it decrypts and unpacks the data contained in it.

It’s at this stage where the first differences from earlier samples appear: to hide the payload, AES in CBC mode is used, after which the data is unpacked by LZNT1 (it used to be LZMA).

The unpacking algorithm is rather interesting: the data is unpacked not as a single byte array, but by chunks of various sizes. Figure 25 shows the addition of the header_start_chunk offset to the zero offset of each chunk (for the first of them, an additional offset of 4), after which the unpacking function is activated.

Thus, the structure of the first chunk in the decrypted load can be represented as follows:

    

struct first_comprChunk
{
DWORD signature;
WORD sizeOfCurrChunk; // in fact compressed buffer size
BYTE data[sizeOfCurrChunk]; //compressed data
};
    

Correspondingly, the remaining chunks do not have the first DWORD field and have the following structure:

    

struct comprChunk
{
WORD compressedBuffSize;
BYTE data[sizeOfCurrChunk];
};
    

Each chunk is unpacked independently of the others, without any padding, strictly according to the offsets from its headers.

The final stage of the loader involves loading the unpacked data as a valid PE image, searching for the required export by the ordinal name, and transferring control to it (Figure 26).

Payload

The data received at the loader stage is the payload of the malware. Its main functionality is to initialize the connection to the control server and load various modules from it.

Curiously enough, the payload module also has a configuration inside which is identical to the one in the loader, but in this case it is AES-encrypted and gets decrypted after control is transferred to the main module.

Next, the malware generates a communication packet that is sent to the server to establish a connection. This packet contains information about the infected machine and is most likely designed to identify targets that are of interest for attackers.

The structure of the packet is shown below (Figure 27).

    

struct Message
{
DWORD lenOfPacket;
DWORD sizeOf_OSVERSIONINFO;
BYTE data_OSVERSIONINFO[sizeOf_OSVERSIONINFO - 4];
DWORD volumeInformation;
BYTE timestamp[16]; // GetLocalTime
WORD GetUserDefaultLCID;
WORD GetSystemDefaultLCID;
DWORD len_of_1_field;
DWORD len_of_2_field;
DWORD len_of_3_field;
DWORD len_of_4_field;
char username; //1_field
char PcName; //2_field
char executePath; //3_field
char applicationName; //4_field
char argvParam;
DWORD lenOf_curr currFileSystem;
char currFileSystem[lenOf_curr currFileSystem];
};

The malware sends the generated packet to the control server, using the CLSID_IServerXMLHTTPRequest2 COM object for communication (Figure 28).

The restored table of this object’s virtual methods can be described by the following structure:

    

struct IServerXmlHttpRequest2Vtbl
{
int QueryInterface;
int AddRef;
int Release;
int GetTypeInfoCount;
int GetTypeInfo;
int GetIDsOfNames;
int Invoke;
int open;
int setRequestHeader;
int getResponseHeader;
int getAllResponseHeaders;
int send;
int abort;
int get_status;
int get_statusText;
int get_responseXML;
int get_responseText;
int get_responseBody;
int get_responseStream;
int get_readyState;
int put_onreadystatechange;
int setTimeouts;
int waitForResponse;
int getOption;
int setOption;
int setProxy;
int setProxyCredentials;
};
    

It should be noted that the protocol for communicating between the malware and the server supports five types of requests (Figure 29), each of which is used at a certain stage of communication.

For example, after a PROPFIND request that installs the directory contents on the remote server, a GET request is made to load the module contained on the control server. Curiously, if the loading is successful, this module is deleted (Figure 30).

If the communication is successful, binary data is loaded (Figure 31) containing a specific module in obfuscated form.

The same procedures are used for obfuscating the data as for extracting the payload with the loader: AES-CBC encryption and LZNT1 compression.

The functions responsible for the payload extraction procedure, as well as the encryption keys and initialization vectors used to encrypt the communication, are identical to those used to extract the payload in the loader.

In the course of our research, we managed to obtain a sample that the malware downloads from the control server (examples of the server contents are shown in Figures 32 and 33).

The loaded module is decrypted and unpacked (Figure 34), and placed in the memory as a PE image, just as in the case of the loader. It’s also worth noting that the ordinal name (which is used to search for the export to call) is identical to the one used to transfer control to the payload.

The decrypted payload is an executable module, which is preceded by a configuration. Based on the content of the configuration, the main functionality of the loaded module becomes clear: to steal files from an infected computer according to certain parameters.

In particular, attackers are interested in files with these extensions: *.doc, *.docx, *.xls, *.xlsx, *.pdf, *.rtf, *.contact, *.odt, *.jpg, *.jpeg. Accordingly, the paths needed to search for the files are also present in the configuration. These can be both disk names and network paths to remote machines.

Functionality of the loaded module

The first thing that interested us was that the function that transfers control to the code of the loaded module in the first argument (Figure 35) passes a pointer to the function which communicates with the control server.

Analyzing this function allowed us to understand that in this case the communication scheme is identical to the one described above: data is transferred by function calls from the table of virtual methods of the same COM object (in this case, PUT is used as the communication method).

Other than this, the analysis of the loaded module reveals nothing of interest. It simply performs a recursive search in the directories of certain paths.

It’s worth noting that for each type of disk connected to the computer, a different type of search is used (Figure 36). It is also possible to steal files from remote servers—in this case, usernames and passwords (stored in the malware configuration) are transferred as parameters.

Let’s also have a look at the function responsible for analyzing the contents of the scanned directories (Figure 37). It’s worth noting that the function itself does not read the file directly. Instead, the pointer to the read function (pfnReadFile in the figure) is transferred through the global context—the structure that is initialized at the initial stage of the application—and the function is called this way.

Network infrastructure

All the domains that we discovered in the 2019–2021 attacks were registered through the anonymous registrar bitdomain[.]biz. This resource guarantees complete anonymity and payment on the service is made exclusively in bitcoins.

After analyzing the SOA records of the domains, we found that the admin email address field contains perfectly normal email addresses. In some cases, they turned out to be the registrant addresses that we found in WHOIS. Therefore, in those domains where WHOIS was hidden by the privacy settings, it can be assumed that the email in the SOA is the email of the registrant.

When analyzing the 2022 campaign, we found a pattern: all the control servers registered by the attackers are used only to load remote templates.

List of the detected servers:

• checklicensekey.com
• comparelicense.com
• driver-updated.com
• sync-firewall.com
• system-logs.com
• technology-requests.net
• translate-news.net

We also discovered an interesting fact: the attackers disguised one of the control servers (technology-requests.net), trying to make it look like the site https://www.hoosierheightsindianapolis.com (Figure 38).

Figure 39 shows what the malicious site looked like on July 26, according to webcache.googleusercontent.com.

The malicious tools communicate through a cloud service (similar to previous years), namely OpenDrive (https://www.opendrive.com). The service is used for both storing the malware modules to be loaded and for loading the collected data. In this case, a temporary mailbox is used for logins.

Conclusion

The Cloud Atlas group has been active for many years, carefully thinking through every aspect of their attacks. The group’s toolkit has not changed for years—they try to hide their malware from researchers by using one-time payload requests and validating them. The group avoids network and file attack detection tools by using legitimate cloud storage and well-documented software features, in particular in Microsoft Office.

The attackers also carefully choose their victims and target their attacks: the group used targeted mailings based on the professional field of the recipients, but we noted the absence of any publicly available information about the recipients, which could indicate a well-prepared attack.

We predict that the group will continue to operate, increasing the complexity of its tools and attack techniques due to the fact that it has once again attracted the attention of researchers.

Authors: Denis Kuvshinov, Aleksandr Grigorian, Daniil Koloskov, Positive Technologies

The article’s authors thank the incident response and threat intelligence teams PT Expert Security Center for their help in drafting the story.

Detection of CloudAtlas group activity by Positive Technologies products

MP SIEM

The following correlation rules analyze triggered processes and help identify the described activity:

• Suspicious_Connection
• Malicious_Office_Document
• Windows_Autorun_Modification

The following correlation rules analyze the triggered scripts and help detect the described activity:

• Execute_Malicious_Powershell_Cmdlet
• Execute_Malicious_Command

Implementation of D3FEND techniques in MP SIEM, which will help in detecting CloudAtlas grouping activity

PT NAD

PT NAD contains a CloudAtlas reputation list, which will help in identifying CloudAtlas grouping activity.

Implementation of D3FEND techniques in PT NAD, which will help in detecting CloudAtlas activity.

PT Sandbox

PT Sandbox verdicts on CloudAtlas grouping activity:

• Trojan.Win32.Generic.a
• Trojan.Win32.RegLOLBins.a
• Backdoor.Win32.CloudAtlas.a
• Trojan-Downloader.Win32.Generic.a

Network traffic analysis rules to help detect CloudAtlas grouping activity:

• LOADER [PTsecurity] Possible CloudAtlas
• SUSPICIOUS [PTsecurity] PROPFIND method in http request
• SUSPICIOUS [PTsecurity] MKCOL method in http request

Yara-rules, which will help in detecting CloudAtlas grouping activity:

• PTESC_tool_win_ZZ_OfficeTemplate__Downloader__DOC
• PTESC_exploit_win_ZZ_MalDoc__CVE201711882__Rtf__CA

Implementation of D3FEND techniques in PT Sandbox, which will help in detecting CloudAtlas grouping activity

Yara

    

rule PTESC_tool_win_ZZ_OfficeTemplate__Downloader__DOC
{
	strings:
		$a = {00 A5 06 6E 04 B4}
		$b = {FF FF FF 7F FF FF FF 7F}
		$c = {B4 00 B4 00 81 81 12 30 00}
		$pref_1 = {68 00 74 00 74 00 70 00 3A 00 2F 00 2F}
		$pref_2 = {68 00 74 00 74 00 70 00 73 00 3A 00 2F 00 2F}
	condition:
		uint16be ( 0 ) == 0xd0cf and ( for any i in ( 300 .. 400 ) : ( uint8be ( @a + i ) == 0x68 and uint8be ( @a + i + 2 ) == 0x74 and uint8be ( @a + i + 4 ) == 0x74 and uint8be ( @a + i + 6 ) == 0x70 ) or for any j in ( 100 .. 200 ) : ( uint8be ( @b + j ) == 0x68 and uint8be ( @b + j + 2 ) == 0x74 and uint8be ( @b + j + 4 ) == 0x74 and uint8be ( @b + j + 6 ) == 0x70 ) or for any k in ( 200 .. 400 ) : ( uint8be ( @c + k ) == 0x68 and uint8be ( @c + k + 2 ) == 0x74 and uint8be ( @c + k + 4 ) == 0x74 and uint8be ( @c + k + 6 ) == 0x70 ) ) and ( ( for any l in ( 14 .. 70 ) : ( uint8be ( @pref_1 + l ) == 0x2f ) ) or ( for any y in ( 16 .. 70 ) : ( uint8be ( @pref_2 + y ) == 0x2f ) ) )
}

    

rule PTESC_exploit_win_ZZ_MalDoc__CVE201711882__Rtf__CA
{
 strings:
 $equation = "4571756174696F6E" nocase ascii //180000004571756174696F6E
 $msftedit = "generator Msftedit 6.39.15" nocase ascii //generator Msftedit 6.39.15.1401
 $objclass = "objclass weaseoijsd" nocase ascii
 condition:
 uint32be ( 0 ) == 0x7B5C7274 and ($equation and ($msftedit or $objclass) or (for any i in (50..350) : (uint8be (@equation + i) == 0x64 and uint8be (@equation + i + 2) == 0x64 and uint8be (@equation + i + 4) == 0x64 and uint8be (@equation + i + 6) == 0x38)))
}

IOCs

File indicators

Network indicators:

• api-help.com
• driver-updated.com
• sync-firewall.com
• system-logs.com
• technology-requests.net
• translate-news.net
• checklicensekey.com
• comparelicense.com
• msupdatecheck.com
• protocol-list.com

Payload filenames (from the configuration):

• callicrates
• tinh
• amianthium
• mandarinduck
• cushioning
• kingsclover

Email addresses from which malicious emails were sent:

MITRE TTPs

General TTP countermeasures used by CloudAtlas

Basic protective measures

Additional protective measures

Source: https://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/apt-cloud-atlas-unbroken-threat/