Updated, July 24: This article has been updated with further information on the encryption method used by the ransomware and other details of the ransomware itself, as well as a proof-of-concept for decrypting affected files if the password used can be recovered or brute-forced.
Attackers will sometimes use the name of security companies in their malware. While performing a regular search on VirusTotal looking for interesting malware and new ransomware variants using our threat hunting rules this week, a Sophos X-Ops analyst discovered a novel ransomware executable that appears to use “Sophos” in the UI of the panel alerting that files have been encrypted, (shown below) and as the extension (“.sophos”) for encrypted files.
The SophosLabs teams immediately investigated and began work on developing a targeted detection rule for Sophos endpoint security products, but a pre-existing behavioral rule (and Sophos CryptoGuard) blocked the ransomware from causing harm in tests. This targeted detection rule has been released as indicated in “Detections,” below.
The ransomware executable itself, compiled using MinGW and containing linked Rust libraries, is unusually retro in terms of the functionality it appears to have. In most contemporary ransomware incidents, the threat actors who build the ransomware make a tool that is explicitly and exclusively made for the purpose of encrypting files, without including a lot of other functionality. Most ransomware we deal with today is a single-purpose executable that doesn’t bring many, or any, additional capabilities.
By all indications, the VirusTotal records on these files seem to indicate, and our analysis confirms, that one of the samples has the capability to do many things beyond encrypting files, which is unusual. The ransomware also seems to emphasize methods for the target to communicate with the attacker that most ransomware groups no longer use: email, and the Jabber instant messenger platform.
In fact, the capabilities of one of these files falls closer to a general-purpose remote access trojan (RAT) with the capacity to encrypt files and generate these ransom notes, than to a contemporary ransomware executable. Those capabilities include hooking the keyboard driver for keystroke logging and profiling the system using WMI commands. Like many other ransomware, it excludes a list of directories that would either impede the system from booting or that contain unimportant files if they were encrypted. The ransomware also checks the language settings on the system and refuses to run if it is set to use the Russian language.
The other known sample has fewer of these non-ransomware features. However, both of them connect over the internet to a command-and-control server address. The connection references an address on the Tor (.onion) dark web, but the ransomware samples we analyzed do not actually make a Tor connection.
In addition, both samples contain a hardcoded IP address (one we did see the samples connect to). The address has been associated for more than a year with both Cobalt Strike command-and-control and automated attacks that attempt to infect internet-facing computers with cryptomining software.
Console ransomware application
Both samples are intended to be executed in the Windows command line. When executed in the Windows Command Prompt application, the ransomware prompts the user (“user” here means the criminal who is deploying the ransomware, not the owner of the computer) to enter a string of information that configures its behavior and the contents of the ransom note it eventually drops.
The program prompts the person running it to enter a “password encrypted (32 characters)” followed by a “token,” an email address and a Jabber instant messaging account address. After the user enters that information, the program prompts the user to select an option to (1) encrypt all files on the hard drive, (2) encrypt a single drive letter, or (3) to quit the program.
If the user chooses either the “single” or “all” options, when the ransomware completes the encrypting task, it renames the encrypted files using the “token” value in the renamed filename. The email address and Jabber address get added to the ransom note, which is an HTML Application (.hta file) dropped into any directory where encryption has taken place.
The .hta file simply displays the ransom note, customized with the email address and other information the attacker provided at the start of the attack.
The .hta contains the embedded email/Jabber ID information.
The ransomware appends a unique machine identifier, the email address entered during setup, and the suffix “.sophos” to every file it encrypts at the end of the process.
If the encryption process is stopped before it is complete, the ransomware does not leave a ransom note behind or change the wallpaper image to the one it retrieves from the public image server.
The ransomware also retrieves a graphic from a public image library website, and uses that to change the Windows desktop wallpaper to a screen which reads “Sophos.” It’s notable that this does not replicate Sophos logos, colors, or branding but instead presents a green padlock logo and instructions on how the target can find and use the ransom note to contact the attackers.
The ransomware’s file icon appears to match the padlock icon used in the wallpaper graphic shown at the top of the article.
When run in the console, the ransomware outputs a long list of what appears to be debug logging, reporting the time it took to encrypt each file it finds, in milliseconds.
The testing of the ransomware also revealed that the ransomware attempts to validate the user’s permission to use the ransomware when it is run on a computer connected to the internet. In our tests, the ransomware also was capable of performing encryption tasks when it was run on a computer not connected to the internet.
Ransomware that checks its own validity
The ransomware executables’ Properties sheets show that they are versions 0.0.8 and 0.0.9, respectively, of the program. Neither executable is signed, and both prompt for elevation via UAC when executed.
The initial behavior of the ransomware is for the user (again, “user” means criminal) to enter a “token.” The ransomware performs a minor bit of system profiling on the computer, retrieves the public IP address for the target’s network, and performs an HTTP POST request to the IP address 22.214.171.124 on port 21119/tcp that transmits the token, and profiling information about the computer. The session is not encrypted.
If the “token” value is not acceptable to the server, the application outputs the error message “Your token is not valid!” in the console, and the application quits. However, if the ransomware is run on an offline computer disconnected from the internet, the ransomware displays “Local use of the program” and it proceeds to function, prompting the user to enter a 32-byte password, the contact information that gets embedded into the ransom note and appended to each filename, and it proceeds to begin encrypting.
Looking at the encryption code
Examining the latest version of the malware (version 0.0.9), we found that it embeds a Rust AES encryption library (libaes) and uses AES-256 in cipher-block-chaining (CBC) mode. The initialization vector is hard coded into the malware binary (highlighted in yellow in the screen shot below).
The encryption key is the 32-character password that is input at a command prompt when the malware is executed. The malware code performs a SHA-256 hash of the password and saves the hash for use as digital signature check to be added to each encrypted file.
The malware also has a list of folders and file extensions to skip during encryption, and a list of processes to kill. None of the folder names, file extensions or process lists are obfuscated in any way.
Folders to skip
File extensions to skip
Processes to kill
Folders to skip
File extensions to skip
Processes to kill
‘Documents and Settings’
‘System Volume Information’
‘Program Files (x86)’
After generating the encryption key but before attempting to encrypt files, the malware:
Tries to kill all process from its hardcoded list.
Tries to delete the recycler bin by using ‘cmd /Crd /s /q %systemdrive%$Recycle.bin’
Look for network drives.
Then it begins the file encryption process. The 32-character password entered when the malware is launched is used as the AES key for all files encrypted on the targeted system. Most ransomware code generates new session keys for each file, in order to make file recovery more difficult.
The encryption method varies depending on the size of the file being encrypted. For files smaller than 6.4 megabytes, the malware creates a new file, writes the SHA256 value of the key at the beginning of the file, and then reads the file to encrypt in chunks of 0x100000 bytes. It encrypts each chunk using AES-256 in CBC mode, appending the result to the newly created file. When complete, it deletes the original file.
For bigger files, instead of creating a new file, the malware modifies the original file. It reads the file in chunks of 0x320000 bytes for encryption, replacing the original content, and then appends the SHA256 of the key at the end of the file.
A prototype of the decryption process
Because the encryption process uses a single key (which is the provided password), decrypting files is straightforward—if you know what the password is. Below is Python code for a simple script to decrypt a file when the password is known.
from malduck import aes
from hashlib import sha256
# arg 1 is password
# arg 2 is filename to decrypt
# arg 3 is outputfile
data = open(sys.argv,”rb”).read()
key = bytes(sys.argv,”utf-8″)
IV = b”wA3XnNVGS1NJ72eI”
if len(data) < 6400000:
sig = data[:32]
data = data[32:]
sig = data[-32:]
data = data[:-32]
m = sha256()
if m.digest() == sig:
For example, the file openssh.zip was encrypted using the malware with the password “22222222222222222222222222222222”. To decrypt using the Python script above (saved as decrypt.py), the following command line is used:
python decrypt.py 22222222222222222222222222222222 “openssh.zip.[[CLAcwPCc]].[[email@example.com]].sophos” openssh.zip
Sophos Intercept X products will block the execution and malicious behaviors of this ransomware using the following signatures:
CryptoGuard – Proactively blocks ransomware encryption attempts at runtime based on engine released May, 2017.
Impact_6a – Runtime behavioral detection blocking the malicious activity at the Impact stage published October, 2020.
Troj/Ransom-GXS – Pre-execution anti-malware detection of the malicious file published July 18, 2023
Mal/Generic-R – reputation detection preventing the execution of the malware, published July 17, 2023
Reputation-based detection for C2 IP – Blocks access to 126.96.36.199, the C2 associated with the malware, published July 18, 2023
These samples have only been observed in a public malware repository but have not been seen in use by an attacker. Sophos will continue to monitor for the use of this ransomware in the wild.
Sophos has published a Knowledge Base article addressing this ransomware. X-Ops has published IOCs relating to this malware on the SophosLabs Github.
Sophos X-Ops would like to acknowledge the assistance of Yusuf Arsan Polat, Anand Ajjan, Steeve Gaudreault, and Ronny Tijink for their assistance identifying and analyzing the samples. SophosLabs also thanks @malwrhunterteam for alerting us about this.