Studying Donot Team

APT group called Donot Team (aka APT-C-35, SectorE02) has been active since at least 2012. The attackers hunt for confidential information and intellectual property. The hackers' targets include countries in South Asia, in particular, state sector of Pakistan. In 2019, we noticed their activity in Bangladesh, Thailand, India, Sri Lanka, the Philippines, and outside of Asia, in places like Argentina, the United Arab Emirates, and Great Britain.

For several months, we have been monitoring changes in the code of this group's malicious loaders. In this article, we will review one of the attack vectors, will talk about the loaders in more detail, and will touch upon the peculiarity of the network infrastructure.

Attack chain

At the early stage of infection, the victim receives an MS Word document in Office Open XML format. Even though we do not have clear evidence, we are sure that the initial penetration vector is a targeted phishing message with MS Office attachment. The document itself is not malicious, but it abuses the external elements autoloading capability to launch the next stage document.

The loaded fine is an RTF document exploiting vulnerability CVE-2018-0802 in Microsoft Equation. The main shellcode is preceded by a chain of intermediate ones, each decrypting the subsequent slice with a single-byte XOR with keys 0x90 and 0xCE.

The main shellcode performed the following actions:

• Uses a single-byte XOR with key 0x79 to decrypt binary data from file %TEMP%\one.
• Creates executable files C:\Windows\Tasks\Serviceflow.exe and C:\Windows\Tasks\sinter.exe. These are the group's malicious loaders. We will talk more about them later.
• Creates file C:\Windows\Tasks\S_An.dll, containing two bytes 0x90.
• Creates file C:\Windows\Tasks\A64.dll. Depending on the system bit capacity, this is a modified x64-bit or x86-bit version of UACMe utility escalating privileges in the system. In addition to bypassing UAC control, the library creates and launches BAT script %TEMP%\v.bat. The script will use the following commands to register one of the loaders created earlier as a service:

sc create ServiceTool displayname= "ServiceFill" binpath= "C:\Windows\Tasks\Serviceflow.exe" start= "auto"
sc start ServiceTool

• Creates and launches JScript script C:\Windows\Tasks\bin.js. Its task is to launch library A64.dll via RnMod export using rundll32.
• Creates shortcut WORDICON.lnk in the startup folder. Its task is to launch loader sinter.exe after system restart.
• Creates shortcut Support.lnk in the startup folder. Its task is to launch bin.js JScript script after system reboot.

So, at that stage there are two loaders with a firm foothold in the System. We will discuss their operation later on.

Lo2 loaders

Despite their classification, the trojans have different objectives. For instance, file Serviceflow.exe acts as a watchdog. It collects the following information about the system:

• Username
• Computer name
• Contents of \Program Files\ and \Program Files (x86)\
• OS version
• Data about the processor

The watchdog records the results in file log.txt. It also checks Windows\Tasks\ for files A64.dll and sinter.exe. If necessary, it downloads the files from control server skillsnew[.]top and launches them on behalf of the current user. The corresponding token is extracted from process winlogon.exe. Trojan sinter.exe lets the attackers know about the infection by sending a request to hxxps://mystrylust.pw/confirm.php, and sends the collected information about the system to skillsnew[.]top. Then, if the attackers are still interested in the victim's computer, the trojan obtains contents of customer.txt file at hxxp://docs.google.com/uc?id=1wUaESzjGT2fSuP_hOJMpqidyzqwu15sz&export=download. The file contains the name for control server car[.]drivethrough.top, with which the trojan communicates further. Downloaded files are placed in folder \AppData\Roaming\InStore\, and launched with task scheduler.

As a result of malicious loaders' activity, components of framework yty are inserted into the system, allowing the attackers to get more details about their victim, including files with a certain extension, intercepted input strings, list of processes, and screenshots. We will not discuss plugins in this article.

When we studied other similar samples, we found some paths and project names left in the debugging information including the following:

• D:\Soft\DevelopedCode_Last\BitDefenderTest\m0\New_Single_File\Lo2\SingleV2\Release\BinWork.pdb
• D:\Soft\DevelopedCode_Last\BitDefenderTest\m0\New_Single_File\Lo2\SingleV2_Task_Layout_NewICON\Release\BinWork.pdb
• D:\Soft\DevelopedCode_Last\BitDefenderTest\m0\New_Single_File\Lo2\SingleV2_Task_Layout_NewICON_N_Lnk\Release\BinWork.pdb
• D:\Soft\DevelopedCode_Last\BitDefenderTest\m0\New_Single_File\Lo2\SingleV3\Release\WorkFile.pdb
• D:\Soft\DevelopedCode_Last\BitDefenderTest\m0\Off\Off_New_Api\Release\C++\ConnectLink.pdb
• D:\Soft\DevelopedCode_Last\BitDefenderTest\m0\Off\Off_New_Api\Release\C++\TerBin.pdb
• D:\Soft\DevelopedCode_Last\BitDefenderTest\m0\yty 2.0 - With AES Chunks LOC FOR XP Just Bit-Change_Name\Release\TaskTool.pdb
• D:\Soft\DevelopedCode_Last\BitDefenderTest\yty 2.0 - With AES Chunks OFFS Just Bit\Release\C++\MsBuild.pdb
• D:\Soft\DevelopedCode_Last\yty 2.0\Release\C++\Setup.pdb

In addition to substring yty 2.0 connecting the trojans with the framework, we also noticed substring Lo2, which may be an abbreviation from Loader 2..

In loaders versions before mid-2018, all used strings were stored in the file in cleartext. In subsequent builds, the attackers started encrypting the strings. In different versions, the following changes were made to the algorithm:

• Since May 2018: reverse the string and encode with Base64
• Since April 2019: perform the previous actions twice.
• Since January 2019: encrypt the string with AES in CBC mode and encode with Base64. Sample of Python code for decryption:

import base64
from Cryptodome.Cipher import AES

aeskey = (0x23, 0xd4, 0x67, 0xad, 0x96, 0xc3, 0xd1, 0xa5, 0x23, 0x76, 0xae, 0x4e, 0xdd, 0xca, 0x13, 0x55)

def aes_decrypt(data, aeskey):
	iv = bytes(list(range(0, 16)))
	key = bytes(aeskey)
	aes = AES.new(key, AES.MODE_CBC, iv)
	return aes.decrypt(data).decode().strip('\x00')

def base64_aes_decrypt(data, aeskey):
	data = base64.b64decode(data)
	data = aes_decrypt(data, aeskey)
	return data

• Since June 2019: perform symbol-by-symbol circular subtraction with the set array of bytes, encode with UTF-8, and encode with Base64. Sample of Python code for decryption:

subgamma = (0x2d, 0x55, 0xf, 0x59, 0xf, 0xb, 0x60, 0x33, 0x29, 0x4e, 0x19, 0x3e, 0x57, 0x4d, 0x56, 0xf)

def sub_decrypt(data, subgamma):
	o = ''
	length = len(data)
	subgamma_length = len(subgamma)
	for i in range(length):
		o += chr((0x100 + ord(data[i]) - subgamma[i%subgamma_length]) & 0xff)
	return o

def base64_utf8_sub_decrypt(data, subgamma):
	data = base64.b64decode(data)
	data = data.decode('utf-8')
	data = sub_decrypt(data, subgamma)
	return data

• Since October 2019: perform symbol-by-symbol circular modified XOR with the set array of bytes, and encode with Base64 twice. The peculiarity of XOR algorithm is that if the string symbol value matches the value of the symbol in the set array of bytes, XOR is not required. Sample of Python code for decryption:

xorgamma = (0x56, 0x2d, 0x61, 0x21, 0x16)

def modxor_decrypt(data, xorgamma):
	o = ''
	length = len(data)
	xorgamma_length = len(xorgamma)
	for i in range(length):
		c = data[i]
		if c != xorgamma[i%xorgamma_length]:
			c = data[i] ^ xorgamma[i%xorgamma_length]
		o += chr(c)
	return o

def base64_modxor_decrypt(data, xorgamma):
	data = base64.b64decode(data)
	data = modxor_decrypt(data, xorgamma)
	return data

When we were writing the decryption script, we found that some strings couldn’t be decrypted. But then we found that these lines can still be decrypted with one of the decryption methods mentioned earlier. After we verified that each sample uses only one decryption method, we concluded that the attackers had simply forgotten to delete unused strings or replace them with those correctly encrypted for the next version of the malware.

Such mistakes are always advantageous for the researchers. For instance, the strings left by the attackers often contained the attackers' control servers which we did not know about before.

Network Infrastructure peculiarities

To complete the picture, we want to point out some typical features which can help you make a connection between the group's attacks in the future.

• Most of the control servers are rented from DigitalOcean, LLC (ASN 14061), and are located in Amsterdam.
• The attackers do not use the same servers for different DNS names. They prefer reserving a new allocated host for each new domain name.
• In most cases, domain owners' registration information is hidden with privacy services. The attackers can use the following services: WhoisGuard, Inc.; Whois Privacy Protection Service, Inc.; Domains By Proxy, LLC; and Whois Privacy Protection Foundation. In some cases the data is accessible, and we can see the common approach to filling the fields.

• Most commonly, the attackers use .top, .pw, .space, .live, and .icu TLD.

Conclusions

Donot Team is known to use their own tools at every stage of the attack. On the one hand, the group uses various techniques to make code analysis more difficult, but on the other hand, it does not attempt to hide or disguise their actions in the system. Multiple attacks on the same targets can be indicative of particular interest in the chosen range of victims. This can also mean that the used tactics and techniques are not very efficient.

Author: Alexey Vishnyakov, Positive Technologies

IOCs