2026-07-31 · view entry permalink →
GenieLocker — a Windows and ESXi ransomware built to leave no ransom note on disk, gated behind a hashed command-line secret so it will not run in a sandbox
Kaspersky published an analysis of GenieLocker on 2026-07-30, a ransomware family it dates to March 2026 and that open-source reporting attributes to the Toy Ghouls extortion group — also tracked as Bearlyfy, Labubu and Laboo.boo — which had previously relied on rented encryptors rather than its own (Kaspersky Securelist, 2026-07-30). The victim in the analysed intrusion was a Russian manufacturing organisation, which places the targeting outside this constituency; three deliberate design decisions in the malware are what transfer.
It will not run without a key the operator types. GenieLocker's Windows build expects its first command-line argument to be a hex string, which it converts to bytes, hashes with SHA-256, and compares against a value compiled into the binary. Without a match the process exits immediately. Kaspersky reads this as serving two purposes at once — evading sandboxes and automated analysis environments, which have no way to supply the argument, and preventing other criminals from reusing a captured sample. For a defender this has a concrete consequence: a sample recovered from an incident cannot be detonated to observe its behaviour unless the argument is also recovered, typically from command-line telemetry or shell history rather than from the file.
It watches for debuggers continuously, and for tampering with itself. Once the argument check passes, the malware spawns a thread that loops indefinitely, polling the standard debugger-presence checks every 500 milliseconds. On top of that it computes a checksum over its own executable code section at thread start and recomputes it on every iteration, so a breakpoint written into that section is detected as a change. Any single failed check terminates the whole process, with no partial-encryption fallback described.
It leaves nothing behind to alert on. GenieLocker writes no ransom note, carries no contact address and no negotiation link; the operators deliver demands by hand during the intrusion instead. Kaspersky's assessment of why is the operationally important part — that this is an attempt to avoid proactive detection triggered by the creation of multiple readme files. Any detection strategy that leans on mass note-drop as its ransomware trigger simply does not fire here. The ESXi build extends the same logic: it can overwrite the hypervisor's welcome message, and in the analysed sample that field was left blank rather than filled with a demand.
The intrusion around it is conventional and, for this constituency, the most familiar part. Initial access came over an OpenVPN connection originating from an external partner's network, using stolen credentials that were still valid — Kaspersky's assessment is that the operators exploited the trusted relationship with that partner rather than breaching the victim's own perimeter. From there they ran SoftPerfect Network Scanner for discovery, dumped credentials with Mimikatz, and accessed the KeePassXC password manager already installed on several machines to try to extract what was stored in its databases. Lateral movement used RDP to Windows hosts and SSH to Linux servers, mass deployment of the encryptor was carried out with the legitimate PsExec and PAExec utilities, and command-and-control ran over a reverse SSH tunnel. On the Linux and ESXi side the operators stopped running virtual machines before encrypting their disks. Kaspersky found no evidence of data exfiltration and notes this group runs neither double extortion nor a leak site — which means, unusually, that the encryption event is the whole extortion.
Detection. Because the note is gone, the durable behavioural triggers are the ones around it: a rapid rise in file-modification volume with high-entropy writes across shares, and, on hypervisors, virtual machines being powered off in sequence shortly before their backing datastore files start changing — that ordering is the ESXi ransomware signature that does not depend on any note or binary. On the endpoint, remote service creation by PsExec-class tooling from a host that is not a management server is the deployment step, and it is loud in service-creation and process-creation telemetry. Two collection behaviours are worth hunting independently of this family: a process other than the password manager itself opening a KeePass database file, and any read of a credential database from a service account context.
Triage: administrators use PsExec, and virtual machines are shut down for maintenance every day. The discriminators are direction and breadth — legitimate PsExec runs originate from a known management host to a bounded set of targets, whereas deployment here fans out from a recently-compromised workstation to everything reachable; and maintenance shutdowns are scheduled, announced in change records, and followed by boots rather than by datastore writes. For the password-manager signal the discriminator is the accessing process: the user's own manager opening its database is normal, a scripted or remote-execution parent doing it is not.
During the incident, the attackers first entered the environment through an OpenVPN connection originating from an external partner's network. They likely exploited the trusted relationship with that partner and used stolen, yet still valid, credentials to connect.
GenieLocker starts a new parallel thread called watchdog. It runs in an infinite loop that performs a number of checks to detect well-known debuggers every 500 milliseconds. If at least one of the checks fails, the whole GenieLocker process immediately terminates.
GenieLocker doesn't save the ransom notes on the victim's system. The Trojan doesn't contain any attackers' contact info or negotiation addresses. Instead, the attackers will need to deliver the ransom demands and contacts manually during the attack.