FlowCloud Version 4.1.3 Malware Analysis

FlowCloud Version 4.1.3 Malware Analysis

Share with your network!

Proofpoint researchers are continuing to track the threat actor TA410’s use of FlowCloud, a remote access trojan (RAT). Below is a new in-depth analysis of another version of the FlowCloud RAT, version 4.1.3. While we do not have many campaign details or targeting information on this particular sample, this is another version of FlowCloud in the wild. Earlier this week we provided an analysis of version 5.0.1, which was used during the targeting of critical U.S. utility providers last year.

It is currently unclear which of the versions is the “newer one” or if there are distinct variants of FlowCloud being used for different purposes. The version we previously detailed had an older compilation date (December 15, 2018 – it is unclear whether the date is forged), but a newer internal version (5.0.1) than the sample discussed here.

One major difference between the two is that version 5.0.1 is written in C++ using extensive object-oriented programing, Boost library, and a C++ implementation of Protocol buffers—version 4.1.3 was written in C without any object-oriented techniques and used a C implementation of Protocol buffers. Version 5.0.1 also makes use of SHA512, a modified (or broken) AES, and TEA algorithms instead of the MD5 and RC4 as described below. In general, version 5.0.1 was a larger and more difficult malware to reverse engineer. 

FlowCloud has typical RAT functionality such as access to the filesystem, processes, and services, screenshots, keylogging, command shell, and added functionality via plugins. It also includes port mapping and Nmap port scanning to help facilitate lateral movement. Although the additional functionality was not implemented in the analyzed sample below, there are indicators in the code and configuration data that suggests support for audio recording, clipboard stealing, and exfiltrating files based on specific search criteria such as file type and name pattern. These might be implemented via FlowCloud’s plugin mechanism or may be present in other versions of the malware.

In this blog post we will analyze the following FlowCloud sample:

SHA256

b75e1391fcb558e42cc05399fa716829114323e1d01aa284445955548302d71f

Per its metadata, it is version 4.1.3 and was compiled on March 21, 2019 (it is unclear whether the date is forged). It was recently uploaded to VirusTotal on May 12, 2020 by a submitter from Taiwan. At the time of research, the command and control (C&C) server (114.55.109[.]199) was still active.

Naming 

The name “FlowCloud” comes from a debugging string left in one of the earlier samples we found: 

g:\FlowCloud\trunk\Dev\src\fcClient\Release\fcClientDll.pdb 

The name was also used in the configuration data of the sample analyzed for this blog post as the “product_name”: 

1 (product_name): "flowcloud" 

2 (product_version): "v4.1.3" 

Protocol Buffers 

FlowCloud makes extensive use of a data structure known as Protocol buffers (“protobufs”) in its configuration and C&C communications. “Protocol buffers are Google's language-neutral, platform-neutral, extensible mechanism for serializing structured data – think XML, but smaller, faster, and simpler. You define how you want your data to be structured once, then you can use special generated source code to easily write and read your structured data to and from a variety of data streams and using a variety of languages.” 

As an example, in the analyzed sample, FlowCloud stores its configuration data as a 3344-byte serialized protobuf as shown in Figure 1: 

image-20200610171847-1

Figure 1 Configuration data serialized as a protobuf

Using the Protocol buffer compiler (“protoc”), the serialized data can be deserialized into a more human-readable format as shown in Figure 2: 

image-20200610171847-2

Figure 2 Configuration data that has been deserialized (truncated for readability)

To recover the names of the fields, the associated ProtobufCMessageDescriptor and ProtobufCFieldDescriptor structures can be identified as shown in Figure 3: 

image-20200610171847-3

Figure 3 Configuration data’s associated ProtobufCMessageDescriptor

We have included an IDA Pro Python script on our GitHub that can be used to parse and display some of the important fields of these structures as shown in Figure 4: 

image-20200610171847-4

Figure 4 Parsed ProtobufCMessageDescriptor and ProtobufCFieldDescriptor (truncated for readability)

The “id” numbers from the structures can be matched with the deserialized data for labeling as shown in Figure 5: 

image-20200610171847-5

Figure 5 Labeled protobuf for configuration data (truncated for readability)

The ProtobufCMessageDescriptor structure also starts with magic bytes (e.g. 0x28aaeef9), so these can be used to identify all the protobufs compiled into the malware. In the analyzed sample there were 78 protobufs included. 

Configuration 

In the analyzed sample, a working directory was setup in: 

C:\Windows\Fonts\zitbee.fon\ 

The fully labeled configuration data is available on our GitHub . Most of its fields are self-identifying and include things such as: 

  • C&C addresses (e.g. “exchange_server”)
  • C&C ports (e.g. “exchange_server_port”)
  • Encryption keys (e.g. “xchg_server_key”)
  • Various installation options (e.g. “install_config”)
  • Various command options (e.g. “keyboard_policy”)

The configuration data is also stored as a serialized protobuf and encrypted in a “winver.dat” file. It is encrypted using a basic XOR and addition algorithm. We have included a Python script that can be used to decrypt this config file on our GitHub 

Dependencies 

FlowCloud uses HTTP to download some dependencies from its C&C server (“exchange_server: exchange_server_port+1” from the config). Figure 6 shows an example:

image-20200610171847-6

Figure 6 Example dependency download

The URIs are hardcoded into the sample. The response data starts with an encrypted 16-byte header: 

  • Header key (DWORD)
  • CRC32 checksum (DWORD)
  • Decrypted/decompressed data length (DWORD)
  • Encrypted/compressed data length (DWORD)

The header key is used with some XOR and ROR operations to decrypt the remaining bytes of the header. 

After the header there is RC4 encrypted data. The RC4 key is generated by taking a hardcoded string (e.g. “y983nfdicu3j2dcn09wur9*^&(y4r3inf;'fdskaf'SKF”) and hashing its hex digest 1000 times with MD5. 

The decrypted data starts with another 16-byte header as described above. The data that follows this inner header is ZLIB compressed and once decompressed contains a PE file. 

The downloaded dependencies include: 

  • /SL3716/S8437AEB.DAT - SQLite
  • /WC413/21FB9FCF.DAT - Nmap
  • /WC413/6EE2EFF7.DAT - Packet.dll (used with Nmap)
  • /WC413/67B1B02F.DAT - wpcap.dll (used with Nmap)

We have included a Python script on our GitHub that can be used to decrypt these dependencies. 

Command and Control 

C&C uses a binary protocol over TCP to “exchange_server:exchange_server_port” from the config. An example exchange is shown in Figure 7: 

image-20200610171847-7

Figure 7 Example C&C exchange

Both requests and responses are structured similarly. They start with a 28-byte header called “HHDR”: 

  • Header key (DWORD)
  • CRC32 checksum (DWORD)
  • “HHDR” (DWORD)
  • Unknown counter (DWORD)
  • Unknown hardcoded 1 (DWORD)
  • Data length (DWORD)
  • Unknown hardcoded 1 (BYTE)
  • Hash type (BYTE)
    • 1 is MD5 
  • Compression type (BYTE)
    • 1 is ZLIB
  • Crypto type (BYTE)
    • 2 is RC4 

The header key is used with some XOR and ROR operations to decrypt the remaining bytes of the header.

Following “HHDR” is a 24-byte header called “HCMD”: 

  • Header key (DWORD) 
  • CRC32 checksum (DWORD) 
  • “HCMD” (DWORD) 
  • Command (DWORD) 
  • Subcommand (DWORD)
  • Data length (DWORD) 

The header key is used with some XOR and ROR operations to decrypt the remaining bytes of the header. 

Following the “HCMD” header is a 16-byte header as described above in the “Dependencies” section. 

After the third header there is RC4 encrypted data. The RC4 key for this data is generated by taking the “xchg_server_key” from the config and hashing its hex digest one time with MD5. 

Once the data is decrypted there is a final 16-byte header and ZLIB compressed data (see the “Dependencies” section above). 

We have included a Python script on our GitHub  that can be used to decrypt these requests or responses. Figure 8 is an example output of our script: 

image-20200610171847-8

Figure 8 Example parsing of a C&C request

 The decrypted data is a serialized protobuf. For example, the names of the protobufs involved with command 1 subcommand 2 are: 

  • FcNet__MsgUsr 
  • FcNet__MsgUsr__System 
  • FcNet__MsgUsr__System__Adapter 

This command is used to send various system information to the C&C server as shown in Figure 9: 

image-20200610171847-9

Figure 9 Labeled protobuf for command 1 subcommand 2 (edited for privacy)

C&C Commands 

We have identified the following commands that can be executed via C&C command polls: 

  • Command 2 – filesystem related
    • Subcommand 0 - get drive information
    • 1 - get directory listing
    • 2 - create directory
    • 3 - rename directory
    • 4 - write file
    • 5 - read file
    • 6 - remove directory
    • 7 - get file attributes
    • 8 - set file attributes and times
    • 9 - add file to "filemgr" list (see below)
    • 10 - search directory for files with a given file name pattern
    • 11 - ShellExecute "open" file with arguments
    • 12 - add directory to "folderimage" list (see below) 
  • 3 – take a screenshot 
  • 5 – Exfiltrate data related (see below)
    • 0 - get exfiltrate data size
    • 1 - get exfiltrate data file count
    • 2 - get exfiltrate data item list
    • 3 - change status of exfiltrate data 
  • 6 – process related
    • ​​​​​​​0 - get process list
    • 1 - kill process 
  • 7 – service related
    • ​​​​​​​0 - get service list
    • 1 - start service
    • 2 - stop service
    • 3 - delete service
    • 4 - set service start type 
  • 9 – system related
    • ​​​​​​​0 - get installed software
    • 4097 – reboot
    • 4098 – reboot
    • 4099 – NtRaiseHardError
    • 4100 – copy %SYSTEM%\winver.exe to %WIN%\System\winver.exe then NtRaiseHardError 
  • 10 – cmd.exe command shell
    • ​​​​​​​4097 – write command to shell 
  • 11 – lateral movement related
    • ​​​​​​​4097 - setup port mapping using https://github.com/windworst/LCX
    • 4098 - remove port mapping
    • 4099 - get port mappings
    • 8193 - start Nmap scan
    • 8194 - replies with "Unsupported yet."
    • 8195 - get Nmap scan results 

Data Exfiltration Managers 

In addition to the C&C commands, FlowCloud has some additional functionality organized as “data exfiltration managers" that include: 

  • “filemgr” – exfiltrate files as specified by a C&C command 
  • “folderimage” – exfiltrate directories as specified by a C&C command 
  • “screen” - exfiltrate screenshots 
  • “keylog” - exfiltrate keylogging data
    • ​​​​​​​Keylogging data is gathered by an external program and sent to FlowCloud via a named pipe (e.g. “\\.\pipe\namedpipe_keymousespy_english”)
  • ​​​​​​​“audio” - possibly audio recording
    • ​​​​​​​The config and code hint at this functionality, but it is not implemented in the analyzed sample
  • ​​​​​​​“smtfile” - possibly search for and exfiltrate files based on file types and name patterns
    • ​​​​​​​The config and code hint at this functionality, but it is not implemented in the analyzed sample
  • ​​​​​​​“plugin” - download and execute additional plugins
    • ​​​​​​​PE file exports associated with plugins:
      • ​​​​​​​“pluginInfo”
      • “startModule”
      • “setOtherInterface2”
  • “clipboard” - possibly steal clipboard contents
    • ​​​​​​​​​​​​​​The config and code hint at this functionality, but it is not implemented in the analyzed sample 

These exfiltration managers run in their own execution threads and some are controlled by “policies” in the config. They store their data in various SQLite databases and then another execution thread will eventually exfiltrate the data to the C&C server. 

As an example, the “screen” exfiltration manager takes continuous screenshots according to its “screen_policy”: 

  • state – is policy active 
  • cycle_time – sleep time between screenshots 
  • cache_count – maximum number of screenshots waiting to be exfiltrated 
  • bit_depth – bit depth of screenshot 

A screenshot is taken. Depending on its size, the data may be broken up into chunks. The data is then compressed with ZLIB and encrypted with RC4 (uses “file_key” from config). As described above, 16-byte encrypted headers are attached to the compressed and encrypted data. 

Two additional headers are prepended to the compressed and encrypted data. They are encrypted similarly to the 16-byte, 28-byte, and 24-byte headers above. The first header is 96-bytes: 

  • Header key (DWORD)
  • CRC32 checksum of header (DWORD)
  • CRC32 checksum of data (DWORD)
  • Product name (16-bytes)
  • Product version (16-bytes)
  • Unknown hardcoded 1 (DWORD)
  • Timestamp (QWORD)
  • File attributes (DWORD)
  • Data length (QWORD)
  • Creation time (QWORD)
  • Last access time (QWORD)
  • Last write time (QWORD)
  • Length of the next header (DWORD)

The second header is at least 24-bytes, but its length depends on the number of data chunks and length of a filename: 

  • Header key (DWORD)
  • CRC32 checksum of header (DWORD)
  • Header length (DWORD)
  • Offset to end of chunk list (DWORD)
  • Offset to start of chunk list (DWORD)
  • Number of chunks (DWORD)
  • File name and chunk list (variable length)

The encrypted screenshot data is then saved to a SQLite database. In the analyzed sample this was stored in the file “data\E70EEF62”. We have included an example of the schema used on our GitHub, but it basically consists of a “file” table to store metadata about the data to exfiltrate and a “file_data” table that stores the data. 

Periodically a separate execution thread will go through the SQLite databases created by the exfiltration managers and send the data to the C&C server. It uses the same C&C protocol as described above, but using the “file_server,” “file_server_port,” and “file_server_key” values from the config. 

The Proofpoint threat research team analyzed and performed reverse engineering on a recently discovered version (4.1.3) of the FlowCloud RAT. While the version that we analyzed is for Windows only, we believe that there may be additional variants. One piece of evidence that may support the theory that there are additional FlowCloud variants, is the “plateform” (sic) field detailed in Figure 9 above. This is an enumerated data type that can have the following values: 

  • FC_NET__USR_LIST__USR__SYSTEM__PLATEFORM_TYPE__WINDOWS
  • FC_NET__USR_LIST__USR__SYSTEM__PLATEFORM_TYPE__LINUX
  • FC_NET__USR_LIST__USR__SYSTEM__PLATEFORM_TYPE__MAC
  • FC_NET__USR_LIST__USR__SYSTEM__PLATEFORM_TYPE__ANDROID 

While we have only seen versions of FlowCloud for Windows, this implies there may be other implementations of FlowCloud for other operating systems. 

ET and ETPRO Suricata/SNORT Signatures

2842895 - ETPRO MALWARE FlowCloud Dependency Download M1

2842896 - ETPRO MALWARE FlowCloud Dependency Download M2

2842897 - ETPRO MALWARE FlowCloud Dependency Download M3

2842898 - ETPRO MALWARE FlowCloud Dependency Download M4