The first publicly available decryption method for The Gentlemen ransomware.
The Gentlemen (also known as hastalamuerte) is currently the most active ransomware-as-a-service (RaaS) operation globally, with 320+ confirmed victims as of Q1 2026. Until now, every major security vendor — Cybereason, Group-IB, Check Point, ASEC, Trend Micro — assessed the encryption as cryptographically unbreakable. No public decryptor existed.
We broke it.
The Gentlemen uses XChaCha20 stream encryption with X25519 ECDH key exchange. Each file is encrypted with a unique key derived from a fresh ephemeral key pair. The encryption is mathematically sound — we didn't break the math.
We broke the implementation.
Go does not zero cryptographic key material on the heap after use (CWE-244). Once an ephemeral X25519 private key is generated for a file, it lingers in process memory rather than being wiped — so a dump of the live process recovers the keys for files already encrypted, often in multiple GC-left copies. The OS reclaims this memory once the process exits.
A memory dump of the live process, taken during or near the end of encryption, typically contains the ephemeral keys for every file processed up to that point — in our 35-file analysis, all of them.
Results: 35/35 files decrypted with 100% accuracy. All 35 keys recovered in 0.6 seconds from a single memory dump.
If you've been hit by The Gentlemen ransomware, you may be able to recover files if a memory image of the ransomware process was captured while it was running. Recovery works by extracting the per-file ephemeral private keys from that image, so it is best-effort and may be partial — only files whose key had already been generated and was still resident at the moment of capture can be recovered.
What that means in practice:
- Each file's key is created at the moment that file is encrypted. A capture taken early in the attack contains keys only for the files processed up to that point; a capture taken near the end of execution gives the widest coverage.
- The keys live in the running process's memory. Go does not zero this key material while the process runs (CWE-244), so a dump of the live process typically yields the keys for files already encrypted — often all of them.
- The keys are lost soon after the process exits. Once the ransomware process terminates, the operating system reclaims its memory and the keys are quickly gone. A memory image only helps if it reflects the process while it was alive — a routine disk image, or a RAM capture taken after the machine was rebooted, will almost certainly not contain them.
- There is no master or skeleton key. The operator's private key never exists on the victim system. Recovery depends entirely on the per-file keys being physically present in your memory image; without such an image, this tool cannot recover those files.
Where a usable memory image may exist — each only helps if it captured the process while it was running:
- EDR/XDR solutions — CrowdStrike, SentinelOne, Carbon Black, Microsoft Defender for Endpoint, and others may capture process memory when they detect the threat. Check your EDR console for memory captures or forensic snapshots from the incident.
- Incident response — if your IR team used
procdump, Task Manager → "Create dump file", or another forensic tool to capture the ransomware process before terminating it. - Windows Error Reporting — if the ransomware crashed, a process dump may exist in
C:\ProgramData\Microsoft\Windows\WER\. - Kernel crash dumps —
C:\Windows\Minidump\andC:\Windows\MEMORY.DMP, if a bugcheck occurred while the process was running (only complete memory dumps include process memory; minidumps usually do not). - Full RAM capture — a forensic image of system RAM taken while the machine was still running (WinPmem, Magnet RAM Capture, FTK Imager).
- Hibernation file —
C:\hiberfil.sys, if the system hibernated while the ransomware process was active (it freezes a RAM snapshot at that moment).
Not sure whether any of these exist for your incident? Contact us at contact@bedrocksafe.ca and we can help you check.
# 1. Install dependencies
pip install cryptography
# 2. Extract ephemeral public keys from your encrypted files
python extract_keys_from_files.py --input-dir /path/to/encrypted/files --output keys.json
# 3. Search the memory dump for matching private keys
python recover_keys.py --dump process_memory.dmp --pubkeys keys.json --output recovered_keys.json
# 4. Decrypt your files
python decrypt.py --keys recovered_keys.json --input-dir /path/to/encrypted/files --output-dir /path/to/recoveredThe Gentlemen locker supports speed flags that perform partial encryption on
files larger than 1 MB. Under --superfast, only ~3% of bytes in a large file
are encrypted; the remaining ~97% is left as plaintext at the original disk
position. This is verified across published RE (ASEC, Trend Micro, Cybereason).
Whole-body XChaCha20 decryption on a partial-encryption file would DOUBLE-CORRUPT the unencrypted regions — XOR'ing keystream over the plaintext segments turns them to garbage and destroys recoverable data.
For this reason, decrypt.py refuses to process files larger than 1 MB by
default. If you have verified the locker ran in full-encryption mode (small
files only, or a build without the speed flags), pass --force-large to
override.
For partial-encryption victims, use format-aware recovery tools on the unencrypted regions instead:
- CyberArk White Phoenix — Office documents, PDFs (https://github.com/cyberark/White-Phoenix)
- PhotoRec — generic media file carving
- Format-specific carvers — tailored to your filetypes (SQLite, QuickBooks, etc.)
Bedrock Safeguard is actively reverse-engineering the chunk-offset geometry of partial-encryption mode. When that work completes, this decryptor will be updated to safely handle the partially-encrypted segments.
Per-file encryption:
1. Generate 32 random bytes -> ephemeral private key (crypto/rand.Read)
2. X25519(ephemeral_priv, operator_pub) -> shared_secret (32 bytes)
3. XChaCha20(plaintext, shared_secret) -> ciphertext
4. Append to file: --eph--<base64(ephemeral_PUBLIC_key)>--marker--GENTLEMEN
The ephemeral private key is the critical secret. It exists only in process memory and is never written to disk. But Go's goroutine stack allocator does not zero memory when variables go out of scope (CWE-244), leaving the key material accessible via memory forensics.
| ID | Description |
|---|---|
| CWE-244 | Improper Clearing of Heap Memory Before Release |
| CWE-316 | Cleartext Storage of Sensitive Information in Memory |
- Capture a full process memory dump during active encryption
- Scan for 32-byte values at 8-byte aligned offsets
- For each candidate, compute
public = X25519(candidate, basepoint) - Compare against ephemeral public keys extracted from encrypted file footers
- Match found = private key recovered for that file
- Derive decryption key:
shared_secret = X25519(ephemeral_private, operator_public) - Decrypt with XChaCha20 using shared_secret as key
| IOC | Value |
|---|---|
| Operator X25519 Public Key | fcb11717cab989424755a957c1d55361b119de4fdcfecdb2f2e56b15ad801922 |
| TOX ID | 88984846080D639C9A4EC394E53BA616D550B2B3AD691942EA2CCD33AA5B9340FD1A8FF40E9A |
| Negotiation Email | negotiation_hapvida@proton.me |
| Leak Site (.onion) | tezwsse5czllksjb7cwp65rvnk4oobmzti2znn42i43bjdfd2prqqkad.onion |
| Field | Value |
|---|---|
| SHA256 | 3ab9575225e00a83a4ac2b534da5a710bdcf6eb72884944c437b5fbe5c5c9235 |
| Type | PE32+ x64, Go binary, Garble-obfuscated |
| Size | 2,962,944 bytes |
| First Seen | 2026-04-03 |
| Indicator | Value |
|---|---|
| Ransom Note | README-GENTLEMEN.txt |
| Encrypted Extension | Randomized per build (e.g., .axfsmg) |
| File Footer | --eph--<base64>--marker--GENTLEMEN |
- Deletes volume shadow copies via
vssadminandwmic - Adds Windows Defender exclusions via
Add-MpPreference - Deletes Windows Prefetch files
- Kills database, backup, and security services before encrypting
- Changes desktop wallpaper to
gentlemen.bmp - Spawns child process with
LOCKER_BACKGROUND=1environment variable - CLI flags:
--path,--fast,--full,--shares,--silent,--system,-T(delay)
This research led to the development of Bedrock RansomGuard — an open-source Windows service that automatically detects ransomware encryption and captures process memory before keys are destroyed. RansomGuard works against any ransomware family, not just The Gentlemen.
This work extends Adrien Guinet's WannaCry key recovery (2017) to modern Go-based ransomware using elliptic curve cryptography. To our knowledge, this is the first published application of X25519 ephemeral key recovery from memory forensics against any ransomware family.
- The Canadian Centre for Cyber Security (CCCS) and RCMP NC3 have been notified of these findings.
- This publication contains only defensive information. No victim data is included.
- The encryption scheme details published here are already known to the operators — publishing them provides no offensive advantage.
This project is licensed under the Business Source License 1.1 — free for all non-commercial use, internal business use, incident response, and academic research.
Bedrock Safeguard Inc. is a Canadian cybersecurity intelligence firm specializing in threat actor infrastructure analysis, malware reverse engineering, and digital forensics. This research was conducted as part of our mission to protect Canadian organizations and individuals from ransomware threats.
If you are a victim of The Gentlemen ransomware and need assistance with key recovery, contact us at contact@bedrocksafe.ca.