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

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.

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

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%TendyronTendyron.exe
  (SHA-1: 09C76522136B5E9BAB74381FEEE265F7E9B1D550)
• http://103.139.2[.]93:1702/okt.dat written to %localappdata%TendyronOnKeyToken_KEB.dll (SHA‑1: F359D3C074135BBCA9A4C98A6B6544690EDAE93D)
• http://103.139.2[.]93:1702/md.dat written to %localappdata%TendyronTendyron.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 HKCUSOFTWAREMicrosoftWindowsCurrentVersionRun.

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.

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.

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.

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

Resource ID	Role	Internal name
100	FlowCloud RAT DLL	fcClientDll
101	32-bit rootkit driver	Driver
102	64-bit rootkit driver	Driver
103	DLL hijacking vulnerable app	N/A
104	Shellcode loaded by the malicious library in the DLL hijacking	SETLANG_dlcore
105	Shellcode that loads fcClient (unused)	N/A
106	Final dropper stage	fcClient
107	32-bit persistence module	fcClientWD_x86
108	64-bit persistence module	fcClientWD_x64
109	Legitimate library used for module stomping	slam
110	DLL used for hijacking	XXXModule_dlcore0
1000	Protobuf serialized FlowCloud configuration	N/A
1001	Dropper configuration	N/A
2000	Used as an alternative or extension to resource 2001	N/A
2001	Path to the registry key for the PrintProcessor service (used by the driver)	N/A
10000	Installation configuration	N/A

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%MSBuildMicrosoftExpressionBlendmsole 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.

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 to English.

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.

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.

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 MicrosoftWindowsCertificateServicesClientNetTask 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 plug-ins, 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.

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>

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%MSBuildMicrosoftExpressionBlendmsolefcdata.

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.

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.

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.

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 \.pipenamedpipe_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.

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 IO 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 \.pipenamedpipe_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 HKLMHARDWARE{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.

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:ProgramDataMicrosoftCryptoRSAMachineKeysLogrsa.txt. Figure 18 shows a 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

Registry Key	Description
HKLMSOFTWAREMicrosoftDRMX4Key	AES key.
HKLMSOFTWAREMicrosoftDRMPSKey	Name of the process into which the shellcode will be injected (spoolsv.exe).
HKLMSOFTWAREMicrosoftDRMX4Data	Encrypted shellcode.

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.

The orchestrator handles seven commands, detailed in Table 3. Output of these commands is written to C:ProgramDataMicrosoftCryptoRSAMachineKeysLogoutput.log.

Table 3. X4 backdoor commands

ID	Name	Description
0x3ECFF9B9D92	osload	Write new encrypted shellcode to HKLMSOFTWAREMicrosoftDRMX4Data. It can also modify X4Key and PSKey.
0x3F5FAFC0EDD	pskill	Kill a process by PID.
0x3F5FB1E6015	pslist	List the running processes using CreateToolhelp32Snapshot and Process32Next.
0x3B6C27610D1	inject	Decrypt and inject   shellcode, from encrypted form on disk, into memory.
0xDA83E71	exec	Execute a given command line.
0xE9478DC	live	Get the PID of the process in which the orchestrator is running.
0x6D6E70D40	cacls	Modify the access controls of a given object using SetEntriesInAclA, SetNamedSecurityInfoA and BuildExplicitAccessWithName.

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.

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

Field	Offset (bytes)	Note
Magic bytes	0x00	The constant 0x48AB2EC2. Messages that don’t start with this magic value are discarded.
<Message dependent>	0x04
Compressed body size	0x08
Uncompressed body size	0x0C
Checksum	0x10	CRC32 of the message body.
Message type	0x14	Integer value indicating the message’s content and the associated action to be performed. We have found code for over 50 message types. There seems to be little to no overlap between the values used by the client and the server. Table 5 presents the types we have   analyzed in more depth.
<Message dependent>	0x18
<Message dependent>	0x1C
Message Body	0x20	The message body can be empty. In this case, the checksum and length fields are set to 0x00.

Table 5. LookBack message types

Message type	Used by	Description
2	Client	Register with C&C server. The body contains configuration and information about the victim host.
3	Server	Acknowledgment for message type 2.
8	Client	Request to download the main backdoor component (SodomMain).
9	Server	Reply to message type 8. The message body contains the SodomMain file.
36 and 38	Client	Transfer file to server in message body.
35 and 37	Server	Response to message 36 or 38.
41	Client	Request file from server.
42	Server	Transfer file to client in message body (response to message 41)

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.

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 purporting it is a GIF image.

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.

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

SHA-1	Filename	Detection	Description
C96558312FBF5847351B0B6F724D7B3A31CCAF03	N/A	Win32/Agent.UWR	FlowCloud v5.0.3 initial loader.
1403241C415A8D686B1148FA4229A2EB833D8D08	setlangloc.dll	Win32/Agent.UNL	FlowCloud DLL hijacking malicious library.
38D0E92AFF991CFC9C68D7BAAD6CB85916139AF5	hidmouse.sys	Win32/Agent.UKR	TA410 32-bit Rootkit/Keylogger driver.
AF978ED8AD37CE1437A6B42D96BF518D5C4CFD19	hidmouse.sys	Win64/Agent.UKR	TA410 64-bit Rootkit/Keylogger driver.
B70F3A3A9B5B8506EE95791469CA496E01AD7DAF	winver32.dll	Win32/Agent.ULH	FlowCloud v4.1.3 hcClientLoaderZero_x86 backdoor.
014421BDB1EA105A6DF0C27FC114819FF3637704	hhh.exe	Win32/Agent.ABYK	FlowCloud v4.1.3 initial loader.
EA298866E5A61FEEA4D062987F23B10A78C8A4CA	N/A	Win32/Agent.ULH	FlowCloud v4.1.3 backdoor.
021B9E2E8AA30B29569254C0378A9F43E4F32EEC	winver64.dll	Win64/Agent.KM	FlowCloud v4.1.3 hcClientLoaderZero_x64 backdoor.
2A2F08FAD6B0A86DC94885224687D954E739CC21	N/A	Win32/ParanoidFish.A	Pafish sandbox detection tool.
3658B7CCA13C8C8AD03E9B6AEFE4B9CBE48E3C81	hidmouse.sys	Win64/Agent.UKR	TA410 Rootkit/Keylogger driver.
517488F6BD0E7FC9EDE82F37226A75212B277E21	hidmouse.sys	Win64/Agent.UKR	TA410 Rootkit/Keylogger driver.
C05B4AD7A3322917E17710842FB88A090198D51F	N/A	Win32/Agent.TWI	LookBack trojanized libcurl loader.
DB2DF1BDF8145CB8ABA3A2026A3CC3EF4F1762BE	phx.dll	Win32/Agent.TWI	LookBack trojanized libcurl loader.
EDE2AB811311FC011B1E89C5A0B7A60C123B7398	hidmouse.sys	Win64/Agent.UKR	TA410 Rootkit/Keylogger driver.
7AA35BA7030AFCD271436DE8173D7B2F317A1BFC	libcurl.dll	Win32/Agent.TWI	LookBack trojanized libcurl loader.
A5C02ABE698300F3DE0B7CC7F0856652753831DA	libcurl.dll	Win32/Agent.TWI	LookBack trojanized libcurl loader.
613C4AFAE8F5F80F22DCD1827E3230FCA361ADA5	libcurl.dll	Win32/Agent.UKD	LookBack trojanized libcurl loader.
859CD6DFDADAB3D6427C6C1C29581CB2094D648F	meterpreter.exe	Win32/Rozena.CP	Metasploit Meterpreter backdoor.
DBEA7F0C0D2BF8BC365A2D1572CA1538FE8FB9A3	responsor.dat	Win32/Agent.ULL	FlowCloud fcClientDLL final stage backdoor.
ADD5B4FD9AEA6A38B5A8941286BC9AA4FE23BD20	絆邧坋蔡趕口昴.doc	Win32/Exploit.Agent.TY	Malicious Royal Road document.
7BA42061568FF6D9CA5FE5360DCE74C25EA48ADA	N/A	Win32/Agent.ACKQ	Packed Tendyron downloader.
D81215890703C48B8EA07A1F50FEC1A6CA9DF88B	N/A	Win32/TrojanDownloader.Agent.FLI	Unpacked Tendyron downloader.
F359D3C074135BBCA9A4C98A6B6544690EDAE93D	OnKeyToken_KEB.dll	Win32/Injector.ELGA	Tendyron malicious DLL.
621B31D5778EC2FB72D38FB61CED110A6844D094	N/A	Win64/Rozena.AO	X4 network shellcode.
BC11DC8D86A457A07CFE46B5F2EF6598B83C8A1F	m.exe	Win32/Injector.EMVA	Korplug dropper.
C369E1466F66744AA0E658588E7CF2C051EE842F	qrt.dll	Win32/Injector.EMVA	Korplug loader.
B868764C46BADC152667E9128375BA4F8D936559	qrt.dll.usb	N/A	Korplug encrypted payload.
BDECA89B4F39E6702CE6CBBC9E6D69F6BBAB01C8	N/A	N/A	Korplug decrypted payload.
5379FBB0E02694C524463FDF7F267A7361ECDD68	sll.exe	MSIL/TrojanDownloader.Agent.GPS	QuasarRAT downloader.
6CC6170977327541F8185288BB9B1B81F56D3FD0	PresentationCache.exe	MSIL/Agent.TZG	QuasarRAT loader.
D95185A4A3F8512D92F69D2ED7B8743638C54BE8	N/A	MSIL/Spy.Agent.AES	QuasarRAT backdoor.
BE7F0E41CD514561AED43B07AA9F5F0842BF876C	HTra.exe	Win32/HackTool.Hucline.AB	HUC Packet Transmitter (HTran).
7F663F50E9D6376715AEB3AB66DEDE038258EF6C	HTran13.exe	Win32/HackTool.Hucline.S	HUC Packet Transmitter (HTran).
BEDA1224B3BB9F98F95FF7757D2687F4D9F4B53A	event.exe	Win32/Agent.UJN	Simple cmd.exe-based backdoor compiled with MingW.
2B61E7C63A0A33AAC4CF7FE0CEB462CF6DACC080	htran.exe	Win32/HackTool.Hucline.AB	HUC Packet Transmitter (HTran).
EF3C796652141B8A68DCCF488159E96903479C29	htran_f-secury.exe	Win32/HackTool.Hucline.AB	HUC Packet Transmitter (HTran).
6B547C244A3086B5B6EA2B3A0D9594BBE54AE06B	inbt.zip	Python/HackTool.Agent.J	EXE masquerading as ZIP. This is a Python network scanner (compiled with PyInstaller).
4CDCE3AF614C2A5E60E71F1205812AB129C0955B	msd017.exe	Python/Exploit.MS17-010.B	This is a Python scanner (compiled with PyInstaller) for the vulnerability MS17-010 (EternalBlue).

Certificates

Serial number	0F8B600FF1882E
Thumbprint	02ED6A578C575C8D9C72398E790354B095BB07BC
Subject CN	Hangzhou Leishite Laser Technology Co., Ltd.
Subject O	Hangzhou Leishite Laser Technology Co., Ltd.
Subject L	Hangzhou
Subject S	Zhejiang
Subject C	CN
Valid from	2012-03-29 09:07:04 UTC
Valid to	2014-04-02 06:24:19 UTC

Serial number	4ED8730F4E1B8558CD1CB0107B5F776B
Thumbprint	850821D88A4475F0310F10FBA806353A4113D252
Subject CN	北京和 赢讯时 科技有限公司 (translation: Beijing   Heyingxunshi Technology Co., Ltd.)
Subject O	北京和 赢讯时 科技有限公司 (translation: Beijing Heyingxunshi Technology Co., Ltd.)
Subject OU	研 发 部 ( R&D Department)
Subject S	北京市 (Beijing)
Subject C	CN
Valid from	2019-11-13 00:00:00 UTC
Valid to	2020-11-12 23:59:59 UTC

Network

Domain	IP	First seen	Details
	43.254.216[.]104	2020-06	Delivery server
	45.124.115[.]103	2020-08	Delivery server
	161.82.181[.]4	2020-12	Delivery server
	43.254.219[.]153	2020-07	X4 C&C server
	154.223.141[.]36	2020-06	HTran C&C server
	103.139.2[.]93	2020-10	Tendyron C&C server
cahe.microsofts[.]com			QuasarRAT C&C server
ffca.caibi379[.]com			QuasarRAT downloader C&C server
smtp.nsfwgo[.]com			Korplug C&C server
	45.124.115[.]103	2020-06	LookBack C&C server
	185.225.19[.]17	2021-01	LookBack C&C server
	94.158.245[.]249	2020-03	LookBack C&C server
	5.252.179[.]227	2021-03	LookBack C&C server
	222.186.151[.]141	2019-11	FlowCloud C&C server
	47.111.22[.]65	2020-09	FlowCross C&C server
	114.55.109[.]199	2020-05	FlowCloud C&C server
dlaxpcmghd[.]com	185.225.17[.]39	2020-09	LookBack C&C server
wwww.dlmum[.]com		N/A	FlowCloud C&C server

MITRE ATT&CK techniques

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

Tactic	ID	Name	Description
Resource Development	T1587.001	Develop Capabilities: Malware	TA410 develops LookBack and FlowCloud.
	T1588.003	Obtain Capabilities: Code Signing Certificates	TA410 uses stolen code-signing certificates.
	T1588.005	Obtain Capabilities: Exploits	TA410 had exploits for ProxyLogon and ProxyShell.
Initial Access	T1190	Exploit Public-Facing Application	TA410 has exploited web server vulnerabilities for initial access.
	T1566.001	Phishing: Spearphishing Attachment	TA410 uses malicious RTF and DOCX attachments to compromise victims.
Execution	T1106	Native API	FlowCloud makes extensive use of the Windows API to execute commands and launch processes.
	T1129	Shared Modules	TA410’s backdoors can load DLLs and execute their payloads.
	T1203	Exploitation for Client Execution	TA410 uses Royal Road RTF documents to compromise victims.
	T1559.001	Inter-Process Communication: Component Object Model	FlowCloud uses COM interfaces to schedule tasks and perform WMI queries.
	T1047	Windows Management Instrumentation	TA410 uses WMI for lateral movement and information gathering.
Persistence	T1053.005	Scheduled Task/Job: Scheduled Task	FlowCloud creates a scheduled task for persistence.
	T1505.003	Server Software Component: Web Shell	TA410 plants webshells on vulnerable web servers.
	T1543.003	Create or Modify System Process: Windows Service	FlowCloud can be configured to create a service for persistence.
Defense Evasion	T1027	Obfuscated Files or Information	FlowCloud files are distributed and stored in encrypted form.
	T1036.004	Masquerading: Masquerade Task or Service	The driver component of FlowCloud masquerades as a mouse driver service.
	T1036.005	Masquerading: Match Legitimate Name or Location	Files named after legitimate utilities are written into the %ProgramFiles%MSBuildMicrosoftExpressionBlendmsole subdirectory.
	T1014	Rootkit	FlowCloud uses a rootkit to hide its network traffic and processes from system utilities.
	T1055.001	Process Injection: Dynamic-link Library Injection	FlowCloud uses both regular and reflective DLL injection. It also manually loads some DLLs, bypassing calls to LoadLibrary.
	T1055	Process Injection	TA410’s backdoors perform process injection to masquerade as harmless processes.
	T1055.003	Process Injection: Thread Execution Hijacking	One of FlowCloud’s DLLs replaces instructions in the loading process to make it execute code written in its memory.
	T1055.012	Process Injection: Process Hollowing	FlowCloud uses module stomping to hide the loading of its main backdoor.
	T1140	Deobfuscate/Decode Files or Information	Multiple TA410 backdoors communicate with their C&C through encrypted and obfuscated channels.
	T1574.002	Hijack Execution Flow: DLL Side-Loading	FlowCloud uses DLL Side-Loading to launch its second-stage dropper.
	T1497	Virtualization/Sandbox Evasion	Some versions of FlowCloud use the Pafish utility to detect virtualization, sandboxes, and debuggers.
	T1134.002	Access Token Manipulation: Create Process with Token	FlowCloud can create processes using tokens acquired from legitimate processes.
	T1070.004	Indicator Removal on Host: File Deletion	FlowCloud deletes its rootkit’s executable after launching it.
	T1070.006	Indicator Removal on Host: Timestomp	FlowCloud backdates some files and services to 2013.
Discovery	T1010	Application Window Discovery	When logging mouse events, FlowCloud gathers information about the application running in the foreground.
	T1057	Process Discovery	Multiple TA410 backdoors can list running processes.
	T1518	Software Discovery	FlowCloud uses the IShellAppManager COM object to list installed software.
	T1083	File and Directory Discovery	FlowCloud can search through connected file systems and obtain directory listings.
	T1120	Peripheral Device Discovery	FlowCloud can list connected camera devices.
	T1016	System Network Configuration Discovery	FlowCloud can discover and use locally configured proxies.
	T1012	Query Registry	FlowCloud components use registry keys to signal each other.
	T1115	Clipboard Data	FlowCloud registers a listener to steal clipboard data when it is changed.
Collection	T1056	Input Capture	FlowCloud logs mouse clicks.
	T1056.001	Input Capture: Keylogging	FlowCloud records keystrokes.
	T1113	Screen Capture	FlowCloud takes screenshots at regular intervals.
	T1125	Video Capture	FlowCloud uses OpenCV to take pictures using connected camera devices.
	T1123	Audio Capture	FlowCloud has audio capture functionality.
	T1119	Automated Collection	FlowCloud automatically collects data based on timers and events.
	T1074.001	Data Staged: Local Data Staging	FlowCloud stores collected data in local SQLite databases prior to exfiltration.
	T1005	Data from Local System	FlowCloud can exfiltrate files from local file systems.
	T1025	Data from Removable Media	FlowCloud can exfiltrate files from removable drives.
	T1560.002	Archive Collected Data: Archive via Library	FlowCloud and LookBack use a statically linked zlib library to compress data.
	T1560.003	Archive Collected Data: Archive via Custom Method	FlowCloud compresses some collected data by removing duplicates and similar screen captures.
Command And Control	T1071.001	Application Layer Protocol: Web Protocols	LookBack and FlowCloud can send and receive data over HTTP.
	T1095	Non-Application Layer Protocol	LookBack can communicate over raw TCP sockets.
	T1132.001	Data Encoding: Standard Encoding	FlowCloud uses Protobuf to encode C&C commands and configuration.
	T1132.002	Data Encoding: Non-Standard Encoding	LookBack encodes binary data using a custom hex-encoding method.
	T1573.001	Encrypted Channel: Symmetric Cryptography	FlowCloud can use XOR, TEA, RC4 and a modified AES algorithm to encrypt traffic and files.
Exfiltration	T1030	Data Transfer Size Limits	FlowCloud uses local caches to stage data and exfiltrates their content when it reaches a size specified in its configuration.
Impact	T1529	System Shutdown/Reboot	FlowCloud can force a system crash or shutdown.