TigerRAT – Advanced Adversaries on the Prowl

This article was written by Scott Knight

Summary

On September 5th, 2021, the Korea Internet & Security Agency (KISA) released a report on a new threat they dubbed TigerRAT. The newly found malware shares similarities with malware previously reported by Kaspersky and Malwarebytes. Kaspersky has previously attributed those malware samples to Andariel, a threat actor group the Korean Financial Security Institute has identified as being a sub-group of Lazarus. TigerRAT appears to have been used from late 2020 onwards.

VMware’s Threat Analysis Unit identifies TigerRAT as a payload associated with broader campaign of attacks against target enterprises. The TigerRAT payload capability includes the ability to manipulate files, execute remote commands, log keystrokes and remotely view and control the screen. TigerRAT may be blocked by VMware Carbon Black (see Figure 8).

Notably this malware, and the overall attack, originates from a loader application that utilizes a unique approach to storing the payload. Within the TigerRAT sample, configuration data for Command and Control (C2) communications is stored encrypted within the malware, and communications with the C2 server are customized to appear like HTTP web traffic.

VMware’s Threat Analysis Unit performed a deep analysis of the TigerRAT malware to document its internal operations for comparison to other malware families in the wild.

When considering how TigerRAT may be used in the wild, defenders should recognize that the TigerRAT malware will be used by attackers as part of a broader campaign of attacks and that along the kill-chain, a wide variety of other malware types and attack techniques are also likely to be used. This is a key point when evaluating how such campaigns can be detected and disrupted.

Loader

Loader structure

In the case of sample , the TigerRAT payload data is stored in a section named “data”. The payload structure is a 4-byte size, a 16-byte key, and then base64 encoded data. The size is the total length of the base64 data.

The screenshot below (Figure 1) shows the size in red, the decryption key in green, and the base64 data in blue.

Figure 1: Loader

Loader function

The Loader’s purpose is to decrypt the final TigerRAT payload and execute it in memory. The data is loaded, base64 decoded and then the 16-byte key is used to decrypt the data with a simple XOR. The decoded payload is a PE file and after decrypting the loader will jump to the entry point.

Variance of loaders in the wild

The loader sample Malwarebytes reported on had almost identical code to that analyzed here, with the notable difference being that the base64 data was stored as overlay data after all the regular PE data. The embedded payload in the Malware bytes sample also differed. Refer to the Malwarebytes post for additional detail.

TigerRAT

The embedded PE is referred to as TigerRAT by the KISA report. A handful of different samples were found with compilation dates ranging from the end of 2020 to the beginning of 2021, with the only notable differences between different samples being the encrypted C2 information, and the DES/RC4 keys used for encryption and decryption.

The malware is written in C++ and makes use of only a handful of classes. At startup, a main class is created with references to the classes below.

Table 1: TigerRAT classes

All of the Module classes inherit from a common base class and the main class stores an array of Module instances that are used during C2 communication. The code makes heavy use of threading when running actions based on C2 commands.

C2 Communication

During the main class initialization, the C2 IP addresses are decrypted using the CryptorDES class and stored in the main class. When that initialization is finished, the malware then attempts to initiate the network connection to the C2 server. The malware first tries to connect to one of the decrypted C2 IP addresses on port 443 and then performs a handshake with the C2 server. The malware starts by sending HTTP 1.1 /index.php?member=sbi2009 SSL3.3.7\x00 and then the C2 server responds with HTTP 1.1 200 OK SSL2.1\x00.

Following a successful initial handshake, the malware sends a 16-byte hash of the RC4 key being used and expects to get back a hardcoded 7-byte value. In the case of all currently found samples, the malware expects the 7-byte value “xPPygOn”.

The handshake process can be seen from the perspective of the C2 server by running a mockc2 TigerRAT server (Figure 2).

Figure 2: TigerRAT handshake

After the handshake process has been completed successfully, the malware will proceed to send all further data in a standard command format and encrypted using the CryptorRC4 class. A single 32-byte RC4 key is used to initialize two separate running RC4 ciphers. One is used to decrypt incoming traffic and the other is used to encrypt outgoing traffic. The encrypted traffic has the following format (Figure 3):

Figure 3: Encrypted traffic structure

Once decrypted the command format is as follows (Figure 4):

Figure 4: Command structure

After the handshake, the malware sends to the C2 server a unique victim machine identifier previously generated by the IDGeneratorAdapter class. The unique ID is generated by calling the GetAdaptersInfo API and getting the hardware address for one of the network devices on the victim machine (Figure 5).

Figure 5: TigerRAT victim ID

After the handshake process and upload of the victim ID, the malware initiates  a heartbeat thread to send periodic packets to the C2 server, as well as a receive thread to read and process commands sent back from the C2 server. The subsequent actions of the malware will depend on the commands received from the C2 server; refer “Commands”. An example of a heartbeat command can be seen below (Figure 6):

Figure 6: TigerRAT heartbeat

Commands
Each Module class has a unique ID associated with it. This ID is set in the command structure sent from the C2 server down to the malware. The complete list of Module IDs can be seen below:

Table 2: Module IDs

The following tables list the various opcodes used by the different Module classes and their function.

ModuleUpdate

Table 3: ModuleUpdate opcodes

ModuleInformation

Table 4: ModuleInformation opcodes

ModuleShell

Table 5: ModuleShell opcodes

ModuleFileManager

Table 6: ModuleFileManager opcodes

ModuleKeyLogger

Table 7: ModuleKeyLogger opcodes

ModuleSocksTunnel

Table 8: ModuleSocksTunnel opcodes

ModuleScreenCapture

Table 9: ModuleScreenCapture opcodes

ModulePortForwarder

Table 10: ModulePortForwarder opcodes

Detection and Blocking

The TigerRAT malware may be detected . Figure 7 below shows TigerRAT launching multiple command interpreters in response to simulated commands sent from the mock C2 server. VMware Carbon Black Cloud can be configured to block unknown software attempting to run command interpreters as seen in Figure 8 below.

Figure 7: Process tree of TigerRAT executing remote commands

Figure 8: VMware Carbon Black Cloud blocking execution on unknown application attempting to run a command interpreter

MITRE ATT&CK TIDs

Indicators of Compromise (IOCs)

Links

• https://twitter.com/heavyrain_89/status/1434696945268756481
• https://www.boho.or.kr/filedownload.do?attach_file_seq=3277&attach_file_id=EpF3277.pdf
• https://securelist.com/andariel-evolves-to-target-south-korea-with-ransomware/102811/
• https://blog.malwarebytes.com/threat-intelligence/2021/04/lazarus-apt-conceals-malicious-code-within-bmp-file-to-drop-its-rat/