Operation TA505: twins. Part 4

The old adage "everything old is new again" perfectly fits the latest chapter in the story of the TA505 group. Although in the case we are going to examine, the "old" has been well revised and enhanced on its way to becoming "new."

In the beginning of September we detected some malware downloaders packed by the group's unique PE packer described in one of our earlier articles. At first glance the downloaders appeared similar to the well-known stagers of the FlawedAmmyy backdoor. However, closer analysis proved otherwise. The less-than-cutting-edge coding techniques we found in them pointed the way to payloads that were implemented to a rather higher standard of quality.

This article will provide a detailed look at the detected malware and draw parallels with what is already known.

Twein downloader

Curiously, out of all the downloader samples that we managed to find, only one was digitally signed:

The certificate is issued in the name of PEAR SOLUTIONS LTD. This is not the first time TA505 has signed malware to make it look like legitimate software (albeit from fictitious organizations). Here are some names of organizations that TA505 has used for other malware families:

• ET HOMES LTD,
• FIT AND FLEX LIMITED,
• MISHA LONDON LTD,
• SATOJI KAIDA MB,
• VERY TELE LIMITED.

Since the found downloaders are all similar, let us opt for the one mentioned above and focus on it.

When the malware is running, almost every action entails a trace record and debug output:

Such tracing facilitates static analysis of the file and also helps examine malicious activity via dynamic analysis:

The Trojan checks the keyboard layout to prevent it from running in Russia and some neighboring countries:

Then the downloader creates the mutex Global\system32_mutant_service and checks if the Internet is available by sending an HTTP GET request to google.com. After that, the Trojan tries to determine the type of Internet access (dedicated IP address or NAT) by identifying the external IP via myexternalip.com, ipecho.net, and ifconfig.me and comparing the obtained values with those specified in the system's network parameters:

Next, the malware identifies the version of the %SystemRoot%\system32\crypt32.dll library. If the build number and the revision number are less than 7601 and 18741 respectively, then the Trojan downloads and installs the KB3033929 update appropriate for the installed OS version:

Are the TA505 attackers so kind as to care about the victim's system and patch it when necessary? Not a chance. Installing the update ends support for SHA-1 code signing certificates, requiring SHA-2 instead. The hackers most likely had encountered difficulties launching signed payloads on non-updated systems. Having installed the update, the Trojan generates and sends a log to its С&C server, stops its activity, and removes itself from the system cleaning up the traces.

If installing the update is not needed, the downloader collects and sends the following data to the C&C server:

• System data
• Information on installed software
• Data about signed software in the directories %ProgramFiles% and %ProgramFiles(x86)% (if any)
• Information on signed drivers in the %SystemRoot%\drivers directory

Note that the attackers leveraged legitimate code to obtain information about digital signatures.

After that, the downloader creates the C:\Windows\Logs\diag directory and launches a thread in which it monitors changes in the directory and sends notifications to its C&C server:

Then the Trojan prepares already known and missing system information (username, system version, domain, IP address, video card information, and NAT vs. non-NAT Internet access) and generates a JSON file as follows:

{
 "adm": "0",
 "bid": "M3xwwhqLH/AUOhmU2+W55A==",
 "bit": "1",
 "bnet": "ldr",
 "cam": "0",
 "cis": "0",
 "dmn": "WORKGROUP",
 "hash_r": "0",
 "lip": "192.168.100.153",
 "lvl": "0",
 "nat": "1",
 "osb": "0",
 "osv": "Windows 7 Professional",
 "pc": "USER-PC",
 "proc_c": "0",
 "proc_n": "cpu",
 "rep": 0,
 "tmt": "0",
 "ver": "163",
 "video": "Standard VGA Graphics Adapter,"
}

Later the data will be encrypted with RC4 (the encryption key gJypA9RWUlYpnBbzujVqE6fDcEAk0zoz is hardcoded in the Trojan's body), encoded with Base64, and sent in an HTTP POST request to a C&C server:

The server response undergoes RC4 decryption (the key is the same as the one used for sending the data). The first two bytes are checked to see if they equal the string MZ, indicating that it is a PE file. We have already encountered such a sequence before, when analyzing another TA505 downloader responsible for delivering the FlawedAmmyy RAT:

The payload is downloaded not only in the main thread, but also in a specially generated one. In other words, there are two payloads. In the case of one, the Global\system32_host_service mutex is checked, and if it is not present, the Trojan downloads the component named in the debug information as payload or bot. After the response is received from the server, the PE file does not run at at all. Instead, its body is written to registry hive HKEY_LOCAL_MACHINE\SYSTEM in key 0x228028. After that, the downloader disables redirection of the WoW64 file system for 32-bit applications via Wow64DisableWow64FsRedirection and starts the process %SystemRoot%\System32\services.exe with the parameter -ww. There is no point in using this parameter, but this is the last step in installing the payload.

We will discuss the second payload a bit later.

Twein plugins

As we studied the Trojan in question, a certain function caught our attention. It deletes the files twein_32.dll and twein_64.dll from the %SystemRoot% directory:

The files do not come up anywhere else and are not involved with the operation of the downloader. However, the names of these two libraries reminded us of some other malware from TA505 which we are going to discuss here.

Two months earlier we found a Trojan of the TA505 group approximately 9 MB in size. The file is packed by UPX. The Trojan is installed on the system as the WMDICToss service. The resources contain three files — systemdiron.bat, twein__32.dll, and twein__64.dll — encrypted by linear XOR.

Note that the names of the two files are almost the same as the file names we discussed earlier. The only difference is in the number of underscore characters.

One of the decoded resources with the name systemdiron.bat unsurprisingly turns out to be a command script, which ensures the start of other components as appropriate based on whether the system is 32-bit or 64-bit:

@echo off
if defined PROCESSOR_ARCHITEW6432 (goto LABEL_X64)
if %PROCESSOR_ARCHITECTURE%==IA64 (goto LABEL_X64)
if %PROCESSOR_ARCHITECTURE%==AMD64 (goto LABEL_X64)
if %PROCESSOR_ARCHITECTURE%==x86 (goto LABEL_X86)
goto LABEL_NON

:LABEL_X64
echo OS type: x64
copy c:\temp\tmp.log c:\i.txt
rundll32.exe C:\Windows\twein__64.dll,Install
copy c:\temp\tmp.log c:\i.txt
rundll32.exe C:\Windows\twein__32.dll,Install
del c:\temp\tmp.log
del c:\i.txt
shutdown.exe -r -t 00
goto LABEL_END

:LABEL_X86
echo OS type: x86
copy c:\temp\tmp.log c:\i.txt
rundll32.exe C:\Windows\twein__32.dll,Install
del c:\temp\tmp.log
del c:\i.txt
shutdown.exe -r -t 00
goto LABEL_END

:LABEL_NON
echo OS type: undefined
goto LABEL_END

:LABEL_END 
pause

Both twein libraries operate in a similar way. They are both packed by a packer that is characteristic of TA505. Note the original name of the libraries: av_block.dll. The use of an obfuscator substantially complicates analysis. About 80 percent of the code is obfuscated. That is why execution of the program is full of jumps, code decryptions, and non-linear function calls.

The libraries contain a huge list of Base64-like strings that are decrypted in the following way:
1) The input string is divided into blocks of 4 bytes each.
2) Each block is decoded via an algorithm with substitution and shift:

import binascii
def block_decode(input_str, len_of_block):
	alphabet = '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x3E\x00\x00\x00\x3F\x34\x35\x36\x37\x38\x39\x3A\x3B\x3C\x3D\x00\x00\x00\x00\x00\x00\x00\x00\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0A\x0B\x0C\x0D\x0E\x0F\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x00\x00\x00\x00\x00\x00\x1A\x1B\x1C\x1D\x1E\x1F\x20\x21\x22\x23\x24\x25\x26\x27\x28\x29\x2A\x2B\x2C\x2D\x2E\x2F\x30\x31\x32\x33\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
	int_result = 0
	for i in range(len_of_block):
		alph = ord(alphabet[ord(input_str[i])])
		alph <<= 0x6 * i
		int_result += alph
	str_result = hex(int_result)[2:]
	if len(str_result) % 2 != 0:
		str_result = '0' + str_result
	return binascii.unhexlify(str_result).decode('latin1')[::-1]

3) The blocks are assembled into a single string.
4) The result is decoded by the eexec algorithm with a 2-byte key, which is passed as a parameter:

The majority of the strings are file names and paths to antivirus software files. But some of them relate to Microsoft Exchange Server, MySQL Server, SAP, Apache, PostgreSQL, Elasticsearch, and others. Unique paths were found as well:

• C:\Users\tislam\Desktop\salik app\Aye_salik_data\Aye_salik_data\bin\Debug\Aye_salik_data.exe
• C:\oem13c\agent13c\agent_13.2.0.0.0\perl\bin\perl.exe
• C:\Users\adadmin\Ubiquiti UniFi\bin\mongod.exe
• C:\Users\sakella\AppData\Local\Microsoft\OneDrive\OneDrive.exe
• D:\Add-ons\IMI_CREDIT_POLICY Test v 02.01\IMI_CREDIT_POLICY.exe

If the system is found to contain any software from the list, then the files and directories are deleted.

For persistence, the libraries install themselves as the Windows Sockets service provider interface (SPI) under the names of Intel and IntelFiltr. In addition, the libraries change the sequence of handlers in the protocol chain in order to become the first SPI to handle the client's request.

In 2015, researchers at FireEye reported on their analysis of LatentBot. The string encryption algorithm in LatentBot is absolutely the same as that in the twein libraries. Additionally, LatentBot uses a security module as one of its plugins. The module searches the system for specified paths and product names, although its activity does not extend beyond such checks.

Twein rootkit

We will now return to the topic of the downloader and, specifically, the second payload. The debug strings try to open rootkit... and Driver %S installed make it easy to guess the format of the subsequent payload. After successfully downloading, the driver is written to the directory %SystemRoot%\System32\drivers under a pseudorandom name that is generated from the names of other, legitimate files. Then the service is created and started:

At its final stage, the downloader configures the driver with deny lists in registry keys. It takes the names of antivirus processes, tools for analysis, and vendors of security tools from their digital signature files and adds them to the specified numeric values of the keys of the hive HKEY_LOCAL_MACHINE\SYSTEM:

While studying the downloader, we were unable to obtain a sample of the driver from the C&C server. However, we discovered a reference to a rootkit that was loaded by another similar downloader.

The driver is digitally signed to the name of Lizas Limited with the email address administrator@lizaslimited.site:

Studying this rootkit, we found many common characteristics with the well-known Necurs botnet, which TA505 widely used for sending spam and distributing its malware. Let us now have a closer look at how the rootkit operates.

The driver registers event handlers to run processes and download PE images via PsSetCreateProcessNotifyRoutine and PsSetLoadImageNotifyRoutine. In other words, the driver watches launch of all new processes and services. Using the deny lists we mentioned earlier, the rootkit terminates processes via ZwTerminateProcess. It also prevents the loading of other drivers that are potentially dangerous to it by overwriting the entry point value in the following way:

mov eax, 0C0000001
retn 8

This leads to unloading the service in normal mode with the error STATUS_UNSUCCESSFUL.

The driver intercepts system registry access events by using CmRegisterCallback. Namely, the driver's further operation is parametrized by the numeric values of the keys accessed in intercepted events.

In some versions of the Necurs rootkit, the same numeric values were used as ioctl request codes.

This trick can be considered a step towards greater stealth, because registry calls are less suspicious than ioctl requests to DeviceObject.

The rootkit body contains a helper DLL library encrypted with single-byte XOR. When a new process is created, the driver injects the library along with another PE file, which is extracted from the registry and is again decrypted with single-byte XOR.

The helper component is a custom reflective loader, which correctly loads the second PE file (which acts as payload) into memory and passes control to it. This can help understand how exactly the payload from the first part of the article (the one added by the downloader to the registry) starts operating.

Conclusions

The article has examined the characteristic features of certain twin Trojans. Why twins, you might wonder? The malware downloader covered in the beginning of the article is very similar in code quality and certain aspects of its implementation to the well-known downloader of the FlawedAmmyy backdoor. The twein libraries that the Trojan tries to remove from the system are, most likely, the very same libraries covered here. The libraries are extremely similar to the security plugin of LatentBot. One of the downloader payloads is a driver derived from the well-known Necurs rootkit.

Even with malware families that are more than five years old, the developers still continue updating and enhancing them to keep up with today's operating systems and security tools.

Authors: Alexey Vishnyakov and Daniil Koloskov, Positive Technologies

IOCs