GenieLocker ransomware: custom-made for multiple systems

GenieLocker ransomware has been active since March 2026 in attacks on organizations in the Russian Federation. According to open-source insights, the threat is linked to the group Toy Ghouls, which is best known for financially motivated extortion. Instead of relying only on existing encryption trojans, GenieLocker appears to have been built as its own design and is deployed as custom malware across multiple platforms.

In this article, we break down the most notable characteristics: how the attack starts, what steps it follows to gain access and control, and what happens technically during encryption on Windows, Linux, and ESXi. This gives you clearer expectations for what a GenieLocker ransomware infection may look like—and what to focus on in terms of prevention and detection.

Why GenieLocker ransomware feels different

The core of the threat is that GenieLocker is designed to run “natively” across different environments: Windows, Linux, and ESXi. That means attackers can better tailor their toolkit to the targets and rely less on external, off-the-shelf encryption software.

In addition, the TTP (tactics/techniques/procedures) shows that the group uses repeatable steps. At the same time, there is enough customization visible in the encryption component itself, including platform-specific variants and cryptographic building blocks.

Start of the attack: entry via OpenVPN

In the incident under investigation, attackers gained access to the environment via an OpenVPN connection. That connection was established from the network of an external partner. The suspected route: exploitation of a trust relationship with that partner, combined with stolen but still valid credentials.

This pattern is especially relevant for organizations with external collaborations. A single mistake in partner trust or credential hygiene can become an entry point to a full compromise.

Discovery and credential access: tools you don’t want to see

After the attackers gained a foothold, they installed additional tooling on compromised hosts. Among other things, they used OpenSSH, a socks5.exe component, and a network scanner: SoftPerfect Network Scanner. For credential dumping, Mimikatz was used.

There is also forensic evidence that attackers accessed the KeePassXC password manager already present on multiple machines. The idea there is straightforward: try to obtain saved credentials from KeePass databases, making later movement and privilege escalation easier.

Lateral movement and command-and-control

For lateral movement within the network, they used RDP for Windows systems and SSH for Linux servers. The encryption trojan was then deployed using legitimate utilities: PsExec and PAExec.

To facilitate communication with the command-and-control infrastructure, a reverse SSH tunnel was also set up. This makes outbound connections less “suspicious” than a completely new, unusual C2 route.

Impact: encryption on Windows, Linux and ESXi

During the impact phase, the group moved to encryption. On Windows machines, the PE variant of GenieLocker ransomware was used to encrypt files.

On Linux and ESXi systems, virtual machines were stopped and disks were encrypted using a variant specifically released for those platforms (ELF version). This means the attack targets not only individual endpoints, but also the virtualization layer.

Windows variant: custom encryption with libsodium

The Windows version of GenieLocker is primarily written in C, but compiled with C++ libraries. The malware uses the open-source libsodium library for cryptographic functions.

What stands out is that the ransomware does not store standard readme files with contact information on the infected systems. Instead, attackers must provide the ransom note and contact details manually during the attack. This approach appears intended to slow down detection or bypass it.

Encryption control via a “secret argument”

For the Windows variant, the malware expects a first argument: a hex string that is referred to in the code as a “secret argument.” This is needed to start the ransomware. The value is converted into bytes and then compared via SHA-256 with a hardcoded value.

After that, further transformations follow (including BLAKE2b-256), where the final output is not used directly as you would normally expect. This suggests that some parts of the functionality may still have been under development.

Anti-debugging and watchdog logic

To make analysis harder, GenieLocker contains mechanisms to check whether the process is being observed. There is an initial environment check where WinAPI functions are used to detect debuggers. Then a watchdog thread starts, performing periodic checks in an infinite loop; if any check fails, the malware immediately terminates itself.

In addition, the malware computes a CRC32 of the .text segment and repeatedly compares that value. If the code is modified by a debugger or other tooling, that difference can trigger detection.

Exclusion lists and stopping processes and services

For encryption, GenieLocker uses multiple exclusion lists. As a result, many system folders and specific Windows files and extensions are not targeted, to prevent essential OS components from being damaged.

If the hostname does not fall within an exclusion list (empty in the sample examined), the ransomware also stops processes that may be using files. It also stops services via ControlService. Only after that does the trojan begin setting up encryption tasks and accessing available drives, including network shares.

File-level encryption: lockfiles, journal, and chunking

The extension for encrypted files is hardcoded. For each file, the ransomware creates two helper files: a lock file to prevent double encryption and a journal file for status and integrity checks.

The encryption happens in chunks (by default per 0x1000000 bytes). A parameter can specify which percentage of the content is encrypted. Even when that percentage is zero, in the behavior observed, at least an initial chunk at the beginning is still encrypted.

For the actual cryptography, GenieLocker uses AEAD with XChaCha20-Poly1305 for content and metadata, with a unique key/nonce per file. Keys are encrypted via Curve25519-XSalsa20-Poly1305 using a hardcoded master public key in the trojan.

Linux and ESXi: simpler, but with platform features

According to the analysis, the Linux/ESXi variant is simpler than the Windows version. There is no secret argument, anti-debugging techniques and exclusion lists are missing. At the same time, the ESXi variant includes functions that fit that environment.

For example, this build supports a daemonized mode via -d, using a double-fork to fully detach the process from the parent. It also modifies the ESXi “Welcome Message” by changing /etc/vmware/welcome. On Linux distributions, that path naturally does not change.

Further, the ESXi build supports options for a launch delay and setting the number of encryption worker threads. Here too, the encryption logic is broadly similar to the Windows variant in terms of algorithms: XChaCha20-Poly1305 for content/metadata and Curve25519-XSalsa20-Poly1305 for key encryption.

Where victims come from

Telemetry indicates that detections of GenieLocker ransomware are primarily concentrated on endpoints in the Russian Federation. In the campaign around March 2026, the manufacturing sector was particularly targeted, with construction, financial services, retail, and technology listed as additional affected sectors.

Conclusion: custom-made ransomware for multiple layers of your infrastructure

GenieLocker ransomware shows that attackers increasingly build and tailor their encryption component themselves to the target platform. The combination of entry via a partner connection, using known dual-use tools, lateral movement via RDP/SSH, and the broad impact on both Windows and virtualization (ESXi) makes this threat especially relevant for teams focused on endpoint, server, and virtualization security.

For organizations, the key takeaway is this: don’t only improve file protection—also examine partner access, credential hygiene, network segmentation, and monitoring of common tools that attackers abuse. That way, you reduce the likelihood that a custom ransomware operation can fully compromise your systems.