At the end of May, we discovered a campaign of malware distribution of the Remote Access Trojan (RAT) class, programs that allow attackers to remotely control an infected system.
The group we are considering was distinguished by the fact that it did not choose any specific RAT family for infection. Several Trojans were spotted in the attacks within the campaign (all in the public domain). With this feature, the grouping reminded us of the rat king - a mythical animal that consists of rodents with intertwined tails.
The original is taken from the monograph by K. N. Rossikov "Mice and mouse-like rodents, the most important in economic terms" (1908)
In honor of this creature, we named the grouping we are considering RATKing. In this post, we will talk in detail about how the attackers carried out the attack, what tools they used, and also share our thoughts on the attribution of this campaign.
Attack progress
All attacks in this campaign were carried out according to the following algorithm:
The user received a phishing email with a link to Google Drive.
From the link, the victim downloaded a malicious VBS script that wrote a DLL to load the final payload into the Windows registry and launched PowerShell to execute it.
The DLL-library injected the final payload β in fact, one of the RATs used by the attackers β into the system process and added a VBS script to autorun in order to gain a foothold in the infected machine.
The final payload was executed in a system process and gave the attacker the ability to control the infected computer.
Schematically, this can be represented as follows:
Next, we will focus on the first three stages, since we are interested in the malware delivery mechanism. We will not describe in detail the mechanism of the malware itself. They are widely available - either sold on specialized forums, or even distributed as open source projects - which means they are not unique to the RATKing group.
Analysis of attack stages
Stage 1. Phishing mailing
The attack began with the victim receiving a malicious email (the attackers used different templates with text, one example is shown in the screenshot below). The message contained a link to a legitimate repository drive.google.com, which allegedly led to a PDF download page.
Example of a phishing email
However, in fact, it was not a PDF document that was loaded at all, but a VBS script.
When clicking on the link from the email in the screenshot above, a file with the name Cargo Flight Details.vbs. In this case, the attackers did not even try to disguise the file as a legitimate document.
At the same time, as part of this campaign, we discovered a script named Cargo Trip Detail.pdf.vbs. It could already pass for a legitimate PDF, because by default Windows hides the file extension. True, in this case, its icon, which corresponded to the VBS script, could still cause suspicion.
At this stage, the victim could recognize the deception: just look at the downloaded files for a second. However, in such phishing campaigns, attackers often rely on an inattentive or hurried user.
Stage 2. Work of the VBS script
The VBS script, which the user could open by negligence, registered the DLL library in the Windows registry. The script has been obfuscated: the lines in it are written as bytes separated by an arbitrary character.
Obfuscated script example
The deobfuscation algorithm is quite simple: every third character was excluded from the obfuscated string, after which the result was decoded from base16 to the original string. For example, from the value 57Q53s63t72s69J70r74e2El53v68m65j6CH6Ct (highlighted in the screenshot above) the result was a line WScript.Shell.
To deobfuscate strings, we used a Python function:
def decode_str(data_enc):
return binascii.unhexlify(''.join([data_enc[i:i+2] for i in range(0, len(data_enc), 3)]))
Below, on lines 9-10, the value is highlighted, upon deobfuscation of which a DLL file was obtained. It was he who was launched in the next step using PowerShell.
Line with obfuscated DLL
Each function in the VBS script was executed as the lines were deobfuscated.
After running the script, the function was called wscript.sleep - with its help, deferred execution was performed.
Further, the script worked with the Windows registry. He used WMI technology for this. With its help, a unique key was created, and the body of the executable file was written to its parameter. Accessing the registry via WMI was performed using the following command:
At the third stage, the malicious DLL loaded the final payload, injected it into the system process, and ensured that the VBS script was auto-run when the user logged into the system.
Launch via PowerShell
The DLL was executed using the following command in PowerShell:
received registry value data named rnd_value_name - this data was a DLL file written on the .Net platform;
loaded the resulting .Net module into the process memory powershell.exe using the function [System.Threading.Thread]::GetDomain().Load()(detailed description of the Load() function available on the Microsoft website);
performed the function GUyyvmzVhebFCw]::EhwwK() - the execution of the DLL library began with it - with parameters vbsScriptPath, xorKey, vbsScriptName... Parameter xorKey stored the key for decrypting the final payload, and the parameters vbsScriptPath ΠΈ vbsScriptName were transferred in order to register a VBS script in autorun.
Description of the DLL
In the decompiled form, the loader looked like this:
Loader in decompiled form (underlined in red is the function that started the execution of the DLL)
The loader is protected by the .Net Reactor protector. The de4dot utility does an excellent job of removing this protector.
This bootloader:
carried out the injection of the payload into the system process (in this example, this svchost.exe);
prescribe VBS-script in autorun.
payload injection
Consider the function that the PowerShell script called.
Function called by PowerShell script
This function did the following:
decrypted two arrays of data (array ΠΈ array2 on the screenshot). They were originally gzip-compressed and encrypted using the XOR algorithm with the key xorKey;
copied data to allocated memory areas. Data from array - to the memory area pointed to intPtr (payload pointer on the screenshot); data from array2 - to the memory area pointed to intPtr2 (shellcode pointer on the screenshot);
called a function CallWindowProcA(description this feature is available on the Microsoft website) with the following parameters (the names of the parameters are listed below, in the screenshot they go in the same order, but with working values):
lpPrevWndFunc - pointer to data from array2;
hWnd - pointer to a string containing the path to the executable file svchost.exe;
Msg - pointer to data from array;
wParam, lParam β message parameters (in this case, these parameters were not used and had values ββof 0);
created a file %AppData%MicrosoftWindowsStart MenuProgramsStartup<name>.urlWhere <name> are the first 4 characters of the parameter vbsScriptName (in the screenshot, the code fragment with this action begins with the command File.Copy). In this way, the malware added a URL file to the list of files to autorun when a user logged into the system, and thereby fixed itself on the infected computer. The URL file contained a link to the script:
To understand how the injection was carried out, we deciphered the data arrays array ΠΈ array2. To do this, we used the following Python function:
def decrypt(data, key):
return gzip.decompress(
bytearray([data[i] ^ key[i % len(key)] for i in range(len(data))])[4:])
As a result, we found out that:
array was a PE file - this is the final payload;
array2 was the shellcode required for the injection.
Shellcode from array array2 passed as function value lpPrevWndFunc into a function CallWindowProcA. lpPrevWndFunc is a callback function, its prototype looks like this:
So when you run the function CallWindowProcA with parameters hWnd, Msg, wParam, lParam executing shellcode from an array array2 with arguments hWnd ΠΈ Msg. hWnd is a pointer to a string containing the path to the executable file svchost.exe, Msg β a pointer to the final payload.
The shellcode received function addresses from kernel32.dll ΠΈ ntdll32.dll by hash values ββfrom their names and performed the injection of the final payload into the process memory svchost.exeusing the Process Hollowing technique (you can read more about it in this article). When injecting shellcode:
created a process svchost.exe in a suspended state using the function CreateProcessW;
then hide the section mapping in the process address space svchost.exe using functions NtUnmapViewOfSection. Thus the program freed the memory of the original process svchost.exe, in order to allocate memory for the payload at this address;
allocated memory for the payload in the address space of the process svchost.exe using functions VirtualAllocEx;
Starting the injection process
write the contents of the payload to the address space of the process svchost.exe using functions WriteProcessMemory (as in the screenshot below);
restarted the process svchost.exe using functions ResumeThread.
Completion of the injection process
Downloadable malware
As a result of the described actions, one of several malicious programs of the RAT class was installed on the infected system. The table below lists the malware used in the attack, which we can confidently attribute to one group of attackers, since the samples accessed the same control server.
Name of HPE
First seen
SHA-256
DC
The process into which the injection is carried out
Examples of distributed malware with the same control server
Two things are noteworthy here.
First, the very fact that the attackers used several different RAT families at once. This behavior is not typical for well-known cybergroups, which often use approximately the same set of tools they are used to.
Secondly, RATKing used malware that is either sold on specialized forums for a small price, or is completely open source projects.
A more complete list of the malware used in the campaign - with one important caveat - is given at the end of the article.
About grouping
We cannot attribute the described malicious campaign to any known attackers. So far, we believe that these attacks were carried out by a fundamentally new group. As we wrote at the beginning, we named it RATKing.
To create a VBS script, the grouping probably used a tool similar to the utility VBS-Crypter from the developer NYAN-x-CAT. This is indicated by the similarity of the script that this program creates with the attacker's script. Specifically, they are both:
carry out deferred execution using the function Sleep;
use WMI;
prescribe the body of the executable file as a registry key parameter;
execute this file using PowerShell in its own address space.
For clarity, compare the PowerShell command to run a file from the registry, which is used by a script created using VBS-Crypter:
Note that the attackers used another utility from NYAN-x-CAT as one of the payloads - LimeRAT.
The C&C server addresses point to another hallmark of RATKing: the grouping favors dynamic DNS services (see list of C&Cs in the IoC table).
IoC
The table below shows a complete list of VBS scripts that can most likely be attributed to the described campaign. All these scripts are similar and carry out approximately the same sequence of actions. All of them inject malware of the RAT class into a trusted Windows process. All of them have C&C addresses registered using Dynamic DNS services.
However, we cannot say that all these scripts were distributed by the same attackers, except for samples with the same C&C addresses (for example, kimjoy007.dyndns.org).
Name of HPE
SHA-256
DC
The process into which the injection is carried out