A new strain of ransomware encrypts files and appends them with the extension, “.SaveTheQueen,” and propagates using the SYSVOL share on Active Directory Domain Controllers.
Our customers encountered this malware recently. Our full analysis results and findings are detailed below.
One of our customers contacted us when they were alerted to a new strain of ransomware that appended a “.SaveTheQueen” extension to newly encrypted files in their environment.
During our investigation, we found that the attacker used the SYSVOL share on the customer’s domain controller to help spread the malware and track infections.
SYSVOL is a crucial folder on each domain controller, used to deliver policy (GPO) and logon scripts to domain workstations. The content of the SYSVOL folder is replicated between the domain controllers to keep data synchronized between organization sites. Writing to SYSVOL requires high domain privileges, however, once compromised, becomes a powerful asset for attackers, who can use it to spread malicious content quickly through the domain.
The Varonis audit trail revealed:
- The infected user created a file named “hourly” on the SYSVOL share
- Many log files were created on the SYSVOL share, each with the name of a device in the domain
- Many different IP addresses accessed the “hourly” file
We concluded that the log files were used to monitor the infection process on new devices, and that the “hourly” file was a scheduled task that ran malware on the new devices using a PowerShell script, samples “v3” and “v4.”
The attacker had likely obtained and used domain admin privileges to write files to SYSVOL. The attacker ran PowerShell code on the infected hosts that created a scheduled task to open, decode and run the malware.
Decoding the Malware
We tried several methods to decode the samples, to no avail.
We were about to give up when we decided to try the “Magic” method from GCHQ’s excellent Cyberchef utility. Magic Tries to guess file encoding by brute force, using known encoding methods and measuring entropy.
Magic detected that the file was GZip under base64, so we were able to decompress the file and discover the injector.
The injector was a simple .NET file without any protection. After reading the source code using DNSpy we understood its sole purpose was to inject shellcode into “winlogon.exe” process.
We used the Hexacorn’s shellcode2exe utility to ‘compile’ the shellcode into an executable to debug and analyze. We then realized that the shellcode worked on both 32-bit and 64-bit machines.
Writing even simple shellcode in native assembly can be difficult; writing full shellcode ransomware that works on 32-bit and 64-bit systems require elite skills, so we started to wonder about the sophistication of the attacker.
When we debugged the compiled shellcode using x64dbg, we noticed it loaded .NET DLLs like clr.dll and mscoreei.dll. That seemed weird – attackers usually try to keep shellcode as small as possible by calling native functions instead of loading them. Why wrap Windows functions inside your shellcode instead of calling them directly?
As it turned out, the author of the malware didn’t write the sophisticated shellcode–they used generic exe2shellcode software.
We found a tool named Donut that looked like could compile similar shellcode (description from GitHub):
Donut generates x86 or x64 shellcode from VBScript, JScript, EXE, DLL (including .NET Assemblies) files. This shellcode can be injected into an arbitrary Windows process for in-memory execution.
To confirm our theory, we compiled our own code using Donut and compared it with the sample – it was a match. From there, we were able to extract and analyze the original .NET executable.
The executable was obfuscated with ConfuserEx:
ConfuserEx is an open-source .NET protector. Protectors allow programmers to protect their code from reverse engineering by using methods like symbol renaming, control flow obfuscation, and method reference hiding. Malware authors use protectors to avoid detection and make reverse engineering harder.
Thanks to ElektroKill Unpacker we unpacked the code:
The Final Payload
The final payload is very plain ransomware. No persistence, no C2 connection–just good old asymmetric encryption to make the victims’ files unreadable.
The Main function takes important strings as parameters:
- The file Extension to use after the encryption (SaveTheQueen)
- The author’s email to be placed inside the ransom note
- The public key used to encrypt the files
The encryption process is as follows:
1.) The malware examines local and mapped drives on the victim’s device
2.) It looks for files to encrypt
3.) It tries to close any process using the file it is trying to encrypt
4.) It renames the file to “<file>.SaveTheQueenING” using MoveFile function and encrypts it.
5.) After the file is encrypted using the author’s public key, the ransom changes its name again to “<file>.SaveTheQueen”
6.) The ransom note file is added to the directory.
Based on the usage of the native “CreateDecryptor” function, one of the malware’s functions appears to contain a decryption mechanism that requires the private key as a parameter.
The ransomware does NOT encrypt files stored in:
- C:\Program Files
- C:\Program Files (x86)
The ransomware does NOT encrypt file types:
- EXE, DLL, MSI, ISO, SYS, CAB
Summary & Conclusions
Though the ransomware does not feature any unusual techniques, the attacker used Active Directory creatively to spread the dropper, and the malware did present interesting hurdles during analysis.
We believe the attackers:
- Wrote the ransomware with the built-in winlogon.exe injection and file encryption functionality
- Obfuscated the malicious code with ConfuserEx, wrapped the obfuscated code with Donut and obfuscated the result with base64 and Gzip
- Obtained elevated privileges on the victim’s domain and used them to copy the encoded malware and the scheduled task to the domain’s SYSVOL share
- Ran PowerShell code on devices in the domain to propagate the malware and log the progress of the attack in SYSVOL
If you have any questions about this variant ransomware or any of the other work our security research team has done, let us know on Twitter, or join our IR team for an attack lab session where we always do live Q&A.