Operation TA505, part four. Twins

We continue to talk about the activities of the hacker group TA505. The well-known phrase “the new is the well-forgotten old” is the best suited as an epigraph to the next chapter of the story about the group TA505. True, this time the “old” is not so much “forgotten” as it is reworked and improved.



In early September, we discovered several malicious downloaders packaged with a special group PE-packer, which we wrote about earlier . At first glance, they looked like the well-known FlawedAmmyy backdoor stagers. But a deeper analysis showed that this is not so. Not the most advanced techniques for writing code have brought us to radically opposite payloads in terms of quality of execution.



In this article, we will take a closer look at the tools found and draw parallels with what is already known.

Bootloader twein

First of all, the following is curious: of all the bootloader samples that we managed to collect, only one has a digital signature:







Fig. 1. Digital signature of the bootloader



Certificate issued in the name of PEAR SOLUTIONS LTD. By the way, this is not the first time that a group signs its tools, passing them off as legitimate software of fictitious organizations. Here are a few other names that used the TA505 for other malware families:

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

Since the detected bootloaders do not differ among themselves, we select the aforementioned signed one and dwell on it in more detail.



Throughout the work of malware, almost every action is accompanied by writing to the log file and debug output of everything that happens:







Fig. 2. Debug output and logging



Such tracing not only simplifies the static analysis of the file, but also helps to find out what is wrong in dynamic analysis systems:







Fig. 3. Debug output in the ANY.RUN online analyzer



Troyan checks the language layout of the keyboard - and does not work in Russia and neighboring countries:







Fig. 4. Checking the language layout of the keyboard

Then it creates the Global\system32_mutant_service



mutex and checks the Internet availability using an HTTP GET request to google.com. After that, it determines the way of accessing the network (a dedicated address or NAT ) by determining the external IP address by the services myexternalip.com, ipecho.net and ifconfig.me and comparing the received value with those specified in the network parameters of the system:







Fig. 5. Comparison of internal and external IP addresses



Next, the malware determines the version of the library %SystemRoot%\system32\crypt32.dll



and, if the build number and revision number are less than 7601



and 18741



respectively, downloads and installs update KB3033929



according to the operating system version:







Fig. 6. Download and install system updates



TA505 attackers take care of the victim and patch the system as needed? Not at all. Installing the update involves stopping support for code security certificates signed with SHA-1 and abandoning it in favor of the SHA-2 algorithm. Most likely, hackers have already had difficulty running signed payloads on non-updated systems. Interestingly, after installing the update, the trojan sends the generated action log to the management server, stops its work and clears itself, clearing the traces left.







Fig. 7. Shutdown after installing a system update



If the update installation is not required, the bootloader collects and sends the following information to the management server:

• system information
• information about installed software,
• information about signed software in the% ProgramFiles% and% ProgramFiles (x86)% directories (if any),
• Information about signed drivers in the% SystemRoot% \ drivers directory.

Note that a legitimate code was used to obtain information about signatures.







Fig. 8. Obtaining certificate information



After that, the bootloader creates the directory C:\Windows\Logs\diag



and starts a thread in which it tracks changes in the directory, sending notifications to the managing server:







Fig. 9. Monitoring directory changes



Then it prepares existing and missing information about the system (username, system version, domain, IP address, information about the video card, network connection - NAT or not NAT) and generates a JSON file of this type:

 { "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, this data will be encrypted with RC4 (the gJypA9RWUlYpnBbzujVqE6fDcEAk0zoz



encryption key is encrypted in the Trojan’s body), encoded with Base64 and sent by an HTTP POST request to the managing server:







Fig. 10. HTTP POST request to the management server







Fig. 11. List of control servers in the bootloader body



The response from the server is decrypted by RC4 (the encryption key is the same as that used to send the data) and checked: the first two bytes must correspond to the MZ line, which is a sign of the PE file. We already met this sequence earlier when we analyzed another group loader that delivered FlawedAmmyy RAT:







Fig. 12. A similar code to decrypt and verify the downloaded file in the bootloader in question (left) and the FlawedAmmyy RAT bootloader (right)



Payload loading occurs not only in the main thread, but also in a separately created one. In other words, there are two payloads. In one case, the Global \ system32_host_service mutex is pre-checked, and in case of its absence, a component is loaded, which is referred to in the debug information as payload or bot. Interestingly, after receiving a response from the server, the PE file does not start in any way. Instead, his body is written to the registry in the HKEY_LOCAL_MACHINE\SYSTEM



section in key 0x228028



. Then the bootloader disables the redirection of the WoW64 file system for 32-bit applications using Wow64DisableWow64FsRedirection



and starts the %SystemRoot%\System32\services.exe



process with the -ww parameter. Using this parameter does not make sense, but this completes the installation chain of the resulting payload.







Fig. 13. Setting the payload



We’ll talk about the second payload later.

Twein plugins

Examining the trojan discussed above, we noticed a function that removes two files from the %SystemRoot%



directory - twein_32.dll



and twein_64.dll



:







Fig. 14. Removing twein_32.dll and twein_64.dll files



These files are not found anywhere else, they do not appear in the logic of the bootloader. However, the names of the libraries reminded us of another malware in the group, which we will now consider.

Two months earlier, we discovered a TA505 Trojan, about 9 MB in size. The file is packaged by UPX . The trojan is installed into the system as a WMDICToss



service. The resources contain three files: systemdiron.bat



, twein__32.dll



and twein__64.dll



, which are encrypted with linear XOR.







Fig. 15. Decryption of one of the resources of the dropper



Note that the names of the two files are almost identical to those already mentioned: the difference is only in the number of underscores.



One of the decrypted resources with the name systemdiron.bat



expected to be a command script that provides the launch of other components depending on the capacity of the system:

 @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 act similarly. Packed with the characteristic packer of group TA505. Original library names: av_block.dll



. The analysis is significantly complicated by the use of an obfuscator, and the proportion of obfuscated code is about 80%. As a result of this, program execution is saturated with numerous transitions, decoding of the next code steps, non-linear function calls.



Libraries contain an impressive list of Base64-like strings, which are decrypted as follows:



1. The input string is divided into blocks of 4 bytes;

2. Each block is decoded using the replacement and shift algorithm:

 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) blocks are collected in a single line;

4) the result is decrypted by the eexec algorithm with a double-byte key, passed as a parameter:







Fig. 16. Implementation of the eexec algorithm



Most of the lines are the names and paths to the files of anti-virus products, however some of them do not belong to security tools at all: MS Exchange Server, MySQL Server, SAP, Apache, PostgreSQL, Elasticsearch, etc. There were even such unique paths:

• 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 software is found in the system from the list, files and directories are deleted.



To secure themselves in the system, the libraries install themselves as the interface of the service provider (SPI) of Windows Sockets , called Intel and IntelFiltr. In addition, they change the order of the handlers in the protocol chain to be the first SPI to handle the client request.



In 2015, our FireEye colleagues introduced the LatentBot bot analysis . It is curious that the string encryption algorithm in LatentBot and the twein libraries reviewed is completely the same. In addition, LatentBot uses a security module as one of the plug-ins, which searches for security tools in the system using the specified paths and product names, though it is limited to checking for availability.

Rootkit twein

Back to the bootloader, namely the second payload. From the debug lines of try to open rootkit ... and Driver% S installed, it's easy to guess the format of the next payload. After successful loading, the driver will be written to the %SystemRoot%\System32\drivers



directory with a name formed in a pseudo-random way from the names of other legitimate files. Then the service will be created and launched:







Fig. 17. Installing and starting the service



At the final stage of its work, the bootloader will configure the driver to be blacklisted in registry keys: the names of anti-virus processes, analysis tools, and protection vendors in digital file signatures will be entered in the specified numeric values ​​of the keys of the HKEY_LOCAL_MACHINE\SYSTEM



branch:







Fig. 18. Blacklisted driver configuration



In the process of researching the bootloader, we were unable to obtain a driver sample from the management server. However, we found mention of a rootkit that was pumped out by another similar bootloader.



The driver is digitally signed in the name of Lizas Limited



with administrator@lizaslimited.site



as email:







Fig. 19. Digitally signed driver



In the course of the study, we found a lot in common with the well-known rootkit of the Necurs botnet, which the TA505 group actively used to send spam and spread malware. Let us consider in more detail the most interesting features of his work.



The driver registers event handlers for starting processes and loading PE images using PsSetCreateProcessNotifyRoutine



and PsSetLoadImageNotifyRoutine



. In other words, this allows the driver to control the launch of all new processes and services. Using the blacklists that we mentioned earlier, the rootkit terminates unwanted processes using ZwTerminateProcess and prevents other drivers potentially dangerous for it from loading, overwriting the entry point value on the instructions:

 mov eax, 0C0000001 retn 8
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

As a result, the service will be unloaded with the STATUS_UNSUCCESSFULL



error.







Fig. 20. Process completion







Fig. 21. Overwriting driver entry points



By means of CmRegisterCallback, the driver intercepts access events to the system registry. In particular, his further work is parameterized by the numerical values ​​of the keys that are accessed in intercepted events.







Fig. 22. Rootkit management of registry key accesses



Interestingly, in some versions of the Necurs rootkit, the same numerical values ​​were used as ioctl request codes.







Fig. 23. Managing a Necurs rootkit using ioctl queries



This trick can be regarded as a step towards greater secrecy: access to the registry causes less suspicion than ioctl-requests to DeviceObject.



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







Fig. 24. Decryption and injection of the auxiliary library into the created process



The auxiliary component is a custom reflective loader that correctly places the second PE file in the memory, which acts as a payload, and transfers control to it. Now it becomes clear how exactly the payload that was written to the registry by the bootloader from the first part of the article begins to work.







Fig. 25. Filling the import table with an auxiliary library

Conclusion

In the article, we got acquainted with the features of the work of many twin trojans. Why the twins? The malicious bootloader with which we started our research is very similar in quality to the code writing and implementation nuances to the well-known FlawedAmmyy backdoor bootloader. The twein libraries that he is trying to remove from the system are most likely the ones we are looking at next. Libraries are very similar to the LatentBot security plugin. One of the bootloader payloads is a driver that is a derivative of the popular Necurs rootkit.



Some malware families are over 5 years old, however, attackers continue to update and improve them, taking into account the development of operating systems and security tools.



Authors : Alexey Vishnyakov and Daniil Koloskov, Positive Technologies

Previous articles in the series:

• Operation TA505: how we analyzed the new tools of the creators of the Trojan Dridex, the ransomware Locky and the Neutrino botnet. Part 1
• Operation TA505: Learning the ServHelper backdoor with NetSupport RAT. Part 2
• Operation TA505: Grouping Network Infrastructure. Part 3