To redeem is the queen: Varonis investigates the fast-spread ransomware ransomware “SaveTheQueen”

A new type of malware of the ransomware virus class encrypts files and adds the .SaveTheQueen extension to them, spreading through the system network folder
SYSVOL on Active Directory Domain Controllers.

Our customers have recently encountered this malware. We give our full analysis, its results and conclusions below.

Detection

One of our customers contacted us after they came across a new type of ransomware ransomware that added the extension “.SaveTheQueen” to new encrypted files in their environment.

During our investigation, or rather, at the stage of searching for sources of infection, we found out that the distribution and tracking of infected victims was carried out using network folder sysvol on the customer’s domain controller.

SYSVOL is a key folder for each domain controller used to deliver Group Policy Objects (GPOs) and login and logout scripts to domain computers. The contents of this folder are replicated between domain controllers to synchronize this data on the organization’s sites. Writing to SYSVOL requires high domain privileges, however, after being compromised, this asset becomes a powerful tool for attackers who can use it to quickly and efficiently distribute malicious load across the domain.

The Varonis audit chain has helped to quickly identify the following:

• The infected user account created a file named “hourly” in SYSVOL
• Many log files were created in SYSVOL – each named for a domain device name
• Many different IPs accessed the hourly file

We concluded that the log files were used to track the infection process on new devices, and that “hourly” is a scheduled task that runs malicious load on new devices using the Powershell script – samples “v3” and “v4”.

The attacker probably obtained and used domain administrator privileges to write files to SYSVOL. On infected nodes, the attacker launched PowerShell code, which created a schedule task for opening, decrypting, and launching malware.

Decryption

We have unsuccessfully tested several methods for decoding the samples:

We were almost ready to give up when we decided to try the “Magic” method of the magnificent
utilities Cyberchef authorship of GCHQ. “Magic” tries to guess the encryption of the file, using enumeration of passwords for different types of encryption and measuring entropy.

“Magic” determined that the base64 encoded GZip packer was used, thanks to which we were able to unzip the file and find the code for implementation – “injector”.

Dropper: “There’s an epidemic in the area! All-round vaccinations. Foot and mouth disease

The dropper was a regular .NET file without any protection. After reading the source code using DNSpy we realized that his only goal was to inject shellcode into the winlogon.exe process.

Shellcode or simple difficulties

We used the Hexacorn authorship tool – shellcode2exe in order to “compile” the shell code into an executable file for debugging and analysis. Then we found that it worked on both 32-bit and 64-bit machines.

Writing even a simple shellcode in native translation from assembler can be difficult, writing a full shellcode that works on both types of systems requires elite skills, so we began to marvel at the sophistication of the attacker.

When did we parse the compiled shellcode with x64dbgwe noticed that he was loading .NET dynamic libraries such as clr.dll and mscoreei.dll. This seemed strange to us – usually attackers try to make the shellcode as small as possible, calling the native functions of the OS instead of loading them. Why would anyone need to embed Windows functionality in shellcode instead of directly calling it on demand?

As it turned out, the author of the malware did not write this complex shell code at all – the software that was used for this task was used to translate executable files and scripts into shell code.

We found a tool Donut, which, it seemed to us, could compile a similar shell code. Here is his description from GitHub:
Donut generates x86 or x64 shellcode from VBScript, JScript, EXE, DLL (including .NET assemblies). This shellcode can be embedded in any Windows process for execution in
random access memory.

To confirm our theory, we compiled our own code using Donut and compared it with a sample – and … yes, we found another component of the toolkit used. After that, we were already able to extract and analyze the original executable file on .NET.

Code protection

This file has been obfuscated with Confuserex:

ConfuserEx is an open source .NET project to protect the code of other developments. This class of software allows developers to protect their code from reverse engineering using methods such as: replacing characters, masking the flow of control commands and hiding the reference method. Malware authors use obfuscators to avoid detection and to make the task of reverse engineering more difficult.

Thanks ElektroKill Unpacker we unpacked the code:

Bottom line – payload

The payload resulting from the transformations is a very simple ransomware virus. No mechanism to ensure presence in the system, no connections to the command center – just the good old asymmetric encryption, in order to make these victims unreadable.

The main function selects the following lines as parameters:

• File extension for use after encryption (SaveTheQueen)
• Author’s email to put in a ransom note file
• Public key used to encrypt files

The process itself looks as follows:

1. Malware scans local and mapped drives on victim device

   

2. Looks for encryption files

   

3. Attempts to terminate a process using the file it is about to encrypt.
4. Renames the file to “Source_file_name.SaveTheQueenING” using the MoveFile function and encrypts it
5. After the file is encrypted with the author’s public key, the malware renames it again, now in “Original_file_name.SaveTheQueen”
6. A file is being recorded with a ransom demand in the same folder

   

Based on the use of the native CreateDecryptor function, one of the malware functions seems to contain a decryption mechanism requiring a private key as a parameter.

Ransomware virus NOT encrypts filesstored in directories:
C: windows
C: Program Files
C: Program Files (x86)
C: Users \ AppData
C: inetpub
Also he DOES NOT encrypt the following file types:EXE, DLL, MSI, ISO, SYS, CAB.

Summary and Conclusions

Despite the fact that the ransomware virus itself did not contain any unusual functions, the attacker creatively used Active Directory to distribute the dropper, and the malware itself provided us with interesting, albeit not complicated, obstacles
during analysis.

We think the author of the malware is:

1. I wrote a ransomware virus with a built-in implementation in the winlogon.exe process, as well as
   file encryption and decryption functionality
2. Disguised the malicious code using ConfuserEx, converted the result using Donut and additionally hid the base64 Gzip dropper
3. Got elevated privileges in the victim’s domain and used them to copy
   encrypted malware and scheduled tasks in the network folder of the SYSVOL domain controllers
4. Launched a PowerShell script on domain devices to spread malware and write attack progress to logs in SYSVOL

If you have questions about this version of the ransomware virus, or any other forensics and investigation of information security incidents done by our teams, Contact us or request live attack response demowhere we always answer questions within the Q&A session.