![](http://content.invisioncic.com/l296857/monthly_2024_05/1024px-Kaspersky_Lab_logo_svg.thumb.png.8ea5e40a0a15d24bf2eceb4ec491bbbc.png)
BitLocker: A Tool for Ransomware Attacks
In recent years, ransomware attacks have evolved in both sophistication and impact, with cybercriminals continuously refining their methods to maximize disruption and profit. One alarming trend is the misuse of BitLocker, a legitimate encryption tool developed by Microsoft, to carry out ransomware attacks.
BitLocker is designed to protect data by encrypting entire volumes on a disk, ensuring that unauthorized users cannot access the information without the proper decryption key. While its intended use is to enhance security for individuals and organizations, cybercriminals have found a way to weaponize BitLocker against its users.
How Cybercriminals Exploit BitLocker
-
Initial Access: Attackers typically gain initial access to a target system through phishing emails, malicious downloads, or exploiting vulnerabilities in software. Once inside, they escalate their privileges to gain administrative control over the system.
-
Deployment of BitLocker: With administrative access, the attackers enable BitLocker on the victim's system or specific drives. By doing so, they encrypt the victim's data, rendering it inaccessible without the recovery key.
-
Ransom Demand: After successfully encrypting the data, the attackers leave a ransom note demanding payment, usually in cryptocurrency, in exchange for the decryption key. The victims are often given a short timeframe to comply, with the threat of data being permanently lost or leaked if the ransom is not paid.
Why BitLocker?
- Legitimacy: As a built-in feature of Windows, BitLocker is not flagged as malicious by antivirus software, allowing attackers to use it without raising immediate suspicion.
- Effectiveness: BitLocker’s strong encryption is effective at locking out users from their own data, ensuring that even advanced recovery techniques might not bypass it without the decryption key.
- Cost-Efficient: Attackers do not need to develop or deploy custom ransomware; they leverage existing software capabilities to achieve their goals.
Mitigation Strategies
To protect against BitLocker-based ransomware attacks, organizations and individuals should implement several key security practices:
- Regular Backups: Maintain regular, offline backups of critical data to ensure recovery without needing to pay the ransom.
- Patch Management: Keep all systems and software updated to protect against known vulnerabilities that could be exploited by attackers.
- Least Privilege Principle: Limit administrative access to only those who absolutely need it, reducing the potential for attackers to gain the necessary privileges to enable BitLocker.
- Security Awareness Training: Educate users about phishing attacks and safe computing practices to reduce the likelihood of initial compromise.
Conclusion
The misuse of BitLocker for ransomware attacks highlights the dual-edged nature of powerful security tools. While BitLocker serves a vital role in data protection, its exploitation by cybercriminals underscores the importance of comprehensive cybersecurity measures. By staying vigilant and proactive, users can mitigate the risk and impact of such sophisticated ransomware attacks.
Shrinkloader Kaspersky's Securelist Article : https://securelist.com/ransomware-abuses-bitlocker/112643/
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.
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.
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:
1
2
3
4
5
6
7
8
9
|
$DriveType_map = @{
0 = 'Unknown'
1 = 'No Root Directory'
2 = 'Removable Disk'
3 = 'Local Disk' This is the DriveType searched by the malware.
4 = 'Network Drive'
5 = 'Compact Disc'
6 = 'RAM Disk'
}
|
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.
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.
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.
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:
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.
By analyzing the malware dynamically, we can confirm the registry changes performed:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
HKLM\SOFTWARE\Policies\Microsoft\FVE\UseTPMPIN: 0x00000002
HKLM\SOFTWARE\Policies\Microsoft\FVE\UseTPMKey: 0x00000002
HKLM\SOFTWARE\Policies\Microsoft\FVE\UseTPMKeyPIN: 0x00000002
HKLM\SOFTWARE\Policies\Microsoft\FVE\EnableNonTPM: 0x00000001
HKLM\SOFTWARE\Policies\Microsoft\FVE\UsePartialEncryptionKey: 0x00000002
HKLM\SOFTWARE\Policies\Microsoft\FVE\UsePIN: 0x00000002
HKLM\SOFTWARE\WOW6432Node\Policies\Microsoft\FVE\UseAdvancedStartup: 0x00000001
HKLM\SOFTWARE\WOW6432Node\Policies\Microsoft\FVE\EnableBDEWithNoTPM: 0x00000001
HKLM\SOFTWARE\WOW6432Node\Policies\Microsoft\FVE\UseTPM: 0x00000002
HKLM\SOFTWARE\WOW6432Node\Policies\Microsoft\FVE\UseTPMPIN: 0x00000002
HKLM\SOFTWARE\WOW6432Node\Policies\Microsoft\FVE\UseTPMKey: 0x00000002
HKLM\SOFTWARE\WOW6432Node\Policies\Microsoft\FVE\UseTPMKeyPIN: 0x00000002
HKLM\SOFTWARE\WOW6432Node\Policies\Microsoft\FVE\EnableNonTPM: 0x00000001
HKLM\SOFTWARE\WOW6432Node\Policies\Microsoft\FVE\UsePartialEncryptionKey: 0x00000002
HKLM\SOFTWARE\WOW6432Node\Policies\Microsoft\FVE\UsePIN: 0x00000002
|
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.
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.
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.
The reason for deleting the default protectors is to avoid the recovery of the keys by the user, as in the example below.
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.
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.
1
2
3
4
5
|
If Len((CreateObject("WScript.Shell").Exec("powershell.exe -Command ""$protectors = (Get-BitLockerVolume -MountPoint " & drives(i) & ").KeyProtector; if ($protectors -ne $null) { foreach ($protector in $protectors) { Remove-BitLockerKeyProtector -MountPoint " & drives(i) & " -KeyProtectorId $protector.KeyProtectorId } }""")).stdout.readall) > 0 Then: End If
If Len((CreateObject("WScript.Shell").Exec("powershell.exe -Command $a=ConvertTo-SecureString " & Chr(34) & Chr(39) & strRandom & Chr(39) & Chr(34) & " -asplaintext -force;Enable-BitLocker " & drives(i) & " -s -qe -pwp -pw $a")).stdout.readall) > 0 Then: End If
If Len((CreateObject("WScript.Shell").Exec("powershell.exe -Command Resume-BitLocker -MountPoint " & drives(i) & " ")).stdout.readall) > 0 Then: End If
|
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.
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.
The script also contains a loop that tries to send the information to the attacker five times if an error occurs.
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.
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
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.
1
2
3
4
5
6
|
If Len((CreateObject("WScript.Shell").Exec("wevtutil cl ""Windows PowerShell""")).stdout.readall) > 0 Then: End If
If Len((CreateObject("WScript.Shell").Exec("wevtutil cl ""Microsoft-Windows-PowerShell/Operational""")).stdout.readall) > 0 Then: End If
If Len((CreateObject("WScript.Shell").Exec("netsh advfirewall set allprofiles state on")).stdout.readall) > 0 Then: End If
If Len((CreateObject("WScript.Shell").Exec("netsh advfirewall firewall delet rule name=all")).stdout.readall) > 0 Then: End If
If Len((CreateObject("WScript.Shell").Exec("schtasks /Delete /TN ""VolumeInit"" /F")).stdout.readall) > 0 Then: End If
If Len((CreateObject("WScript.Shell").Exec("schtasks /Delete /TN ""VolumeCheck"" /F")).stdout.readall) > 0 Then: End If
|
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”.
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.
Tactic | Technique | ID |
Execution | Command and Scripting Interpreter: Visual Basic | T1059.005 |
Execution | Windows Management Instrumentation | T1047 |
Execution | Command and Scripting Interpreter: PowerShell | T1059.001 |
Impact | Data Encrypted for Impact | T1486 |
Impact | System Shutdown/Reboot | T1529 |
Defense evasion | Clear Windows Event Logs | T1070.001 |
Defense evasion | Modify Registry | T1112 |
Defense Evasion | Disable or Modify System Firewall | T1562.004 |
Exfiltration | Exfiltration Over Web Service | T1041 |
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.
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.
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
Recommended Comments
There are no comments to display.
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now