ShrinkLocker: Turning BitLocker into ransomware

Introduction

Attackers always find creative ways to bypass defensive features and accomplish their goals. This can be done with packers, crypters, and code obfuscation. However, one of the best ways of evading detection, as well as maximizing compatibility, is to use the operating system’s own features. In the context of ransomware threats, one notable example is leveraging exported functions present in the cryptography DLL ADVAPI32.dll, such as CryptAcquireContextA, CryptEncrypt, and CryptDecrypt. In this way, the adversaries can make sure that the malware can run and simulate normal behavior in various versions of the OS that support this DLL.

Although this seems smart enough, another clever technique caught our attention in a recent incident response engagement: using the native BitLocker feature to encrypt entire volumes and stealing the decryption key. The original purpose of BitLocker is to address the risks of data theft or exposure from lost, stolen, or improperly decommissioned devices. Nonetheless, threat actors have found out that this mechanism can be repurposed for malicious ends to great effect.

In that incident, the attackers were able to deploy and run an advanced VBS script that took advantage of BitLocker for unauthorized file encryption. We spotted this script and its modified versions in Mexico, Indonesia, and Jordan. In the sections below, we analyze in detail the malicious code obtained during our incident response effort and provide tips for mitigating this kind of threat.

This is not the first time we have seen BitLocker used for encrypting drives and demanding a ransom. Previously, attackers used this Microsoft utility to encrypt critical systems after accessing and controlling these. In this case, however, the adversary took additional steps to maximize the damage from the attack and hinder an effective response to the incident.

VBScript analysis

One interesting fact is that the attackers did not bother to obfuscate the bulk of the code, as threat actors typically do. The most plausible explanation for this is that they already had full control of the target system when the script was executed. It is stored at C:\ProgramData\Microsoft\Windows\Templates\ as Disk.vbs. Its first lines contain a function that converts a string to its binary representation using an ADODB.Stream object. This function is later used for encoding data to be sent in an HTTP POST request.

Stream_StringToBinary function

The first step by the main function of the script is to use Windows Management Instrumentation (WMI) to query information about the operating system with the help of the Win32_OperatingSystem class. For each object within the query results, the script checks if the current domain is different from the target. If it is, the script finishes automatically. After that, it checks if the name of the operating system contains “xp”, “2000”, “2003”, or “vista”, and if the Windows version matches any one of these, the script finishes automatically and deletes itself.

Initial conditions for execution

After that, the script continues to rely on WMI for querying information about the OS. It then performs disk resizing operations, which may vary with the result of the OS version check. These operations are performed solely on fixed drives (DriveType = 3). The following drive types typically exist in a file system:

The likely reason the malware does not try to perform same operations on network drives (DriveType = 4) is to avoid triggering detection tools on the network.

To resize local drives in Windows Server 2008 or 2012, the script checks the primary boot partition and saves this information. It saves the index of the different partitions and then performs the following actions using diskpart:

• Shrink the size of each non-boot partition by 100 MB. This creates 100 MB in unallocated space in each partition other than the boot volume;
• Split the unallocated space into new 100 MB primary partitions;
• Format the partitions with the override option, which forces the volume to dismount first if necessary, and assigns a file system and a drive letter to each;
• Activate the partitions;
• If the shrink procedure was successful, save “ok” as a variable, so the script can continue.

Disk resizing operations performed by the script in Windows Server 2008 and 2012

If the operation is successful, the code uses the utility bcdboot and the drive letter saved previously as a boot volume to reinstall the boot files on the new primary partitions.

Boot files reinstall

The partition shrink operations for other OS versions are similar but implemented with a different piece of code for compatibility reasons. The example below shows the process as applied to the Windows versions 7, 8, and 8.1.

Disk resizing operations in the Windows versions 7, 8, or 8.1

For Windows 2008 or 7, after the partition shrink procedure finishes, the variable matchedDrives saves the drive letters separated by commas, but only if the file system is NFTS, exFAT, FAT32, ReFS, or FAT. The code was modified to print an example:

matchedDrives variable data

The script then adds the following registry entries:

• fDenyTSConnections = 1: disables RDP connections;
• scforceoption = 1: enforces smart card authentication;
• UseAdvancedStartup = 1: requires the use of the BitLocker PIN for pre-boot authentication;
• EnableBDEWithNoTPM = 1: allows BitLocker without a compatible TPM chip;
• UseTPM = 2: allows the use of TPM if available;
• UseTPMPIN = 2: allows the use of a startup PIN with TPM if available;
• UseTPMKey = 2: allows the use of a startup key with TPM if available;
• UseTPMKeyPIN = 2: allows the use of a startup key and PIN with TPM if available;
• EnableNonTPM = 1: allows BitLocker without a compatible TPM chip, requires a password or startup key on a USB flash drive;
• UsePartialEncryptionKey = 2: requires the use of a startup key with TPM;
• UsePIN = 2: requires the use of a startup PIN with TPM.

If the script detects an error, it restarts the system.

Registry modifications

By analyzing the malware dynamically, we can confirm the registry changes performed:

Interestingly enough, there are several functions performing these operations, each designed for a different version of Windows. In some conditionals, it checks if BitLocker Drive Encryption Tools are active through the ID 266 of Remote Server Administration Tools. The malware then checks if the BitLocker Drive Encryption Service (BDESVC) is running. If not, it starts the service.

BDESVC verification

The script also changes the label of the new boot partitions to the attacker’s email as shown in the images below, so the victim can contact them.

Drive label modification

Attacker’s email as a drive label

After that, the malware disables the protectors used to secure BitLocker’s encryption key and deletes them. The deletion method may vary depending on the version of the OS. In a Windows Server 2008 or Windows 7 scenario, this is accomplished via VBS features, after which the script uses PowerShell to force the deletion of the protectors.

Having completed the deletion, it enables the use of a numerical password as a protector and the encryption feature.

Protectors deletion

The reason for deleting the default protectors is to avoid the recovery of the keys by the user, as in the example below.

The recovery of BitLocker keys

As the next step, the 64-character encryption key is generated by the malware using a random multiplication and replacement of the following elements:

• A variable with the numbers 0–9;
• The famous pangram, “The quick brown fox jumps over the lazy dog”, in lowercase and uppercase, which contains every letter of the English alphabet;
• Special characters.

The randomness of this password is accomplished by a seed made of various elements of the affected system, such as used memory and network statistics. Later, this information is sent to the attacker. We tested the key generation logic in our environment, and with a slight modification of the script, we were able to see the generated password.

Key generation process

The code then converts the previously generated encryption key to a secure string—a PowerShell option that prevents creating a string object in memory—and effectively enables BitLocker on the drives.

The script then creates an HTTP POST request object using the following options:

• Use WinHTTP version 5.1.
• Accept the French language.
• Ignore SSL errors (httpRequest.Option(4) = 13056 à WinHttpRequestOption_SslErrorIgnoreFlags).
• Disable redirects (httpRequest.Option(6) = false à WinHttpRequestOption_EnableRedirects).

The attackers used the domain trycloudflare.com to obfuscate their real address. This domain is legitimate, it belongs to CloudFlare and is used to provide quick tunnels for developers. The subdomain configured by the attackers was scottish-agreement-laundry-further.

Request creation

The malware also includes information about the machine and the generated password as a payload for the POST request, as shown in the image below.

Information to be sent in the POST request

The script also contains a loop that tries to send the information to the attacker five times if an error occurs.

Retry procedure

With some tweaks, we were able to print the data being sent to the attacker, as shown in the image below. Note that the data includes the computer name, Windows version, drives affected, and the password string. Consequently, the victim’s IP address will also be logged on the attacker’s server, allowing them to track each victim.

Information to be sent

After removing the BitLocker protectors and configuring drive encryption, the script goes through the following steps to cover its tracks.

It validates if the hostname is the target of this malware, then deletes the files:

• \Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\MACHINE\Preferences\ScheduledTasks\ScheduledTasks.xml
• \scripts\Login.vbs
• \scripts\Disk.vbs
• C:\ProgramData\Microsoft\Windows\Templates\Disk.vbs

Delete operations

The script then clears the Windows PowerShell and Microsoft-Windows-PowerShell/Operational logs with wevtutil. It turns on the system firewall and deletes all of its rules. It also deletes the tasks VolumeInit and VolumeCheck. Finally, the malware performs a forced shutdown.

After the shutdown, the victim will see the BitLocker screen. If the user tries to use the recovery options, they will see nothing but the message, “There are no more BitLocker recovery options on your PC”.

BitLocker recovery screen

Tactics, techniques and procedures

The analysis showed that this threat actor has an extensive understanding of the VBScript language, and Windows internals and utilities, such as WMI, diskpart, and bcdboot. Below are the TTPs identified for this scenario.

Artifacts and digital forensics

As the local activity performed by the script includes cleaning up its traces, clearing some logs and the tasks created for execution, and finally, encrypting the whole drive, it was not easy to get forensic artifacts to identify the malicious activities and to find opportunities for decryption.

Fortunately, some of the script content and commands executed were registered and logged by a third-party service, and these were collected for analysis. This allowed us to obtain the secure strings to which the encryption keys were converted from some of the affected systems.

Secure strings obtained

Elsewhere, we attempted to collect network logs where the POST requests to the C2 were stored. However, the most common configuration for web activity logging includes GET but unfortunately not POST requests.

We did finally obtain the POST requests, but this was very challenging. The case provides justification for logging POST traffic and ensuring that all critical system activity is forwarded to a central repository with enough space for storing data for the recommended retention period (six or more months) to avoid losing evidence after attackers remove all their traces from the individual systems.

Finally, some systems in the customer’s infrastructure remained unencrypted and were considered unaffected at first. However, we later found out that they had, in fact, been affected, but BitLocker was not configured in these systems. This made it possible for us to obtain the script itself, analyze its behavior and collect further evidence.

Recovery

While we could obtain some of the passphrases and fixed values implemented by the threat actor to create the encryption keys, the script includes some variable values and those are different for each single affected system, making the decryption process difficult.

Network information collected for use in the seed

Mitigations

Companies are encouraged to use BitLocker or other encryption tools (such as VeraCrypt) to protect corporate secrets. However, a few precautions must be taken to avoid the abuse by attackers.

• Use robust, properly configured EPP solution to detect threats that try to abuse BitLocker;
• Implement Managed Detection and Response (MDR) to proactively scan for threats;
• If BitLocker is enabled, make sure you are using a strong password and have the recovery keys stored in a secure location;
• Ensure that users have only minimal privileges. This way, they cannot enable encryption features or change registry keys on their own;
• Enable network traffic logging and monitoring. Configure the logging of both GET and POST requests. In case of infection, the requests made to the attacker’s domain may contain passwords or keys;
• Monitor for events associated with VBS execution and PowerShell, and save the logged scripts and commands to an external repository storing activity that may be deleted locally;
• Make backups frequently, store them offline, and test them.

If you need assistance with investigation of a ransomware attack and recovering encrypted data, please contact us at gert@kaspersky.com.

Conclusion

Our incident response and malware analysis are evidence that attackers are constantly refining their tactics to evade detection. In this incident, we observed the abuse of the native BitLocker feature for unauthorized data encryption. The VBS script demonstrates that the malicious actor involved in this attack have an excellent understanding of Windows internals. Although the script analysis was not complicated at all, this kind of threat is difficult to detect, since unique strings inside the artifact can be easily modified to bypass YARA rules. Therefore, the best detection method in scenarios like these is behavioral analysis, which correlates different actions performed by the application to reach a verdict.

Kaspersky products detect the threat described in this article with the following verdicts:

• Trojan.VBS.SAgent.gen;
• Trojan-Ransom.VBS.BitLock.gen;
• Trojan.Win32.Generic.

Indicators of compromise

URLs:
hxxps://scottish-agreement-laundry-further[dot]trycloudflare[dot]com/updatelog
hxxps://generated-eating-meals-top[dot]trycloudflare.com/updatelog
hxxps://generated-eating-meals-top[dot]trycloudflare.com/updatelogead
hxxps://earthquake-js-westminster-searched[dot]trycloudflare.com:443/updatelog

E-mail addresses:
onboardingbinder[at]proton[dot]me
conspiracyid9[at]protonmail[dot]com

MD5 hashes:
842f7b1c425c5cf41aed9df63888e768