SafePay Ransomware

SafePay first appeared in the autumn of 2024, but what started small has quickly become one of 2025’s sharpest ransomware threats. Rather than trumpet its arrival, this group has quietly refined its playbook, and the results are proving costly.

What distinguishes SafePay is its combination of Tactical Discipline + Relentless Speed. Entry is often via VPN or RDP using valid credentials, or through social engineering coupled with vishing or phone calls pretending to be IT staff.

Its encryption routines are paired with a double-extortion model: files are stolen before being encrypted, with threats to leak data on Dark Web leak-sites if demands are unmet.

SafePay doesn’t work like a typical ransomware-as-a-service (RaaS) affiliate model. Instead, it maintains an internal, in-house team and infrastructure. This gives it consistency in how it operates: repeated TTPs, similar victim profiles, and fast turnarounds from breach to encryption.

Geographically, its focus is sharp: the U.S., Germany, the U.K. and Canada are frequently targeted, especially in sectors like MSPs, healthcare, legal, logistics and financial services. It also uses techniques to avoid certain systems for example, SafePay’s payload includes logic that terminates if the system locale or keyboard language is one of several Cyrillic-based languages.

Background & Emergence

The first confirmed traces of SafePay appeared in November 2024. Early builds showed an evolving toolset, compact, DLL-based payloads, often deployed manually within compromised networks after extensive reconnaissance.

By early 2025, incidents attributed to SafePay began surfacing across North America and Europe. The group’s earliest victims included managed service providers (MSPs) and IT consultancies, high-leverage targets whose compromise could cascade to downstream clients. This pattern mirrors the group’s strategy: precision over scale, aiming to maximize disruption with minimal exposure.

Unlike many ransomware collectives that openly advertise or recruit affiliates, SafePay maintains an uncharacteristic silence. There are no public leak sites under its branding, no recruitment messages on cybercrime forums, and no clear RaaS infrastructure. Instead, SafePay appears to operate as a closed-circle entity, controlling its tooling, infrastructure, and negotiations internally. This self-containment reduces the operational noise that typically betrays newer groups and makes attribution significantly harder.

Technical analysis

High-level characteristics

• The sample appears packed and includes enabled ASLR and DEP, which prevents trivial hardcoding of code addresses and suggests the authors expected it to run on modern Windows systems.
• The PE layout is notable for an unusually large .debug section (~27% of the binary), which also has write permission and an anomalous configuration worth further scrutiny since it can hide strings/data and hamper standard static-analysis heuristics.
• The import table is sparse. The relatively small number of imports is consistent with a payload whose primary work is performed inlined (crypto routines, file I/O) or through indirect calls to OS APIs via fixed offsets/import remapping. No dynamic importer calls, such as LoadLibrary/GetProcAddress, were obvious from strings, increasing the suspicion that the sample resolves required APIs either via hardcoded addresses or via hashed/obfuscated name lookups.​​

Exports & entry

DLLRegisterServer is visible and appears to call into DLLInstall. IDA failed to show a conventional DllMain entry; DLLRegisterServer therefore serves as the practical entry point for further execution flows in the sample. Both exports and the DLL form factor imply that the payload is expected to be loaded into a host process or launched via an external exe.

Anti-analysis and environment checks

The sample performs a sequence of early environment validations before progressing to destructive actions. The main controller flow contains checks such as InitializeEnvironment, CheckExecutionEnvironment, and PerformInitialValidation, any of which will cause an early exit if conditions are not met. These checks are followed by initialization of internal handlers and service routines used later in the execution.

The binary decryption reveals explicit diagnostic strings used during runtime (e.g., “Log inited”, “Process bypassed, exiting…”, “Can’t create mutex”), indicating that the author enables conditional logging for debugging or telemetry. These reveal run-time decision points (UAC bypass attempts, mutex checks, search module initialization).

Modular key derivation: XOR key from loaded module base

One of the more interesting implementation details is an in-process routine (referred to as sub_100011E0) which iterates the InMemoryOrderModuleList to find a loaded module by computing a custom hash of each module name. The routine seeks a particular magic hash value (-894187319) and returns that module’s DllBase as a derived XOR key. This indicates a module-based keying approach where the runtime base address of a target DLL becomes a per-process keying source, an anti-static technique that ties decryption to a specific runtime image and complicates offline decryption attempts.

Practically, this makes automated static decryption harder and forces analysts to either emulate the same module load order or patch the binary to bypass the module search and supply the expected key.

Control flow & runtime behavior (MainController)

A decompiled/prototyped control flow (MainController) from the sample reveals the operational stages:

1. Environment & validation: calls to initialization and environment checks that will abort if preconditions fail.
2. Service routines & callbacks: early registration of handlers and callbacks (likely for cleanups, crash handlers, or scheduled actions).
3. UAC bypass attempt: the sample performs a conditional UAC bypass routine (AttemptUACBypass). If successful, it may exit (suggesting different execution paths depending on the context). The sample also supports a -uac flag to trigger abuse of the CMSTPLUA COM interface and execute elevated ShellExecuteW operations.
4. Instance mutex & single-run enforcement: the malware checks/creates a mutex (either a default or dynamically generated name). If a previous instance is detected, the sample exits. These strings are present in the sample’s decrypted logs (e.g., “Default mutex name [%s]”, “Mutex already exists… exiting”).

5. Search module initialization: before encryption begins, a search module is initialized to enumerate target files/drives. Failure to initialize this module triggers an exit path. The sample logs this (“Search module inited” / “Can’t init search module, exiting…”).

6. Auto vs manual mode: execution diverges depending on a runtime flag (byte_1000D1CD): if set, the sample runs an auto encryption routine (StartAutoEncryption) followed by PerformPostEncryption; otherwise it runs a manual encryption routine (StartManualEncryption) which may accept explicit paths or parameters. Both modes end with common finalization (finalize search, encrypt marker files and cleanup).

7. Optional self-deletion: the sample can self-delete if certain flags are set (logged as “Selfdeleting”); otherwise it performs cleanup and exits.

This stage-based structure aligns with a well-designed, battlefield-tested payload: validate, evade/probe, enumerate, encrypt, clean up.

Command execution & defensive sabotage

The DLL includes logic for executing system commands via a command runner initialized during DLLInstall. Notably, the sample is built to run the standard defensive destruction commands used by many ransomware strains:

• bcdedit /set {default} recoveryenabled no
• wmic shadowcopy delete
• bcdedit /set {default} bootstatuspolicy ignoreallfailures
• vssadmin delete shadows /all /quiet

These commands remove restore points and disable OS recovery behavior, greatly reducing victim recovery options. The sample also empties the Recycle Bin using SHEmptyRecycleBinW and establishes persistence by writing an entry under Software\Microsoft\Windows\CurrentVersion\Run with the command used to execute the sample.

Privilege escalation & UAC bypass

When invoked with the -uac flag, the sample abuses the CMSTPLUA COM interface to spawn elevated commands via ShellExecuteW. This indicates the payload can attempt to elevate itself on systems where the operator can provide conditions for the exploit, widening its destructive capabilities when successful. The presence of logging around UAC bypass attempts provides useful telemetry points for detection and emulation.

Encryption engine design & key derivation

The main encryption routine is a substantial, self-contained function that contains the following notable behaviors and structures:

• Large working buffer allocation (~1MB): The routine allocates a substantial working buffer used for key derivation and temporary crypto state. Failure to allocate causes graceful cleanup.

• Key material derivation: A random_seed buffer is populated by a call to a routine (dword_1000D4B8) which mixes in a value derived from a1 and global state; the seed is then processed. This seed is expanded through a chain of mixing and expansion routines, producing intermediate buffers (buf1, buf2) and a final key blob placed in the working buffer. The algorithm uses repeated mixing, wiping of intermediate buffers, and expansion of a layered KDF-like approach intended to increase resilience against simple key recovery.

• Final crypto state & dispatch: After final key material is prepared, a final crypto state is set up and the routine writes encrypted metadata or blocks to the target handle. The function performs careful buffer wiping of sensitive material after use. The result is a production-quality encryption routine with attention to hygiene and performance.
• Mapping to system DLLs: The analysis notes that certain dword pointers map to the addresses of system DLL functions (for example, advapi or other common libraries); this suggests the binary uses indirect references to API functions via resolved pointers rather than plain import names, complicating static matching.

Search & file targeting

The sample initializes a dedicated search module responsible for locating candidate files to lock. The code includes log strings referencing “Found local drive” and “Waiting encrypt threads (waiting for file encryption)…” which signal a multi-threaded encryptor that iterates discovered volumes/paths. The analysis references a main auto-encryption function and a separate manual mode function; both tie into the search module and ultimately into the central encryptor. This confirms a two-phase design: discovery/enumeration followed by threaded encryption of matched files.

Persistence, cleanup & optional self-removal

Persistence is achieved via the standard Run registry key. Post-encryption, the binary can remove artifacts and optionally self-delete when certain flags are set. The presence of detailed cleanup functions (FinalStageCleanup, UnregisterHooks, CloseHandles) indicates the authors prioritized leaving minimal forensic traces where possible.

MITRE ATT&CK mapping

Indicators of Compromise (IOCs)

File Hashes (SHA-256)

• 327b8b61eb446cc4f710771e44484f62b804ae3d262b57a56575053e2df67917
• a0dc80a37eb7e2716c02a94adc8df9baedec192a77bde31669faed228d9ff526

File Artifacts

• Ransom Note: readme_safepay.txt (dropped into multiple directories)
• Encrypted File Extensions: “.safepay”
• Mutex artifacts: distinct per victim, mutex used to prevent duplicate instance runs.

Network/leak site IOCs

• nj5qix45sxnl4h4og6hcgwengg2oqloj3c2rhc6dpwiofx3jbivcs6qd[.]onion
• iieavvi4wtiuijas3zw4w54a5n2srnccm2fcb3jcrvbb7ap5tfphw6ad[.]onion
• qkzxzeabulbbaevqkoy2ew4nukakbi4etnnkcyo3avhwu7ih7cql4gyd[.]onion

Conclusion

SafePay represents a new generation of disciplined, self-contained ransomware operations that are focused, technically sophisticated, and highly deliberate in execution. Its developers clearly understand enterprise environments and employ strong anti-analysis design, modular encryption, and well-timed lateral movement to achieve maximum disruption with minimal noise.

Unlike opportunistic RaaS affiliates, SafePay’s internal structure and refined tooling make it both harder to attribute and faster to act. The group’s emphasis on VPN-based initial access, rapid encryption, and data-theft extortion underscores a maturing threat model that prioritizes precision over publicity.

For defenders, SafePay is a reminder that resilience starts well before encryption: robust credential hygiene, segmentation, and behavioral monitoring remain the most effective countermeasures. As the line between espionage-grade stealth and ransomware aggression continues to blur, proactive visibility and reactive recovery will define who stays secure.