SafePay ransomware is a relatively new breed of double-extortion ransomware that has been in action since the latter half of 2024.
In this blog, we offer an in-depth examination of the SafePay ransomware family, including background information on the malware, technical analysis related to cryptography, persistent mechanisms, code obfuscation, network communications, and corresponding MITRE ATT&CK techniques such as T1059 and T1486, as well information objects and an actual example of how the patented quarantine technology by Xcitium can instantly halt a ransomware attack.
Introduction
SafePay ransomware operates with a “double extortion” tactic where it steals data while encrypting files, making it one of the aggressive new players in the field of extortion on the web. The SafePay threat group was discovered in late 2024, and it swiftly gained popularity by targeting businesses in various sectors.
In their attacks, they enter corporate networks, typically through vulnerable RDP or VPN connectivity, where they take time to explore the data before beginning the24-hour encryption cycle. The ransomware adds .safepay to encrypted files while leaving a ransom note referred to as readme_safepay.txt, demanding payment in exchange for the decryption key to restore files and not to publish any data they might steal. The SafePay data dump on the dark web has registered numerous companies that have fallen prey to the threat, which has escalated in growth in a very short while.
Within this blog post, we introduce the SafePay ransomware family, examine its technical details (binary properties, crypto algorithms, persist mechanisms, code obscurity, and network communications), identify tactics in the context of the MITRE ATT&CK framework, and provide indicators of compromise. Additionally, we would like to highlight our internal example of the application of our proprietary auto-quarantine solution in combating the advanced ransomware variant of SafePay.
Family Overview
SafePay is a relatively new ransomware operation that has been around since late 2024. The ransomware operates independently and has not been affiliated with any known ransomware-as-service group, besides adopting the dual extortion tactic where they steal vital data before encrypting it, with the aim of decrypting it while inhibiting the leakage of data to the public.
At least 22 victims were revealed on the SafePay Tor leak site by security experts by November 2024, pointing to the initial quick spread of the malware in different areas such as the US, UK, Europe, and Latin America.
The group behind the SafePay toolkit seems to steer clear of CIS countries, as in initial samples there was a location check kill switch to disable if it was in CIS countries, where they used the Cyrillic alphabet group of languages. Note that in later versions, they took out the Eastern European language check, likely to cover even more territory.
There has been some observed evolution in the code written in SafePay. The initial code showed something in common with the leaked source code of ransomware such as LockBit Black and Hive, which indicated that they took some notables from there. The encryptor code in SafePay has independent development with unique tools and optimizations.
For instance, the data dump site and communication mechanisms employed by SafePay, ranging from the utilization of the TON decentralized network in addition to Tor and emails, represent the characteristic footprint left by the group of hackers. In general, SafePay has managed to emerge as one of the prolific threat actors in the year 2025 because of aggressive tactics and swift action with the aim of compromising valuable businesses across the world. Below, further details defining the SafePay ransomware payload can be explored.
Technical Details
Binary Characteristics: The SafePay ransomware is distributed in the form of a Windows executable with a random name, for example, \<random>.exe on disk. The binary has been noticed to be compressed with packers such as UPX, along with an injector/dropper in some cases to avoid detection. When it runs, the SafePay ransomware locks a mutex separate for each victim or locked path to run only one copy at any time.
It attempts to execute with escalated privileges through UAC bypass, where it uses the COM interface in the CMSTPLUA object to launch itself with administrative privileges without any prompt to the user. If it succeeds, it gives itself powerful token privileges in order to modify secured processes and files in the system.
There are numerous command-line arguments that SafePay responds to that can change its operation (for example: –path=<target> to encrypt files on a specific target, –network to encrypt network drives, –selfdelete to self-delete itself after execution, –enc=<N> to control the speed of partial encryption, and one very essential –pass=<key> parameter to decrypt the internally stored configuration/configuration key, which in turn allows it to continue operation).
SafePay creates a so-called marker file on each disk it accesses during the initialization phase with a random name that has hyphens inserted after hashing data: While it is running on the machine, it uses multiple threads to perform parallel processes of encrypting files and scanning network shares.
Encryption Algorithms: The hybrid encryption approach used in the SafePay payment gateway is very strong. The data in files is encrypted through the use of the ChaCha20 stream cipher algorithm or AES-256 if CPU instructions on AES-NI are supported.
The key to the files is secured with an X25519 elliptic curve Diffie-Hellman key exchange algorithm. That is: For each file, it generates a random 32-byte key and uses it to symmetrically encrypt the file contents with the ChaCha20 cipher. Then it derives the shared secret by combining the corresponding public key with the attacker-provided public key, which is integrated with the malware (the attacker’s public key is stored encrypted in the binary data and needs to be decrypted with the -pass parameter). The shared secret key goes through key derivation, producing the key used to encrypt the random key for the victims’ files or directly acting as a key for the ChaCha20 cipher.
The file’s footer is then appended in plaintext, containing a small metadata block (around 65 bytes) including the victim file’s ephemeral public key and other info needed for decryption. This design means only the attackers – who hold the corresponding private key for the embedded public key – can recover the per-file keys to decrypt data.
SafePay’s encryption is also optimized for speed: it does partial encryption of large files to save time. For example, attackers can specify an encryption percentage (the -enc flag); in one case, -enc=1 instructed the malware to encrypt only 10% of each 10MB block of a file. This strategy significantly accelerates the process while still rendering the files unusable.
The encrypted files are renamed with the .safepay extension appended. SafePay ensures that even critical infrastructure like databases and virtual machine images are encrypted (it will encrypt large files like hypervisors, leaving VMs inaccessible). To date, no flaws have been found in SafePay’s cryptography – it correctly implements ChaCha20/X25519 such that without the attackers’ private key, victims cannot break the encryption.
Persistence and Execution: SafePay’s attacks are typically “hands-on-keyboard”, meaning the attackers deploy the ransomware after gaining persistent access to a network, rather than relying on the malware itself to establish persistence. However, the ransomware will make some limited persistence moves on infected machines.
It adds an Autorun registry key pointing to its payload (or injected DLL) in the Run registry hive, ensuring it starts after reboot. Interestingly, SafePay cleans up this autorun entry at the end of the encryption routine – likely to reduce forensic traces or prevent re-execution once its job is done.
In some incidents, the SafePay operators also installed separate backdoors or tools for persistence before deploying ransomware. For example, NCC Group found that the threat actors dropped a QDoor backdoor (attributed to the BlackSuit group) and even installed legitimate remote access software (ScreenConnect) as a service to maintain access.
These tools allow the attackers to return to the environment even if the ransomware is discovered and removed. On endpoints, SafePay may also dump credentials (a registry dump tool was flagged in one case) to escalate privileges and ensure it can reach domain controllers or backup systems.Once ready to execute the encryption phase, SafePay uses a built-in UAC bypass (via the COM interface for the Connection Manager Profile (cmstplua.dll)) to relaunch itself with high integrity if it isn’t already running as admin.
It also attempts a token impersonation trick: if not running as SYSTEM or an elevated token, it will search for a process with higher privileges (like a service process) and impersonate its token to gain SYSTEM-level access. These measures ensure SafePay can traverse all files and terminate processes without restriction during encryption.
Obfuscation and Evasion: The SafePay ransomware binary exhibits several obfuscation techniques to thwart analysis. Many strings in the malware are not stored in plaintext; instead, they are XOR-encrypted and only decoded at runtime with a custom loop, making static analysis difficult.
The malware also avoids using straightforward API calls for some actions – for instance, it uses direct system calls (via Nt* functions) to hide threads from debuggers and to adjust privileges, rather than relying on easily-monitored Windows API libraries. SafePay terminates or disables security software to evade detection (Defensive Evasion): it leverages living-off-the-land binaries (LOLBins) built into Windows.
Upon gaining admin rights, it calls SystemSettingsAdminFlows.exe (a trusted system binary) to disable Windows Defender features via PowerShell commands. Specifically, it runs a sequence of commands to turn off real-time monitoring, firewall, sample submission, etc., effectively neutralizing Microsoft Defender AV on the host.
The malware then proceeds to kill processes and services that could interfere. It uses an API call (ZwTerminateProcess) to force-terminate a long list of applications – this list includes database servers (SQL, Oracle), mail servers (Exchange), backup agents (Veeam, Commvault processes with names like GxVss, GxCVD), office applications (Word, Excel, Outlook), web browsers, and security tools like endpoint agents.
By terminating these, SafePay unlocks files that might be in use and prevents backup or security software from stopping the encryption. Similarly, it calls the Windows Service Control Manager to stop services for backups, anti-virus, and system recovery. Services such as Volume Shadow Copy (vss), database services (sqlsvc), backup services (backup, Veeam), and any service named “Sophos” (for Sophos Anti-Virus) are programmatically stopped.
This two-pronged approach of process killing and service shutdown ensures minimal interference during file encryption and inhibits the victim’s ability to recover. Additionally, in early versions, SafePay checked the system’s UI language and would exit if the locale indicated Russia or certain Eastern European countries (a common tactic to avoid drawing attention from local law enforcement).
This check was done by calling GetSystemDefaultUILanguage and comparing the language ID against known Cyrillic-based locales. Newer samples removed this check, indicating the group became bolder in targeting a global victim pool.
Network Behavior: Once inside a network, SafePay operators exhibit extensive network discovery and lateral movement before launching the ransomware. A hallmark of SafePay is its use of a PowerShell script called ShareFinder.ps1 (from the PowerTools toolkit) to scan the domain for accessible network shares.
This script combs through the network identifying open SMB shares, high-value files (like documents, databases), and potential lateral movement paths. By using ShareFinder and similar tools, the attackers create a map of where critical data resides. SafePay also may use built-in commands (net view, net use) and AD queries to list computers and shares.
For lateral movement, the attackers rely on Remote Desktop Protocol (RDP) and SMB admin shares. In many cases, they obtain or crack an administrative credential and then use Windows PSExec/SMB or direct RDP sessions to deploy the ransomware binary across multiple systems.
One observed tactic was copying the ransomware (1.exe) to numerous servers via C$ or admin$ shares and launching it with a command line that points it to a network path (-path=\\<server>\<share>) for encryption. The threat actors often disable network defenses as well – for instance, if endpoint detection/response (EDR) tools are present, they may attempt to uninstall or kill agents using stolen domain admin rights.
Before encryption, SafePay performs data exfiltration to maximize leverage on the victim. The attackers typically collect sensitive files (e.g. financial records, customer data) and archive them with tools like WinRAR or 7-Zip, often using command-line options to split files and exclude certain file types (like videos, executables) to reduce the package size.
The archives are given innocuous names or hidden in temp folders. For exfiltration, SafePay has been known to use FileZilla FTP client, Rclone (a cloud storage tool), or even the RDP clipboard for manual transfer. In one documented case, after archiving data, the attackers installed FileZilla, uploaded the loot to a remote FTP server (over the internet), and then deleted FileZilla to cover tracks.
They may also leverage existing legitimate channels – for example, using already-installed remote management tools or uploading to cloud drives. Throughout the attack, SafePay communicates with attacker infrastructure primarily for tooling (exfiltration servers, backdoor C2) rather than having the ransomware binary reach out directly.
The SafePay ransomware binary itself does not overtly beacon out; it is used at the final stage for encryption. However, earlier in the attack lifecycle, the group’s backdoors have communicated with IP addresses over HTTPS (one incident showed an attacker C2 at 88.119.167[.]239 over port 443 in a dropped DLL).
SafePay’s leak site is on Tor (.onion address) and they also provide a TON (Telegram Open Network) site for contact – these are for victim communication post-attack rather than C2 during the attack. In summary, SafePay’s network behavior includes aggressive network scanning (to find targets and data), lateral movement using remote services, stealthy exfiltration of data to attacker servers, and finally widespread deployment of the encryptor across the environment.
TTP Mapping (MITRE ATT&CK)
SafePay’s tactics, techniques, and procedures (TTPs) can be mapped to the MITRE ATT&CK framework as follows (highlighting key techniques observed):
- Initial Access – Valid Accounts (T1078): Frequently, SafePay acquires initial access through the credentials of compromised or unsecured user accounts that access remote protocols. For example, using compromised credentials to enter a system through RDP, or through a compromised exposed VPN or remote gateway account, though this is one method to gain access to the network as an authorized user.
- Execution – Command and Scripting Interpreter (T1059): SafePay has very significant reliance on script interpreters and command line interfaces throughout the course of the attack. Attackers used script interpreters, such as PowerShell scripts like ShareFinder.ps1 to enumerate the network and executed batch commands to disable control features. The ransomware was launched using command line arguments, like cmd.exe or powershell.exe. This is categorized under T1059, but also T1059.001 PowerShell and T1059.003 Windows Command Shell.
- Defense Evasion – Disable or Modify Tools (T1562.001): The SafePay attack playbook also includes disabling all security software and backups. The attackers will run commands to disable Windows defender through MpCmdRun via PowerShell/LOLBins. They will “kill” or “stop” processes on the systems for endpoint protection (ex: Av) and backup agents. They are actively deleting shadow copies and Windows recovery options. Inhibit System Recovery is also applicable here, impairing defenses also allows the ransomware to remain operational.
- Discovery – Network Share Discovery (T1135): After gaining access, SafePay actors enumerate network shares and hosts. The use of ShareFinder.ps1 is common practice because it automates searching for open SMB shares and sensitive files throughout the domain. Additionally, they likely use built-in commands to enumerate domain assets, which constitutes enumerating network shares (T1135) and overall environment mapping (T1083 File/Directory Discovery).
- Lateral Movement – Remote Services (T1021): SafePay relies on remote services such as SMB and RDP to move laterally across the victim’s network. The attackers were observed transferring the ransomware to multiple servers over SMB admin$ shares and executing it remotely (for example with PsExec). They also conducted interactive RDP sessions (T1021.001) to manually deploy ransomware onto critical servers. The utilization of legitimate administrative channels to facilitate lateral movement reflects many human-operated ransomware attacks.
- Collection/Exfiltration – Archive Collected Data (T1560.001) & Exfiltration Over Alternative Protocol (T1048): Before encrypting the system, SafePay actors collect and archive the data from the victim machine. They utilize tools such as WinRAR or 7-Zip to archive sensitive documents into password-protected archives. For exfiltration, they typically transfer the data out of the environment over non-standard channels, for example; using the FileZilla FTP client or Rclone to transfer to cloud storage (which is Exfiltration over Alternative Protocol, T1048). In some instances, data may have been exfiltrated using HTTPS to a private server or even via the RDP clipboard (as SafePay explicitly states that they use the RDP clipboard). This is to ensure they have the data to leverage for double extortion.
- Impact – Data Encrypted for Impact (T1486): This is SafePay’s endgame – SafePay’s actors will encrypt data from victim systems using the ChaCha20/AES encryption protocol. SafePay appends the .safepay extension to all file types that have been encrypted. SafePay encrypts file servers, databases, and even virtual machines, rendering critical data and services unusable until a decryption key is received. Ransom notes (example: readme_safepay.txt) are left in each directory instructing the victim on payment and contact methods with the attacker.
- Impact – Inhibit Recovery of Systems (T1490): To exert maximum pressure, SafePay also compromises recovery mechanism options. It executes commands such as vssadmin delete shadows /all /quiet and wmic shadowcopy delete to erase the Volume Shadow Copies (i.e., Windows backup), and it uses bcdedit /set {default} recoveryenabled no to render Windows recovery mode inoperative. As a result, the victim is unable to restore from their local backups or use system restore, which greatly increases the likelihood that the victim feels obligated to pay. Also, all online backup agents are killed, and if possible, the network backup repositories will be encrypted.
- Impact – Access to Accounts Removed (T1531): In some cases, SafePay actors have locked out administrators during an attack. After ransomware was deployed, SafePay actors reset passwords of administrator accounts, removing the victim/organization’s access to critical systems. This disrupts incident response and recovery, which increases the impact of the attack.
IOC List (Indicators of Compromise)
Security teams can look for the following indicators related to SafePay ransomware in their environments. These IOCs are derived from public threat intelligence and should be sanitized (they are safe to share and not malicious in themselves):
- File Extension:
.safepay– files encrypted by SafePay will have this extension appended. - Ransom Note Filename:
readme_safepay.txt– the ransom note dropped in affected directories. - Example Hashes of SafePay Samples: MD5
d1f621b82822b544153f6b531e51a611, SHA-256a0dc80a37eb7e2716c02a94adc8df9baedec192a77bde31669faed228d9ff526. - Associated Network Infrastructure: Tor leak site URLs (v3 .onion addresses) and a TON site (
tons://safepay.ton) were provided to victims (actual addresses redacted). SafePay also uses ProtonMail for contact (two attacker email addresses were listed in notes, e.g.***@protonmail.com). In terms of attacker IPs, some exfiltration or C2 servers observed include 45.91.201[.]247, 77.37.49[.]40, and 80.78.28[.]63 (among others). These IPs were associated with SafePay activity and should be flagged if seen in network logs. - Artifacts and Tools: Presence of a file named ShareFinder.ps1 in administrative shares or temp directories may indicate SafePay reconnaissance activity. Unexplained use of WinRAR or 7zip command-line (especially if large archives with sensitive data) and installation of FileZilla where it’s not usually present could be signs of SafePay preparing data exfiltration.
Case Study: Xcitium vs. SafePay Ransomware
To illustrate how organizations can defend against SafePay, we conducted an internal lab test using Xcitium’s advanced endpoint protection platform against a live SafePay ransomware sample.
In this simulated attack, the SafePay ransomware executable was introduced onto a Windows environment protected by Xcitium. Immediately, Xcitium’s patented auto-containment (quarantine) mechanism kicked in – the unknown ransomware was automatically run in a secure, isolated container, preventing it from making any permanent changes to the system.
The malicious behavior of SafePay as it went about its routine of trying to disable defenses and encrypt files was caught by the Xcitium defense. Among the actions taken by the ransomware are spawning PowerShell, attempting process termination, and attempting mass file modifications-all of which were intercepted by Xcitium’s heuristic engine and contained. This containment technology effectively neutered the SafePay sample within a virtual sandbox and prevented it from encrypting any physical files on the machine.
During the test, Xcitium’s solution generated alerts about the behavior of SafePay-for example, an unknown application trying to change many files and trying to access protected data. In this case, SafePay’s attempts were observed without damaging anything by the security team, and Xcitium’s system automatically quarantined the malicious process.
Critically, Xcitium’s default-deny approach meant that even a brand-new ransomware with no prior signature was not allowed to execute freely. This underlines the value of proactive containment: even while SafePay can bypass traditional AV by disabling it, Xcitium’s containment does not rely on the AV being active – it sandboxed SafePay from the start. After containment, Xcitium’s cloud-based analysis rapidly classified the file as malware, and the threat was removed from the endpoints.
The case study emphasizes that modern endpoint protection has to go further than signature detection. Xcitium’s patented quarantine mechanism, Auto-Containment, creates an added layer of security wherein unknown processes, such as the SafePay ransomware, are executed in a restricted environment that does not permit file encryption or lateral movement to other systems.
In this way, organizations can keep ahead of the threats that are emerging. Our test stopped SafePay with zero damage in an effective manner, and thus, it was proved that even highly sophisticated ransomware can be defeated by combining default-deny policy, behavior analysis, and containment technology. All in all, this means for SOC analysts and CISOs that they must invest in advanced prevention, not just detection: if SafePay had infiltrated a live network, Xcitium’s solution would block the encryption routine and save the organization from a potential disaster.
Conclusion
The SafePay ransomware family is a dangerous and advanced multi-vector attack method: using advanced encryption based on ChaCha20/X25519, living off the land, lateral movement, and the classic double extortion playbook. However, organizations are not without options. The technology from Xcitium creates a decisive defense line.
Rather than waiting for signatures, or being aware of specific malware profiles, Xcitium utilizes a patented auto-containment engine. When an unexplained executable spawns and exhibits suspicious behavior — modification of a large number of files, spawning PowerShell, attempt to kill a process or shut down services — Xcitium executes a trigger, containing the executable process in a secure container as a preventative solution.
During the SafePay test case, this containment model prevented file encryption and any lateral movement, and showed that even new, advanced and sophisticated ransomware can be neutralized in practice with the right containment model. Furthermore, the Xcitium methodology is default deny, which prevents unknown executables from roaming freely. Instead, the behavior analysis engine indicates anomalous changes; and a cloud-based classification allows for quick follow-up. Ultimately, Xcitium makes a zero-day a moot point.
When you know how ransomware protections like SafePay operate and couple that information with a proactive solution like the one that Xcitium offers, the paradigm shifts from “if we get hit by ransomware” to “we shall not be damaged by ransomware.” This information stays protected, the enemy’s grip goes away, and the ransom payment is thereby prevented.
