Evasive Panda scouting cloud services

In this blogpost, we provide a technical analysis of CloudScout, a post-compromise toolset used by Evasive Panda to target a government entity and a religious organization in Taiwan from 2022 to 2023. The CloudScout toolset is capable of retrieving data from various cloud services by leveraging stolen web session cookies. Through a plugin, CloudScout works seamlessly with MgBot, Evasive Panda’s signature malware framework.

Key points of this blogpost:

• The CloudScout toolset was detected in Taiwan, between 2022 and 2023, in the network of a religious institution and at a government entity.
• CloudScout utilizes stolen cookies, provided by MgBot plugins, to access and exfiltrate data stored at various cloud services.
• We analyzed three CloudScout modules, which aim to steal data from Google Drive, Gmail, and Outlook. We believe that at least seven additional modules exist.
• Hardcoded fields in CloudScout’s web requests for stealing Outlook email messages suggest that the samples involved were crafted to target Taiwanese users.
• Each CloudScout module, programmed in C#, is deployed by an MgBot plugin, programmed in C++.

Evasive Panda profile

Evasive Panda (also known as BRONZE HIGHLAND, Daggerfly, or StormBamboo) is a China-aligned APT group, operating since at least 2012. Evasive Panda’s objective is cyberespionage against countries and organizations opposing China’s interests through independence movements such as those in the Tibetan diaspora, religious and academic institutions in Taiwan and in Hong Kong, and supporters of democracy in China. At times we have also observed its cyberespionage operations extend to countries such as Vietnam, Myanmar, and South Korea.

Evasive Panda has accumulated an impressive list of attack vectors. We have seen its operators conduct sophisticated TTPs such as supply-chain and watering-hole attacks, and DNS hijacking; in addition, they have abused the latest CVEs affecting Microsoft Office, Confluence, and web server applications. The group also demonstrates a strong capability for malware development, which is showcased in its deep collection of multiplatform backdoors for Windows, macOS, and Android. For Windows, its most-used tools are MgBot (since 2012; a custom malware framework consisting of a main implant and eight currently known plugins as detailed in our WLS blogpost) and the more recently developed Nightdoor (described in another WLS blogpost; a feature-rich backdoor that utilizes public cloud services for C&C communications).

Overview

In early 2023, we detected Evasive Panda deploy three previously unknown .NET modules (internally named CGD, CGM, and COL) at a government entity in Taiwan. These modules are designed to access public cloud services such as Google Drive, Gmail, and Outlook by hijacking authenticated web sessions. This technique relies on stealing cookies from a web browser database, then using them in a specific set of web requests to gain access to cloud services. Unlike stolen credentials, which may be blocked by security features such as two-factor authentication (2FA) and IP tracking, stolen web session cookies allow the attacker to retrieve data stored in the cloud, right from the victim’s machine. In 2023, Google released the Device Bound Session Credentials (DBSC) project on GitHub and, in 2024, the App-Bound Encryption feature in the Chrome 127 update. These are protective measures against cookie-theft malware, such as CloudScout, and could potentially render this toolset obsolete.

Further code analysis of the three modules reveals an underlying development framework, codenamed CloudScout by its developers. In this blogpost, we provide a detailed analysis of this modular framework programmed in C#. To the best of our knowledge, the CloudScout toolset has not previously been documented publicly.

Victimology

According to ESET telemetry, CloudScout was observed in two incidents targeting Taiwan:

• In May 2022, the network of a Taiwanese religious institution was compromised with MgBot and Nightdoor. In this incident, MgBot was used to install a plugin that deploys a CloudScout module.
• In February 2023, CloudScout modules and the Nightdoor implant were detected at what we suspect is a Taiwanese government entity.

Furthermore, we found in some hardcoded HTTP requests the inclusion of Taipei Standard Time as the time zone and zh-CN as the language pack (as shown in Figure 1). Both suggest that these samples were crafted to target Taiwanese users.

Technical analysis

CloudScout is a .NET malware framework consisting of multiple modules targeting different cloud services. The name CloudScout originated from the PDB paths of the modules obtained:

• E:\project\git_new\MProjects\Code\CloudScout\GoogleDriver\CGD\obj\Debug\CGD.pdb
• E:\project\git_new\MProjects\Code\CloudScout\Gmail\CGM\obj\Debug\CGM.pdb
• E:\project\git_new\MProjects\Code\CloudScout\Outlook\COL\obj\Debug\COL.pdb

We also found mention of seven other modules in the framework (see the section CommonUtilities: The heart of CloudScout); at the time of writing, we have not yet observed them deployed on compromised machines, hinting that the attackers deploy them selectively. Altogether, the complete list of CloudScout modules is:

• CGD
• CGM
• COL
• CTW
• CFB
• GMQ
• MEXC
• CEXC
• CZI
• CNE

Based on the naming convention (e.g., the module targeting Google Drive is called CGD, the one targeting Gmail CGM, and the one targeting Outlook COL), we infer that CTW and CFB possibly target Twitter and Facebook. However, the purpose of other modules remains undetermined.

Development timing

The AssemblyCopyright field’s value, Copyright ©  2020, in the .NET manifest of CloudScout modules, as seen in Figure 2, suggests that the CloudScout toolset might have been developed around 2020. Even though the legitimacy of the .NET manifest is questionable, it is consistent across all the samples that we found. In addition, different versions stated in the AssemblyVersion of CGD and CGM reflect the changes added to their code base.

We also found different versions of the embedded internal custom-made library package CommonUtilities. Table 1 shows different versions of CGD, CGM, and COL containing different versions of CommonUtilities.

Table 1. Versions of CloudScout modules

Assuming that the .NET manifest is accurate, in 2020 alone, we observed three new toolsets from Evasive Panda. The other two instances are the first appearance of Nightdoor and a new UDP variant of MgBot (succeeding the UDT variant).

Old dog, new tricks

From a common RC4 encryption key shared by the three modules, we performed a retrohunt and discovered that CGM was deployed by an MgBot plugin called Gmck.dll, which was programmed in C++. The plugin was detected in an incident in 2022 where two machines from the aforementioned religious institution in Taiwan were compromised by Evasive Panda. In that incident (illustrated in Figure 3), MgBot installed the CGM module, which in turn accessed the victim’s Gmail account to download emails and personal information.

Gmck.dll (which we will refer to as Gmck) carries the .NET module CGM within its binary. In order to execute CGM, Gmck first drops the module to disk at a hardcoded path, then starts the common language runtime (CLR) using ICLRMetaHost and ICLRRuntimeHost. Finally, it calls ExecuteInDefaultAppDomain with a reference to CGM’s entry point function (ModuleStart), as seen in Figure 4.

According to our telemetry, CGD and COL modules are also written to the same staging folder, as shown in Table 2.

Table 2. Paths where CloudScout modules are deployed

After the CGM module is successfully deployed, the Gmck plugin needs to provide browser cookies to CGM in the form of a configuration file. Gmck extracts these cookies from web browser database files listed in Table 3. With the release of App-Bound Encryption in Chrome 127 and Edge 128, Gmck is no longer able to decrypt Cookies database files from Chrome and Edge.

Table 3. Database files from which Gmck extracts cookies

The configuration file must have a .dat extension and be RC4 encrypted using the key 0dda5a8d⁠-⁠e4c2⁠-⁠477d⁠-⁠85df⁠-⁠fcb611a62ffe in order to be recognized by CGM. This RC4 key is used by all three CloudScout modules to decrypt the configuration files, which means the MgBot plugins must also use this key for encryption.

Figure 5 summarizes the relationship between Gmck and CGM.

Configuration

The configuration file cm_cke__.dat in Figure 5 is provided by the MgBot plugin after it extracts cookies from a web browser’s database. The CloudScout module obtains a new configuration by continuously monitoring its working directory, looking for files with .dat extensions. For each .dat file that it finds, the CloudScout module spawns a new thread to handle the file, which means it can handle multiple configuration files at the same time. The newly spawned thread handles a full collection cycle, from parsing the configuration to downloading all the targeted data. At the end of the cycle, the configuration file is removed from disk to prevent accidentally repeating the same cycle.

The configuration file is in JSON format. It contains two main data structures: token and config. The token structure contains the cookies organized by domain name. And config contains settings for downloading and staging the collected data for exfiltration, as well as for keeping the program running or exiting after a successful cycle (dealone field). An example of a configuration file is included in Figure 6.

CommonUtilities: The heart of CloudScout

At the heart of CloudScout is the CommonUtilities package, which provides all necessary low-level libraries for the modules to run, as illustrated in Figure 7. This package is stored in the resources section of CloudScout modules and is loaded at the beginning of the ModuleStart function.

As seen in Figure 8, the .NET manifest of CommonUtilities reveals all of its client modules.

CommonUtilities contains quite a few custom-implemented libraries despite the abundant availability of similar open-source libraries online. These custom libraries give the developers more flexibility and control over the inner workings of their implant, compared to open-source alternatives. They also manifest certain unpredictable behaviors that forced us to dig deep into the code to understand. Examples of these custom libraries are HTTPAccess and ManagedCookie.

HTTPAccess provides necessary functions to handle all the HTTP communications of CloudScout modules. It has the capability of modifying HTTP headers, as shown in Figure 9.

As highlighted in this code snippet, the this.mngCk object, an instance of the ManagedCookie class, is used to integrate cookies into the crafted HTTP headers. As the name suggests, ManagedCookie provides functions to manage cookies for web requests between CloudScout and targeted cloud services. What makes this class special is its comprehensive list of cookie parsers capable of turning most cookies into default .NET cookie objects. Figure 10 shows the different regexes created to match various combinations of attribute-value pairs in cookies.

The frame of CloudScout

All CloudScout modules share a uniform architecture, as shown in Figure 11. The core functionality of the module is in the Cloud namespace, which is nearly identical in each module. The implementation only diverges in functions related to authentication and data retrieval, where each module needs to generate specific web requests or to parse certain web responses according to the cloud service it targets.

The streamlined design of CloudScout and the core logic of the Cloud namespace is illustrated in Figure 12.

Authentication

Cookies in general are not very well documented by web platforms. Authentication cookies tend to have short lifespans and are frequently updated as the user interacts with the platform via a web browser. However, as long as the sessions are still valid, the cookies listed in Table 4 can be abused by CloudScout to access and download valuable data from cloud services.

Table 4. Authentication cookies handled by the CloudScout modules

Service	Domain	Required cookies
Google Drive	drive.google.com accounts.google.com	OSID, HSID, SID, SSID, APISID, SAPISID, LSID
Gmail	mail.google.com accounts.google.com
Outlook	outlook.live.com login.live.com	X-OWA-CANARY, RPSSecAuth, ClientId

X-OWA-CANARY is a security cookie used by Microsoft Outlook Web Access (OWA) to prevent cross-site request forgery attacks. It is assigned at the beginning of each session when the user is authenticated. CloudScout’s COL module implements a mechanism to retrieve this cookie when it is not available, by establishing a new session using the RPSSecAuth and ClientId cookies to reauthenticate, as shown in Figure 13.

Data retrieval

After authentication, the CloudScout modules browse the compromised cloud service accounts in a manner similar to how a regular user would with a web browser. To achieve this, each CloudScout module is equipped with a set of hardcoded web requests to perform, along with complex HTML parsers, which identify and extract the data of interest from the web responses.

For example, the CGM and COL modules are interested in mail folder listings and email messages, targeting Gmail and Outlook, respectively. Figure 14 shows the steps that CGM performs to extract email headers, email bodies, and attachments from the HTML content served by the Gmail web server.

On the other hand, CGD is interested in user information from Google Drive; a full directory hierarchy; and files with extensions .doc, .docx, .xls, .xlsx, .ppt, .pptx, .pdf, and .txt. Figure 15 is the code snippet from CGD to generate a download URL for a document.

The module appends a custom header to each downloaded item, whether it is a file or an email. This custom header includes metadata of the item such as client ID (assigned by the malware), email subject, or filename, and the username of the cloud service (Table 5). The added header most likely allows stolen data to be processed at scale, by automated systems, for quick indexing or to perform analysis.

Table 5. Custom headers for downloaded email and files

After adding the header, each item is encrypted using the same RC4 key as used for the configuration file and stored with the filename ._extension>, where indicates the type of stolen data, as listed in Table 6.

Table 6. Filename extension for each data category

For any inquiries about our research published on WeLiveSecurity, please contact us at threatintel@eset.com. 

ESET Research offers private APT intelligence reports and data feeds. For any inquiries about this service, visit the ESET Threat Intelligence page.

IoCs

A comprehensive list of indicators of compromise (IoCs) and samples can be found in our GitHub repository.

Files

Network

MITRE ATT&CK techniques

This table was built using version 15 of the MITRE ATT&CK framework.