Anatomy of a SolidBit Ransomware Attack

Appearing as a relatively new ransomware threat, only active since roughly July 2022, the root of SolidBit can be traced to a family of ransomware builders that have been through a number of iterations and name changes since being first observed in June 2021.

Potentially working with the developer of these earlier ransomware builders, or simply adapting the source code to rebrand it for themselves, SolidBit has also gained attention for mimicking elements of the infamous LockBit ransomware threat, including seemingly 'copying and pasting elements from their victim's chat site to a malicious site, albeit with a subtle color change.

While early indications suggest SolidBit has been indiscriminately targeting individuals with Trojanized applications, more recent posts on cybercrime forums indicate that the ransomware operators are attempting to work with affiliates that have intrusion skills which could potentially expand the threat's reach to enterprise environments.

As such, this article details what is known of the SolidBit threat as of publication date, along with common indicators of compromise of the ransomware.

Origin

It is unclear if the original developer of Yashma ransomware is involved in this SolidBit variant or if malicious actors acquired and modified the original source code. Regardless, the origin of this new threat was confirmed as Yashma in a forum post (Figure 1), alongside limited details of additional features.

Figure 1 - SolidBit confirmed their ransomware was a variant of Yashma.

How it works

Building upon previous variants, SolidBit claims to have added the ability to encrypt data on network shares and removable storage, both of which are expected capabilities for any modern ransomware threat, especially those targeting enterprise environments with valuable data less likely to be stored on local fixed disks.

One somewhat novel feature introduced by SolidBit is the registration of the .solidbit file extension that results in encrypted files having their original icon replaced with a green padlock icon (Figure 2). A ransom note (Figure 3) is displayed if the victim attempts to open the file.

Figure 2 – .solidbit file icon

Figure 3 – A ransom note is displayed when opening an encrypted file.

Future suggested capabilities of SolidBit include the ability to bypass Windows User Account Control (UAC), which allows privilege escalation and provides the means to propagate over the network, both of which are again indicative of a shift toward targeting more lucrative enterprise environments rather than individual home users.

Much like earlier variants, SolidBit continues to have a .NET codebase and unsurprisingly makes use of off-the-shelf code obfuscation tools to complicate analysis. Notably, unlike earlier observed Yashma and Chaos variants, our analysis identified the use of a seemingly old tool named "DeepSea Obfuscator 4.0" rather than the previously used .NET "Confuser."

Deobfuscation of recent SolidBit samples reveals an interesting compiler artifact and namespace (Figure 4) within the .NET code that appears to make reference to Eli Cohen[1], an Egyptian-born Israeli spy, who used the alias Kamel Amin Thaabet when conducting espionage operations in Syria.

Figure 4 – KamelAmenThaabet namespace

This same reference is also present within a compiler artifact that indicates that the name was used for the ransomware project:

    C:\Users\User\Desktop\kamel\KamelAmenThaabet\bin\Debug\Obfuscated\Solidbit.pdb

It's important not to jump to any assumptions or conclusions as to who is behind this or where this originated; artifacts such as these often prove more useful in identifying additional samples rather than identifying those responsible.

A telegram identity linked to SolidBit used a profile picture from the Netflix show "Money Heist" and, given the fact that the story of Eli Cohen was dramatized in the Netflix show '"The Impossible Spy," this leads some to the conclusion that SolidBit may use Netflix programming as inspiration for their aliases and identifiers.

Delivery

Initial observations indicate that SolidBit adopted an indiscriminate Trojan delivery method, masquerading as questionable tools hosted on GitHub. Unsuspecting victims would then download and execute these tools, leading to their files being encrypted.

Reportedly zeroing in on gamers and social media users, these initial lures appear to target low-sophistication threat actors — often dubbed script kiddies or skids — because of the more obvious payload filenames, including terms such as "account checker" and "social hacker."

SolidBit has shown intent to operate as a ransomware-as-a-service (RaaS) threat, initially offering access to the ransomware builder, decrypter, and TOR-based control panel for $200 (Figure 5), later reduced to $100.

Figure 5 – SolidBit RaaS message

Some forum members responded to this thread but the actual number of affiliate positions filled cannot be determined. It's also unclear as to how the minimal ransom payment may be processed and split, unlike other more established RaaS players who recruit suitably skilled affiliates with the more organized promise of huge dividends.

Interestingly, the telegram contact in the affiliate forum post displays the profile picture history (Figure 6) and anecdotally suggests some association or use of RedLine Stealer, a standalone and malware-as-a-service threat that collects credentials, cryptocurrency, and payment card data from compromised hosts while providing backdoor and payload delivery capabilities.

Figure 6 – Telegram profile picture history

Although there is nothing to link the two malware families together, it is possible that those behind SolidBit could use commodity threats such as stealers to gather credentials prior to delivering and executing their ransomware payload.

Initial execution

Potential anti-debugger check

Potentially as an anti-debugging countermeasure, SolidBit queries the Windows Registry (Figure 7) to seemingly determine if the Microsoft Visual Studio .NET just-in-time (JIT) debugger is configured, presumably allowing the ransomware to terminate should it suspect that it is under analysis.

Figure 7 – Potential anti-debug check via the Windows Registry

Mutex

When SolidBit is executed, a mutual exclusion object (mutex) is created using a hard-coded MD5 hash of the string "solid" (Figure 8).

Figure 8 – MD5 hash of "solid" mutex [2]

This ensures that only one instance of the ransomware is running with any subsequent execution being terminated to avoid conflict.

Decryption ID

Once the threat has determined that it can continue execution, a random decryption ID is generated which can be used to later identify the victim if they enter into negotiations with SolidBit via their TOR chat site.

This identifier appears to start with a numeric value followed by a dash and 28 random uppercase alphanumeric characters, and is terminated with k8.

Regex: [0-9]{1,2}-[A-Z0-9]{28}k8

The initial numeric value appears to be hard-coded within the sample (Figure 9) and could potentially signify an affiliate or ransomware-builder version. So far, the values 1-, 5-, and '12- have been observed in the wild.

Figure 9 – Decryption ID generation

Unlike other threats, this identifier is not based on any specific machine identifier and therefore each execution will result in a new identifier being generated.

Persistence

Using the common Windows Registry 'Run' key persistence method, a new value named UpdateTask is created within the 'HKEY_CURRENT_USER' and contains the path to the SolidBit executable.

This ensures the ransomware will automatically execute whenever the victim logs on.

Pre-encryption phase

File list

In preparation for future encryption, SolidBit determines which drives are present on the victim host and then crawls all directories.

Given the need to display the ransom note and have the victim communicate with the threat actor via their Tor-based chat site, the following core system directories and files are excluded from the encryption process so that the compromised host can continue to function:

• $Recycle.Bin
• AMD
• appdata\local
• appdata\locallow
• autorun.inf
• boot.ini
• boot.ini
• bootfont.bin
• bootmgfw.efi
• bootsect.bak
• desktop.ini
• Documents and Settings
• iconcache.db
• Intel
• MSOCache
• ntuser.dat
• ntuser.dat.log
• ntuser.ini
• NVIDIA
• PerfLogs
• Program Files
• Program Files (x86)
• ProgramData
• thumbs.db
• users\all users
• Windows
• Windows.old

Service termination

Using a list that is consistent across many modern ransomware threats, attempts are made to stop any Windows Service matching the following names to ensure that application data files are not "locked" open, all while also attempting to evade detection and disrupt data recovery efforts:

• AcronisAgent
• AcrSch2Svc
• backup
• BackupExecAgentAccelerator
• BackupExecAgentBrowser
• BackupExecDiveciMediaService
• BackupExecJobEngine
• BackupExecManagementService
• BackupExecRPCService
• BackupExecVSSProvider
• CAARCUpdateSvc
• CASAD2DWebSvc
• ccEvtMgr
• DefWatch
• GxBlr
• GxCIMgr
• GxCVD
• GxFWD
• GxVss
• Intuit.QuickBooks.FCS
• memtas
• PDVFSService
• QBCFMonitorService
• QBFCService
• RTVscan
• SavRoam
• sophos
• sql
• stc_raw_agent
• svc$
• TeamViewer
• veeam
• VeeamDeploymentService
• VeeamNFSSvc
• VeeamTransportSvc
• VSNAPVSS
• vss
• YooBackup
• YooIT
• zhudongfangy

As to be expected from a modern ransomware threat, the native Windows commands below are executed to further complicate recovery efforts prior to commencing the file encryption process:

vssadmin delete shadows /all /quiet & wmic shadowcopy delete

bcdedit /set {default} bootstatuspolicy ignoreallfailures &
bcdedit /set {default} recoveryenabled no

wbadmin delete catalog -quiet

File type association

As previously mentioned, SolidBit includes a somewhat novel feature in which the .solidbit file extension is associated with the ransomware executable so that each encrypted file has a padlock icon and the victim is presented with the ransom note should they attempt to open any encrypted file.

In support of this feature, the ransomware executable is copied to the `%APPDATA%` directory and registered alongside the file extension in multiple Windows Registry 'HKEY_CURRENT_USER' locations (detailed in the indicators of compromise section).

Encryption phase

After the initial phases, SolidBit attempts to encrypt each file using AES-256 encryption in cipher block chaining (CBC) mode using a hard-coded RSA public key (Figure 10).

Figure 10 – Hard-coded RSA public key

In an attempt to prevent deleted file recovery, the encryption process reads the original file and writes the encrypted data to a new file with the .solidbit file extension. Once this process is complete, the original file appears to be overwritten and then deleted.

Ransom note

In addition to displaying the ransom note if an encrypted file is opened, a text-based ransom note named RESTORE-MY-FILES.txt is dropped into each folder containing encrypted files (Figure 11).

Figure 11 – Ransom note

Conclusions

While the capabilities of SolidBit are similar to other ransomware threats, and the current delivery method is perhaps less likely to target enterprise users, those responsible appear to have aspirations to shift toward the ransomware-as-a-service (RaaS) model which could encourage affiliates with network intrusion skills to join.

As such, defenders should familiarize themselves with the common tactics, techniques, and procedures being adopted by SolidBit and similar ransomware groups to best protect their environments from attack.

Indicators of compromise

Dropped files

RESTORE-MY-FILES.txt

Executed commands

bcdedit /set {default} bootstatuspolicy ignoreallfailures &
bcdedit /set {default} recoveryenabled no

vssadmin delete shadows /all /quiet & wmic shadowcopy delete

wbadmin delete catalog -quiet

Files (SHA256)

Note: SolidBit ransomware payloads are potentially victim- or affiliate-specific.

0f73ddb9dba894298b468d162f7dd49ae6f49cdc71184b98339d5b1e3eccbb02
4bc5ade40ab56113ce9709c0da15416628e089e838864a6756ceca90b8ffaf5b
46d2eca98c08cba9ed51118bc1c8601d6b902323b9c7b47838502b35a9a9b0a4
63c9e7ec3a191e9ffbfc388a3cf7375693b609f4fd223b3fbcc9d7d21759b1bc
93f6f8e188d36ab7bf04e92d9673c3bcc4af2b56baa0fe98f30d3b05af6378a7
b7625701cb1a94e167bd32989ceb078a430ff4445cb6848b28a85279a5887e70
bc30903638dbe661a8afd6a8f078e68c834e9c3ed706d0ad1b49457e154c4039
eeb0a884d4eabc4f8811ecaa3e37acc8156c52b60a89537c5498df4c0e0c21f7

Registry

HKCU\SOFTWARE\Classes\.solidbit
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\ApplicationAssociationToasts
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.solidbit
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\UpdateTask

Mutex

“solid" - ec03f91ae56e478455e3786e91559194

References