ShrinkLocker Malware: Abusing BitLocker to Lock Your Data

ShrinkLocker is one of newly identified ransomware strains that exploits BitLocker, a legitimate Windows feature, to encrypt targeted volume or data. Unlike typical ransomware that uses custom encryption methods, ShrinkLocker abuses BitLocker to create a secure boot partition, locking users out of their data unless a ransom is paid. This tactic not only complicates decryption efforts but also highlights the evolving methods ransomware developers use to compromise and secure their grip on targeted systems​.

In May 2024, Bleeping Computer and Kaspersky shared blogs showing their analysis for this ransomware strain, offering insights into its operation and impact. Unfortunately, we were unable to obtain the specific samples they analyzed and referenced in their blogs.

However, the Splunk Threat Research Team managed to acquire other samples of ShrinkLocker. Using these samples, we were able to conduct analysis and extract its tactics and techniques. This allowed us to develop and test detection methods that help our customers effectively protect against this evolving threat. Our findings and methodologies are documented in this blog to aid the cybersecurity community in combating ShrinkLocker effectively.

Tactics And Techniques

Reconnaissance

This malware begins its operation by determining the operating system of the compromised or targeted host. It achieves this by executing a Windows Management Instrumentation (WMI) Commandline query: SELECT * FROM Win32_OperatingSystem. The malware then evaluates whether the operating system matches any of the following versions:

• Windows XP
• Windows 2000
• Windows 2003
• Windows Vista

If the operating system is one of the above, the malware proceeds to delete a specific script file located at C:\Programdata\Microsoft\Windows\Templates\disk.vbs.

As illustrated in Figure 01, the two sample variants of this malware exhibit different behaviors. One variant performs an additional check by querying the DomainDNSName of the compromised host using the ADSystemInfo object. This check ensures that the malware is operating within the intended target domain. If the domain name matches the target criteria, the malware proceeds with its malicious activities, otherwise it will exit its main function.

^{Figure 01: OS and DOmainDNSName Checking}

Defense Evasion

Modify Registry (T1112)

As part of its payload, this malware modifies or adds registry entries related to Remote Desktop Protocol (RDP) connections, smart card authentication, and Trusted Platform Module (TPM) settings. These changes are intended to manipulate system configurations to suit the malware's objectives, potentially compromising security measures and data destruction. The chart below lists the specific registry entries that the malware modifies.

Registry Key	Registry Value Data	Description
HKLM\System\CurrentControlSet\Control\Terminal Server \fDenyTSConnections	1	Disables RDP connections
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies \System\scforceoption	1	Enforces Smart Card Authentication
HKLM\SOFTWARE\Policies\Microsoft\FVE\UseAdvancedStartup	1	Requires the BitLocker PIN for Pre-boot authentication, preventing unauthorized users from accessing encrypted drives.
HKLM\SOFTWARE\Policies\Microsoft\FVE \EnableBDEWithNoTPM	1	Allows BitLocker without a compatible Trusted Platform Module (TPM), i.e.: requires a password
HKLM\SOFTWARE\Policies\Microsoft\FVE\UseTPM	2	Uses TPM
HKLM\SOFTWARE\Policies\Microsoft\FVE\UseTPMPIN	2	Allows startup PIN with TPM
HKLM\SOFTWARE\Policies\Microsoft\FVE\UseTPMKey	2	Allows startup key with TPM
HKLM\SOFTWARE\Policies\Microsoft\FVE\UseTPMKeyPIN	2	Allows startup key and PIN with TPM
HKLM\SOFTWARE\Policies\Microsoft\FVE\EnableNonTPM	1	Allows Bitlocker without TPM
HKLM\SOFTWARE\Policies\Microsoft\FVE \UsePartialEncryptionKey	2	Allows startup key with TPM
HKLM\SOFTWARE\Policies\Microsoft\FVE\UsePIN	2	Allows startup PIN with TPM

The code block below illustrates the script code of the ShrinkLocker malware. In addition to modifying the registry entries listed above, it also attempts to install BitLocker using either the ServerManagerCmd command or PowerShell.

# install Bitlocker via ServerManagerCmd
ServerManagerCmd -install BitLocker -allSubFeatures
# install Bitlocker via powershell
powershell.exe -Command Install-WindowsFeature BitLocker -IncludeAllSubFeature -IncludeManagementTools

This technique is unique in that it checks for the object ID of 266, which helps determine if BitLocker feature is enabled:

## checking of bitlocker feature
SELECT * FROM Win32_ServerFeature where ID = 266

_{Figure 02: Registry Modification}

After satisfying its initial conditions for execution, the ShrinkLocker malware performs additional checks on the operating system. Specifically, if it identifies the system as Windows Server 2008 or Windows 7, the malware proceeds to tamper with BitLocker encryption settings by disabling key protectors associated with the encryption keys. This action aims to undermine BitLocker's security measures and facilitate the deletion of encryption keys, thereby compromising the integrity of encrypted data.

_{Figure 03: Deletion of BitLocker Encryption Key}

Impact

Data Encrypted for Impact (T1486)

As part of its data destruction and encryption process, ShrinkLocker checks if the BitLocker Drive Encryption Tools service (BDESVC) is running on the compromised host by using a WMIC query. If the service is not running, ShrinkLocker attempts to start it.

^{Figure 04: BitLocker Service Checking}

Data Destruction (T1485)

Depending on the operating system check, as illustrated in Figure 05 (applicable to either Windows Server 2008 or Windows Server 2012), the ShrinkLocker malware initiates a destructive payload aimed at compromising the data integrity of the host system. If the DriveType is identified as 3 (Fixed Drive), the malware proceeds with the following sequence of actions:

1. Data Destruction Preparation

Initially, ShrinkLocker retrieves and records essential information about the primary boot partition, including the Disk Index. This information is crucial for subsequent operations involving disk resizing.

2. Disk Resizing Process

Using the WMIC query results to identify local or fixed drives, the malware proceeds to shrink each non-boot partition by 100MB using the diskpart utility. This operation creates a 100MB unallocated space partition adjacent to the boot volume.

3. Partition Formatting and Drive Letter Assignment

Upon successful resizing, ShrinkLocker formats the newly allocated partitions and assigns drive letters to facilitate access and potential further manipulation of these partitions.

^{Figure 05: Disk Resizing and Shrinking}

To ensure system bootability after partition modification, the malware employs the BCDBboot utility. It reinstalls the necessary boot files using the previously saved drive letter of the boot volume, thereby configuring the new primary partitions for boot operation.

These actions collectively aim to disrupt system functionality and compromise data integrity on the infected machine. By resizing partitions, creating unallocated space, and reconfiguring boot files, ShrinkLocker seeks to render the system unstable and potentially irreparable, posing significant challenges for recovery and forensic analysis efforts.

^{Figure 06: BCDBoot Setup}

Defacement (T1491)

Figure 07 depicts the code snippet from the ShrinkLocker malware, illustrating how it modifies the disk label on the compromised host. This alteration includes embedding an email address through which the user can potentially contact the attacker to discuss file recovery options.

^{Figure 07: Modify Disk Label}

After modifying the ShrinkLocker malware code, Figure 08 shows the modified disk label in Splunk Attack Range during our analysis and testing.

^{Figure 08: Modify Disk Label}

Exfiltration

Exfiltration Over C2 Channel (T1041)

ShrinkLocker generates a random encryption key using a combination of system parameters from the compromised host, including TotalUsedSpace, TotalFreeSpace, FreeMemory, network information, and current timestamp. Figure 09 illustrates the function employed by ShrinkLocker for generating this encryption key.

^{Figure 09: Generate Encryption Key}

Through modifications of the ShrinkLocker malware code, the Splunk Threat Research Team was able to print one of the potential encryption keys based on the Splunk Attack Range test lab we used during our analysis.

^{Figure 10: Example of Encryption Key}

Figure 11 illustrates how ShrinkLocker utilizes trycloudflare, a free one-time trial Cloudflare domain, as a command and control server (C2). This technique has been utilized since at least August 2023, per BleepingComputer. It sends system information as a beacon along with the encryption key to this domain.

^{Figure 11: C2 Communication}

Indicator Removal (T1070)

After executing its full payload on the compromised host, ShrinkLocker displays a notable defensive measure by attempting to erase its tracks. Figure 12 shows a section of the ShrinkLocker code dedicated to removing various indicators of its presence.

The malware initiates the following actions:

1. Deletion of Windows PowerShell Audit Logs: ShrinkLocker targets and removes logs associated with PowerShell, aiming to obscure any traces of its PowerShell-based activities.
2. Deletion of All Firewall Rules: The malware systematically eliminates all existing firewall rules.
3. Deletion of Scheduled Tasks: Specifically, tasks named 'Disk' and 'Copy' are targeted for deletion. These tasks may have been utilized by ShrinkLocker for regular operations or as part of its persistence mechanism. Removing them helps the malware evade detection and hinder forensic analysis efforts.

^{Figure 12: Defense Evasion - Indicator Removal}

Simulation

The Splunk Threat Research Team has developed tools and Atomic Red Team tests designed to help blue teamers and defenders strengthen their defenses against this type of threat. These atomic simulations are invaluable for ensuring the effectiveness of detection mechanisms and for fine-tuning them to enhance their accuracy.

The use of these atomic tests allows security teams to validate their detection capabilities and identify areas for improvement.

Below is a table listing the atomic tests relevant to this threat:

Atomics	TID	Descriptions
Indicator Removal on Host: Clear Windows Event Logs	T1070.001	Atomic tests that simulate the MITRE ATT&CK tactic of Indicator Removal by clearing Windows event logs.
Delete Firewall Rules via Netsh	T1562.004	netsh advfirewall firewall delete rules.
Delete Scheduled Task/Job	T1053.005	Delete scheduled task.
Disable RDP	T1112	Disable Windows RDP
Enforce Smart Card Authentication	T1112	Enforce Smart Card Authentication Through Registry
Bitlocker, TPM and PIN Registry Configuration	T1112	A series of registry modifications made by ShrinkLocker to prepare the compromised host for deploying its payload.

Security Content

Windows Modify Registry on Smart Card Group Policy

This detection is developed to detect suspicious registry modifications targeting the "scforceoption" key. Altering this key enforces smart card login for all users, potentially disrupting normal access methods. Unauthorized changes to this setting could indicate an attempt to restrict access or force a specific authentication method, possibly signifying malicious intent to manipulate system security protocols.

| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime FROM datamodel=Endpoint.Registry 
  where Registry.registry_path= "*\\Windows\\CurrentVersion\\Policies\\System\\scforceoption*"
Registry.registry_value_data="0x00000001" 
  by Registry.registry_key_name Registry.user Registry.registry_path Registry.registry_value_data Registry.action Registry.dest 
  | `drop_dm_object_name(Registry)` 
  | `security_content_ctime(firstTime)`
  | `security_content_ctime(lastTime)`

^{Figure 13: Smart Card Group Policy Detections}

Windows Modify Registry Configure BitLocker

This detection is developed to detect suspicious registry modifications targeting BitLocker settings. The malware ShrinkLocker alters various registry keys to change how BitLocker handles encryption, potentially bypassing TPM requirements, enabling BitLocker without TPM and enforcing specific startup key and PIN configurations.

| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime FROM datamodel=Endpoint.Registry 
  where (Registry.registry_path= "*\\Policies\\Microsoft\\FVE\\*" Registry.registry_value_name IN("EnableBDEWithNoTPM", "EnableNonTPM", "UseAdvancedStartup") Registry.registry_value_data = 0x00000001) OR
  (Registry.registry_path= "*\\Policies\\Microsoft\\FVE\\*" Registry.registry_value_name IN("UsePIN", "UsePartialEncryptionKey", "UseTPM", "UseTPMKey", "UseTPMKeyPIN", "UseTPMPIN") Registry.registry_value_data = 0x00000002)
  by Registry.registry_key_name Registry.user Registry.registry_path Registry.registry_value_data Registry.action Registry.dest Registry.registry_value_name
  | `drop_dm_object_name(Registry)` 
  | `security_content_ctime(firstTime)`
  | `security_content_ctime(lastTime)`

^{Figure 14: Configure BitLocker Detections}

Windows Modify Registry Disable Remote Desktop Protocol

This detection is developed to detect suspicious registry modifications that disable Remote Desktop Protocol (RDP) by altering the "fDenyTSConnections" key. Changing this key's value to 1 prevents remote connections, which can disrupt remote management and access.

| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime FROM datamodel=Endpoint.Registry 
  where Registry.registry_path= "*\\Control\\Terminal Server\\fDenyTSConnections*" Registry.registry_value_data="0x00000001" 
  by Registry.registry_key_name Registry.user Registry.registry_path Registry.registry_value_data Registry.action Registry.dest 
  | `drop_dm_object_name(Registry)` 
  | `security_content_ctime(firstTime)`
  | `security_content_ctime(lastTime)`

^{Figure 15: Disable RDP Detections}

Suspicious WevUtil Usage

The following detection identifies the usage of wevtutil.exe with parameters for clearing event logs such as Application, Security, Setup, Trace, or System. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line arguments. This activity is significant because clearing event logs can be an attempt to cover tracks after malicious actions, hindering forensic investigations.

| tstats `security_content_summariesonly` values(Processes.process) as process min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes
  where Processes.process_name=wevtutil.exe Processes.process IN ("* cl *", "*clear-log*", "* -cl *") Processes.process IN ("*System*", "*Security*", "*Setup*", "*Application*", "*trace*", "*powershell*")
  by Processes.parent_process_name Processes.parent_process Processes.process Processes.process_guid Processes.process_id Processes.dest Processes.user
  | `drop_dm_object_name(Processes)`
  | `security_content_ctime(firstTime)` 
  |`security_content_ctime(lastTime)` 

^{Figure 16: Suspicious wevtutil Usage Detections}

Scheduled Task Deleted Or Created via CMD

This detection focuses on identifying the creation or deletion of scheduled tasks using the schtasks.exe utility with the corresponding command-line flags (-create or -delete), which could indicate malicious intent or unauthorized system manipulation. This technique has been notably associated with threat actors like Dragonfly and the SUNBURST attack against SolarWinds.

| tstats `security_content_summariesonly` count values(Processes.process)
  as process values(Processes.parent_process) as parent_process min(_time) as firstTime
  max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.process_name=schtasks.exe
  (Processes.process=*delete* OR Processes.process=*create*) by Processes.user Processes.process_name
  Processes.parent_process_name Processes.dest | `drop_dm_object_name(Processes)`
  | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)`

^{Figure 17: Create or Delete Scheduled Tasks Detections}

Windows Delete or Modify System Firewall

The following detection identifies 'netsh' processes that delete or modify firewall configurations. It leverages data from EDR agents, focusing on command-line executions containing specific keywords. This activity is significant because it can indicate malware attempting to alter firewall settings to evade detection or remove traces.

| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes 
  where `process_netsh` Processes.process = "* firewall *" Processes.process = "* del*"
  by Processes.parent_process Processes.parent_process_name Processes.process_name Processes.process_id Processes.process_guid Processes.process Processes.user Processes.dest
  | `drop_dm_object_name("Processes")` 
  | `security_content_ctime(firstTime)` 
  | `security_content_ctime(lastTime)`

^{Figure 18: Delete or Modify System Firewall Detections}

Windows Modify Registry to Add or Modify Firewall Rule

The following detection identifies a potential addition or modification of firewall rules, signaling possible configuration changes or security policy adjustments. It tracks commands such as "netsh advfirewall firewall add rule" and "netsh advfirewall firewall set rule," which may indicate attempts to alter network access controls. Monitoring these actions ensures the integrity of firewall settings and helps prevent unauthorized network access.

| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry 
  WHERE Registry.registry_path= "*\\System\\CurrentControlSet\\Services\\SharedAccess\\Parameters\\FirewallPolicy\\FirewallRules\\*"  Registry.action = modified
  BY _time span=1h Registry.registry_path Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data Registry.process_guid  Registry.dest Registry.user Registry.action
  | `drop_dm_object_name(Registry)`
  | `security_content_ctime(firstTime)` 
  | `security_content_ctime(lastTime)`

^{Figure 19: Add or Modify Firewall Rule Detections}

Wscript Or Cscript Suspicious Child Process

This detection identifies a suspicious spawned process by WScript or CScript process. This technique was commonly used by adversaries and malware to execute different LOLBIN, other scripts like PowerShell or spawn a suspended process to inject its code as a defense evasion. This technique may detect a normal script that uses several application tools that are in the list of the child process it detects, but it can also be a good pivot and indicator that a script may execute suspicious code.

| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time)
  as lastTime from datamodel=Endpoint.Processes where Processes.parent_process_name
  IN ("cscript.exe", "wscript.exe") Processes.process_name IN ("regsvr32.exe", "rundll32.exe","winhlp32.exe","certutil.exe","msbuild.exe","cmd.exe","powershell*","wmic.exe","mshta.exe")
  by Processes.dest Processes.user Processes.parent_process_name Processes.parent_process
  Processes.process_name Processes.process Processes.process_id Processes.parent_process_id
  | `drop_dm_object_name(Processes)`
  | `security_content_ctime(firstTime)`
  | `security_content_ctime(lastTime)`

^{Figure 20: Wscript Or Cscript Suspicious Child Process Detections}

Windows Modify Registry Delete Firewall Rules

The following detection identifies a potential deletion of firewall rules, indicating a possible security breach or unauthorized access attempt. It identifies actions where firewall rules are removed using commands like "netsh advfirewall firewall delete rule," which can expose the network to external threats by disabling critical security measures. Monitoring these activities helps maintain network integrity and prevent malicious attacks.

`sysmon` EventCode=12 TargetObject = "*\\System\\CurrentControlSet\\Services\\SharedAccess\\Parameters\\FirewallPolicy\\FirewallRules\\*" EventType=DeleteValue 
|  rename Computer as dest
|  rename User as user
|  stats count min(_time) as firstTime max(_time) as lastTime by EventCode EventType TargetObject Image user dest
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`

^{Figure 21: Modify Registry to Delete Firewall Rules Detections}

IOC

SHA256	Description
d4f2c5b21e96cfef0fc4e5acb6bde30113d1c8c7522f35d99102de886ed337b3	ShrinkLocker
32f31b35179bbff9ca9dd21b43bfc3e585baafedde523bd3e4869400ab0362cb	ShrinkLocker

Learn More

This blog helps security analysts, blue teamers and Splunk customers identify ShrinkLocker malware by enabling the community to discover related tactics, techniques, and procedures used by threat actors and adversaries. You can implement the detections in this blog using the Enterprise Security Content Updates app or the Splunk Security Essentials app. To view the Splunk Threat Research Team's complete security content repository, visit research.splunk.com.

Feedback

Any feedback or requests? Feel free to put in an issue on Github and we'll follow up. Alternatively, join us on the Slack channel #security-research. Follow these instructions If you need an invitation to our Splunk user groups on Slack.

Contributors

We would like to thank Teoderick Contreras for authoring this post and the entire Splunk Threat Research Team for their contributions: Michael Haag, Jose Hernandez, Lou Stella,Bhavin Patel,Rod Soto, Eric McGinnis, Patrick Bareiss and Gowthamaraj Rajendran.

References

• https://github.com/dsccommunity/xBitlocker/issues/51
• https://securelist.com/ransomware-abuses-bitlocker/112643/

Public link

Please use the above public link if you want to share this noodl on another website.