Varonis debuts trailblazing features for securing Salesforce. Learn More

Varonis named a Leader in The Forrester Wave™: Data Security Platforms, Q1 2023

Read the report

Anatomy of a SolidBit Ransomware Attack

6 min read
Last updated Sep 02, 2022


    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.


    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:


    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.


    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


    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.


    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
    • 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:

    Delete volume shadow copies:
    vssadmin delete shadows /all /quiet & wmic shadowcopy delete
    Modify the boot configuration to ignore failres and disable the recovery option:
    bcdedit /set {default} bootstatuspolicy ignoreallfailures &
    bcdedit /set {default} recoveryenabled no
    Delete the backup catalog:
    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


    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


    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.





    “solid" - ec03f91ae56e478455e3786e91559194



    What you should do now

    Below are three ways we can help you begin your journey to reducing data risk at your company:

    1. Schedule a demo session with us, where we can show you around, answer your questions, and help you see if Varonis is right for you.
    2. Download our free report and learn the risks associated with SaaS data exposure.
    3. Share this blog post with someone you know who'd enjoy reading it. Share it with them via email, LinkedIn, Twitter, Reddit, or Facebook.

    Free Data Risk Assessment

    Join 7,000+ organizations that traded data darkness for automated protection. Get started in minutes.