09/05/2024 | News release | Distributed by Public on 09/05/2024 11:38
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.
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:
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
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
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
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
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
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
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:
Figure 12: Defense Evasion - Indicator Removal
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. |
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
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
SHA256 | Description |
d4f2c5b21e96cfef0fc4e5acb6bde30113d1c8c7522f35d99102de886ed337b3 | ShrinkLocker |
32f31b35179bbff9ca9dd21b43bfc3e585baafedde523bd3e4869400ab0362cb | ShrinkLocker |
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.
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.
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.