Operation TA505: how we analyzed the new tools of the creators of the Trojan Dridex, the ransomware Locky and the Neutrino botnet





The geography of the attacks of the TA505 group for 2019



Our team of Threat Intelligence analysts from the PT Expert Security Center has been monitoring cybercriminals from TA505 for six months. The area of ​​interest of the attackers is financial, and the goals are located in dozens of countries on different continents.



What group TA505 is known for



This group of attackers has a rich history : since 2014, they have listed the banking Trojan Dridex, the Neutrino botnet, as well as a whole series of cryptographers - Locky, Jaff, GlobeImposter, etc.



The activity of the group was recorded throughout the world - from North America to Central Asia. Note: we recorded isolated cases of malicious mailings of the TA505 grouping on the territory of Russia, but there is every reason to believe that the attackers did not have targets in our country, and the mailings were random in nature.



Despite the predominantly financial motivation of the group, among its goals in the last six months there have been research institutes, organizations of the energy industry, healthcare, aviation companies and even the public sector.







Distribution of TA505 attacks by industry for 2019



Below is an example of a phishing email containing malicious software developed by the group and targeted, judging by the email address, to the UK Foreign Office.







Since the spring of 2018, the group has been using the Remote Access Tool FlawedAmmyy, and since the end of the year it has been using the new ServHelper backdoor. TA505 - one of the few who can boast of vigorous activity for a long time. In addition, with each new wave of attacks, they bring interesting changes to their tools.







TA505 group detection dynamics by months for 2019



Of course, such a boisterous activity does not go unnoticed: there are many publications by our colleagues from Proofpoint , Trend Micro , Yoroi and not only about malicious techniques and malware. However, many interesting details are ignored:





This article is the first in a series of our posts about TA505.



Part one. Meet by package



In mid-June 2019, we noticed that the next FlawedAmmy malware downloaders are significantly different from previous versions: for example, the visual representation of the program code in the hexadecimal editor changed, and even became something characteristic of several samples taken:







ASCII representation of program code



A quick analysis of the code showed that we have before us an unknown packer of executable files. Later it turned out that this packer covered not only the aforementioned loaders, but also other samples of the HPE group, including the payload. Then we decided to study in detail the decompression logic in order to automatically extract the target object.



Layer 1. Twisted XOR



The key part of the unpacker is preceded by an abundance of useless instructions. Virus writers often resort to such a technique to confuse emulators of antivirus products. All interesting things begin with the allocation of memory for a buffer of size 0xD20 using the WinAPI-function VirtualAllocEx. Memory is allocated with PAGE_EXECUTE_READWRITE permissions, which allows you to write and execute code.







The beginning of the contents of the unpacker



The data section of the file under study contains an array of data that goes through the decryption procedure, and the result is written to the allocated memory. Decryption Algorithm:









Decoding the first layer

We denote this algorithm by the abbreviation SUB-XOR-ROL7-XOR to refer to it later.

After the decryption procedure, the variables are sequentially initialized. This can be represented as filling in a structure in C in the following format:



struct ZOZ { HMODULE hkernel32; void *aEncodedBlob; unsigned int nEncodedBlobSize; unsigned int nBlobMagic; unsigned int nBlobSize; };
      
      





Where:









Encoded data block





We called the ZOZ structure (this is “505” on leetspeak ).







Fill ZOZ Structure



As a result of the described actions, the code execution will be redirected to the decrypted buffer (now there is no doubt that the decrypted data is executable code), and the pointer to the filled structure will be passed as a function parameter:







Calling the decrypted code with the " ZOZ " structure passed as an argument







Disassembled piece of decrypted code



Layer 2. The smaller the better



After transferring control to the decrypted piece of code, the first step is to determine the addresses of the WinAPI functions GetProcAddress, VirtualQuery, VirtualAlloc, VirtualProtect, VirtualFree and LoadLibraryA. This list is often found in the work of shell codes: after all, they need to prepare and correctly fill the memory for the subsequent launch of the payload.



Upon completion of the preliminary procedures, the transmitted encoded data block is truncated: out of every five bytes, the first two are discarded, and the remaining three are saved:







Coded Data Block Reduction



Then, the decryption procedure, which we called SUB-XOR-ROL7-XOR, is performed . In this case, another nBlobMagic value is used as a constant for the XOR operation, which was passed in the ZOZ structure.







Reusing SUB-XOR-ROL7-XOR Algorithm



After that, the resulting array is transferred to a function in which a series of more complex transformations takes place. By the characteristic values ​​of the constants, it is easy to establish that this is an implementation of the popular PE-wrapper FSG (Fast Small Good). It is curious that the original version of the FSG packer compresses PE into sections, and the implementation of the algorithm in our case works with PE as a whole.







FSG Packer Implementation



At this stage, the unpacked PE target file, ready for further analysis, is in memory. The rest of the shellcode will overwrite the original PE in the address space with the unpacked version and run it correctly. It is interesting to note that in the process of adjusting the entry point of the loaded module, structures are manipulated in PEB. Why attackers decided to forward the kernel32 descriptor from the logic of the first layer instead of retrieving it using the same PEB structures is unknown.







Overwriting the value of the entry point of the loaded module in PEB



Conclusion



So, the payload unpacking algorithm:





During the evolution of malware, the logic changed: for example, the number of cyclic shifts of the SUB-XOR-ROL7-XOR algorithm (seven in the considered case) changed to five, nine, the packer version for the x64 platform was released, etc. The unique cybercriminal grouping packer is excellent epigraph to future narrations about the tools and features of the TA505.



In the following articles, we will talk about how the TA505 tools developed and changed in the course of the latest attacks, about the interaction of participants with other cyber groups, and we will study the previously not examined malware models.



Authors : Alexey Vishnyakov and Stanislav Rakovsky, Positive Technologies



IOCs



b635c11efdf4dc2119fa002f73a9df7b



- b635c11efdf4dc2119fa002f73a9df7b



Packaged Loader

71b183a44f755ca170fc2e29b05b64d5



- 71b183a44f755ca170fc2e29b05b64d5



unpacked bootloader



All Articles