The Approach of TA413 for Tibetan Targets

12 minute read


This attack chain begins with the victim receiving a malicious RTF file through a phishing attack. When the victim opens the RTF file, it contains a hidden encoded file which is then decoded and executed using a shellcode. The executed file then performs process hollowing, injecting itself into the rundll32.dll process and establishing a connection with the attacker’s command and control (C2) server.


Once connected to the C2 server, the infected machine begins sending data about itself to the attacker, who can then use this information to send further modules and commands to the infected machine.

Technical analysis

During our analysis, we collected some important information about the document file in question. By utilizing VirusTotal to scan the file’s hash, we were able to detect that the file is a RTF document that has been flagged by 34 different security solutions. Further analysis revealed that the RTF document exploits several known vulnerabilities, including CVE-2017-11882, CVE-2017-8759, CVE-2018-0802, and CVE-2018-0798.


Using the tool rtfobj, we were able to extract multiple objects from the RTF document. Upon examining these objects, we identified an exploit code. exploit code equation drop encode payload on temp folder Temp\ghb4nrwmp.wmf. After deconding dropped file, it executed to reliver second stage.


Further investigation revealed that the RTF document is related to the Royal Road.

Royal Road: It is known for its use of weaponized Microsoft Office documents to deliver payloads, including ransomware and other malicious software. The documents often exploit vulnerabilities in software such as Adobe Reader or Microsoft Office to execute the payload without the user’s knowledge.

RoyalRoad has been used in various campaigns targeting individuals and organizations around the world. It has been observed being delivered through spam emails, exploit kits, and other methods. Once the payload is delivered and executed, it may perform various malicious actions such as encrypting files, stealing sensitive information, and installing other malware.

During our analysis, we utilized the rr_decoder tool to decode the second stage payload of the RoyalRoad malware, which was named “ghb4nrwmp.wmf”. The results of the decoding are shown in the figure below.

$python3 sample_ghb4nrwmp.wmf second_stage.exe

  • [!] Type [b2a66dff] is Detected!
  • [+] Decoding…
  • [!] Complete!

second stage

Upon decoding the second stage payload of the RoyalRoad malware, second stage is packed. so we identified that it utilized the VirtualAlloc function multiple times to allocate a region of memory in which to copy shellcode. Upon transferring execution to the shellcode, we observed the use of obfuscation techniques such as stack strings to obscure the names of APIs. Further analysis revealed that the shellcode used the “LoadLibraryA” and “GetProcAddress” functions to resolve and locate APIs necessary for injecting the third stage of the malware into the “rundll.dll” process.

In order to understand the injection process used by the RoyalRoad, we analyzed the behavior of the payload and identified the following steps:

  • The malware utilizes the VirtualAlloc function to copy shellcode into a region of memory.
  • The shellcode uses stack strings to obscure the commandline.
  • The CreateProcA function is used to create a process in a suspended state (0x4) rundll32.dll.
  • A handle to the target process is obtained to allocate a region of memory on it using VirtualAllocEx.
  • The third stage of the malware is copied into the target process using WriteProcessMemory`.
  • The third stage is executed using the ResumeThread function.

From the previous steps, we can identif that second stage used process hollowing to inject third stage into rundll.dll and excute it using this commandline

  • C:\Windows\system32\rundll32.exe"shell32.dll,Control_RunDLL

thrid stage

The third stage of the malware is developed in C and functions as a backdoor to collect information about the infected system and send it to the attacker. If the attacker determines that the infected system is of interest, they may choose to drop the next stage of the malware.


Upon analysis of the malware, it was observed that the malware creates a mutex with the identifier “552FFA80-3393-423d-8671-7BA046BB5906.” This mutex is also used as the malware’s campaign name, as shown in the following figure.



The malware is equipped with a capability to encrypt strings using a simple XOR algorithm. This function was used by the malware to decrypt APIs into runtime in order to evade detection by static analysis tools. The malware also loaded 4 libraries into runtime using this technique. It is worth noting that different keys were used to decrypt the APIs and the libraries.


The keys used for decryption are as follows:

Key for decrypting APIs : cffb9895f0dcddca9e8befc4aee9b1bf (in hex)
Key for decrypting libraries: bf8a87e415cebb95aaf991b08ec486a4 (in hex)

After decrypting the APIs, the malware was able to utilize the GetProcAddress function to resolve the APIs and load the libraries using LoadLibraryA. This allowed the malware to execute its desired functions at runtime and we can include laoded libraries.

  • ws2_32.dll
  • ntdll.dll!
  • advapi32.dll

we can see our script to decrypted encrypted strings.

def unhex(hex_string):
    import binascii
    if type(hex_string) == str:
        return binascii.unhexlify(hex_string.encode('utf-8'))
        return binascii.unhexlify(hex_string)
def tohex(data):
    import binascii
    if type(data) == str:
        return binascii.hexlify(data.encode('utf-8'))
        return binascii.hexlify(data)
out = []
data = unhex("c8f8b7b822f993f6ce9c9b")
key = unhex("bf8a87e415cebb95aaf991b08ec486a4")

for i in range(0, len(data)):
    out.append(i ^ data[i] ^ key[i & 15])


collecting sensitive information

function appears to be designed to gather and encode various system information. It does this by first decrypting several strings using the mw_decrypt_strings function. These strings are likely API names or other relevant information that is used later in the function.

The function then calls one of the decrypted functions (either GetNativeSystemInfo or GetSystemInfo) to retrieve system information and stores it in an array called system_info. This information may include details such as the system’s processor, memory, and operating system.

The function then encodes this information, as well as the hostname and username, using the mw_base64_encode function. The encoded strings are then concatenated into a single string.

collected information:

  • Username
  • Process name and Process ID
  • IP Address
  • Hostname


Evade Detection

After gathering and encoding data, the malware appears to use the LZF compression algorithm to compress the data further. It then applies an XOR operation with the value 0x2b to encrypt each element of the compressed data before encoding it again using the base64 encoding method. This process may be used to reduce the size of the data for easier transmission.


Establish a connection

Malware establish a connection with the server over a socket, so malware call htons to ensure that the data is correctly interpreted by the receiving system then call

  • mw_create_listen: to create a socket that can listen for incoming connections.
  • mw_send_socket_connection: to be used to send a socket connection request to a server.
  • mw_establishing_connection_server: to be used to establish a connection with a server.


implemention of a simple HTTP

The malware appears to have implemented a simple HTTP client that can send HTTP requests to a server and receive responses. The process begins by extracting the hostname and port number for the connection. A socket is then created and a connection is established with the server.

The malware then constructs an HTTP request using the following format: “CONNECT %s:%d HTTP/1.1\r\nProxy-Connection: Keep-Alive\r\nContent-Length: 0\r\nHost: %s\r\nUser-Agent: %s\r\n”. The request is then sent to the server and a response is received. It is not clear how the response is processed or what the purpose of the request is.


Encryption data with AES

After establishing a connection with the server, the malware appears to be utilizing the AES algorithm to encrypt data before sending it to the server. It uses a ransom key as the initial key for the encryption process and then receives a key from the server to encrypt the data again


c2 response

malware appears to use a specific method for receiving encrypted data from the server and decrypting it. This data is likely to be modules or commands that are used for specific tasks. The decryption process is reversing method that was used to encrypt the data, which includes:

  • LZF compression
  • XORing with 0x2b
  • Base64 encoding
  • AES encryption with a randomly generated key
  • AES encryption with a key derived from the XOR of the Client, Server Random Bytes Key


malware checkes the header of response with “PK” and receive also one commands or more and we can see the commands in the next figure.

  • Command 2000: which used to decode using base64, decrypt, with 0x2b key and decompress uing LZF.


We can see a table of commands

No. command info
1 2000 which used to decode using base64, decrypt, with 0x2b key and decompress uing LZF
2 2001 clear the command of data
3 2002 set communication delay time
4 2003 exit command loop
5 2004 break connection
6 2005 load module from attaker into memory
7 2006 run module
8 default listen for proxy connection

Analysis Infrastructure

  • It appears that the hostname “” is associated with the domain “VULTRUSERCONTENT.COM” and is hosted by the cloud provider Vultr. The host is located in Japan, specifically in the city of Ōi. The organization responsible for the host is Vultr Holdings, LLC, and the ISP is The Constant Company, LLC. The ASN associated with the host is AS20473. It is important to note that the presence of a host or domain on a cloud provider does not necessarily indicate malicious activity.

  • The network and AS are likely used by the malware for communication with its command and control (C2).

Classification and attribution

Attribution refers to the process of identifying the source of a cyber attack or threat. It is often difficult to accurately attribute cyber attacks to a specific country, as attackers often use various tactics to hide their identity and location. There are a number of factors that can be used to help attribute a cyber attack to a specific country, including:

Victimology: This refers to the characteristics of the victims of the attack, such as the type of organization or industry they belong to. If a group of attacks all target organizations in a specific country, it can be a strong indication that the attacks are coming from that country.

Infrastructure: If a group of attacks all use the same infrastructure, such as a specific set of servers or domain names, this can be used to help attribute the attacks to a specific country or group.

Tactics, Techniques, and Procedures (TTPs): The specific tactics and techniques used in an attack can often be used to identify the group or country behind the attack.

Malware used: The type of malware used in an attack can often be used to attribute the attack to a specific group or country.

A spreadsheet targeting a Tibetan organization was used and a domain, tibet[.]bet, was attributed to the TA413 group for the attack. ansd we can see that in the next figure.


In this particular case, TA413 are known to have impersonated the “Department of Religion & Culture.” This type of social engineering tactic is often used to trick individuals into revealing sensitive information or downloading malware.


ideas how to track activity of this tool:

  • Set up a YARA rule to identify the RTF version of the Royal Road tool or any associated indicators of compromise (IOCs). This can be done by analyzing the characteristics of the RTF file, such as specific strings of code or patterns of behavior, and creating a rule that matches these characteristics.

  • Use YARA to scan your network for any instances of the RTF version of the Royal Road tool or associated IOCs. This can be done by running YARA on a schedule, such as daily or weekly, or in real-time as part of a threat hunting process.

  • When YARA detects a match, conduct further investigation to determine the scope and impact of the RTF version of the Royal Road tool on your network. This may involve analyzing network traffic, examining system logs, and performing forensic analysis on affected systems.

  • Take appropriate remediation steps to remove the RTF version of the Royal Road tool from your network and secure any affected systems. This may involve isolating infected systems, patching vulnerabilities, and implementing additional security measures to prevent future attacks.

  • Use threat intelligence sources to stay informed about the latest tactics and techniques used by APT groups, including those that use the RTF version of the Royal Road tool. This can help you stay ahead of potential threats and better defend your network.



Yara Rule

rule lowzero_malware: lowzero
	description = "Detect_lowzero_malware"
        author = "@malgamy12"
	date = "2022/12/26"
	license = "DRL 1.1"
        hash = "de44e5f6cfac9cd3e61194efd5c2b20ba44c437a520fe7018ed7f623e66f8131"

        $pdb = "Proxy-Authorization: NTLM " ascii
        $op = {8B C1 8D 14 39 83 E0 ?? 8A 44 05 ?? 32 04 16 32 C1 41 88 02 3B CB}
        uint16(0) == 0x5A4D and all of them


Frist stage

  • 9681ef910820d553e4cd54286f8893850a3a57a29df7114c6a6b0d89362ff326

second stage

  • 028e07fa88736f405d24f0d465bc789c3bcbbc9278effb3b1b73653847e86cf8

third stage

  • de44e5f6cfac9cd3e61194efd5c2b20ba44c437a520fe7018ed7f623e66f8131





ip addresses





  • 0b30433bb80abd4b1978fa84d953c13f4d7b726cd533e3c50cef36b4e79f2d2e
  • cfc72b48732286a2beab5d0fc60aabc8d529faf4d0fb262b99a092096a187dc0
  • 1351dca77922b22ab5dae0689550cb55807900348a42b5dc71b01a5a78602b0f
  • 9681ef910820d553e4cd54286f8893850a3a57a29df7114c6a6b0d89362ff326
  • ba2c89192643f05e64f49b5cb3513a6a5bbfa719225af3b72c83587b8b774e8d
  • d987e80a23f334c5eb50c9883a6b5b1b2090230f950fa5eb7cec0a2d74f5271b
  • 3a69c1453b8062620837ab32be68ed871df383e24e68161839508a98bf7033b8
  • c0fc6a2ba864650af25b9da8e70396cdb40e8a196f7f0ce6024ff67a080346dc
  • c44be5ed5c4bec2be72ce9737bde5a2d48fe5fb0ea235ddc61ba447b26642949
  • c8934c7b3187e48b1ee44fc2c8e1c3ab19850efc1e45383442cfe4b9b4a06d01
  • 9b79fbbc895ca98b951aecd664cdd7ce69f63901996c7341a560d7c207a143ea
  • 65bddf8148ed60f5625b3495baba0824d2fcd13a710494817c7a84e0062ce227
  • 1120275dc25bc9a7b3e078138c7240fbf26c91890d829e51d9fa837fe90237ed
  • 4f941e1203bf7c1cb3ec93d42792f7f971f8ec923d11017902481ccf42efaf75
  • 67458476cc289f7d0f0bda8938f959b8a1a515e23f37c9d16452b2e1d8adf5a4
  • 7d9e22ae60cb85c4dbdceac46d33fc080b89df23607ab4904b3795d9a9765b82
  • c83c28add56ec8cad23a14155d5d3d082a1166c64ea5b7432e0acaa728231165
  • b7bebe92a5802aa922e5719c948e35716f908e67701cfffaeebfcadc7a6e650a
  • 0eb7ba6457367f8f5f917f37ebbf1e7ccf0e971557dbe5d7547e49d129ac0e98