M3RX Ransomware Decryption & Data Recovery

The earliest known M3RX encryptor sample was uploaded to a public sandbox in late April 2026, and its leak site was picked up by trackers such as RansomLook and Ransomware.live at the same time, with a first batch of eleven victims published in one go on 29 April. As of 11 September 2026 trackers count roughly 38 to 43 named organisations (the figures differ by methodology), the most recent update falling in late August - a small crew that posts in occasional bursts. (One tracker's auto-generated profile says the group was "first observed in 2025", but every verifiable sample and leak-site post starts in April 2026, which is what this page follows.)

Victims sit in the US, Germany, the UK, Australia, Canada, Italy, Switzerland, Spain, Portugal, Ireland, the Nordics, Japan, Brazil, Mexico, Argentina, New Zealand and South Africa, concentrated in professional services, IT, retail and e-commerce, manufacturing and transport, and mostly mid-market companies. Claimed stolen volumes range from about twenty gigabytes to 2.3 TB, frequently hundreds of thousands and sometimes over a million files, which indicates a thorough exfiltration stage.

To be candid: public information on M3RX is still limited. The verifiable technical material comes largely from threat-intelligence reversing of a single Windows sample; no mainstream vendor has published an independent report, and the initial access vector, lateral-movement tooling and exfiltration method remain unconfirmed. No public victim in mainland China has been recorded either, but the targeting is plainly opportunistic, so overseas subsidiaries and cross-border branches of Chinese groups fall inside the same target space.

File renaming. This is the most visible M3RX trait: encrypted files do not keep their original names. The whole name is replaced by sixteen random characters plus the extension, e.g. a7Kq2xR9mB4tLpZ0.8hmlsewu. The original path is stored encrypted in the file trailer, so the directory structure cannot be reconstructed from filenames alone.

Extension. The publicly analysed sample uses .8hmlsewu. Note that both the extension and the note text live in a compressed configuration blob embedded in the binary, so they are build-time parameters and need not be identical across campaigns. Do not attribute on the suffix alone; cross-check it with the note filename, the Tox ID and the leak-site entry.

File trailer marker. Encrypted files carry a 1 KB trailer whose leading four-byte magic distinguishes a completed file from one interrupted mid-encryption. That distinction decides whether recovery room remains, so forensics must check it file by file rather than trusting the extension.

Ransom note. RECOVERY_NOTES.TXT, catalogued both in Zscaler ThreatLabz's ransom-note collection and on RansomLook; the sample drops it recursively into directories named "desktop" or "documents" (case-insensitive). The English text claims files were encrypted with a "military class algorithm" and stolen from the network, supplies a Tor chat portal link plus a Tox ID, offers to decrypt three sample files for free as proof before payment in Bitcoin, and explicitly warns against rebooting or shutting down machines, renaming or moving encrypted files and notes, or deleting the notes.

Other checkable traces. The sample enforces a single instance through a mutex named after the CRC32 of "kek" plus the hostname; it requires a high integrity level and exits outright under normal privileges; it empties the recycle bin and then deletes itself after a PowerShell loop overwrites the binary with random data; and its log leaves the misspelling complited.

Leak site. Entries usually state the claimed data volume and file count and attach sample screenshots. Negotiation runs on a separate Tor chat server whose uptime is poor and which is offline for long stretches - a common source of confusion for victims.

No public report yet describes how M3RX gains initial access or moves laterally, and we will not guess. The published sample analysis does, however, give several clues about how the operation is run:

• The encryptor does not steal data. The sample contains no exfiltration capability and talks to no C2, so data leaves through separate tooling before encryption. Hunting for the theft cannot stop at the machine where the encryptor landed.
• It requires a high integrity level and exits if it does not have one. The operators therefore already held administrator-level privileges before the encryptor was deployed; credential access and escalation sit earlier in the timeline.
• It supports a target path plus delayed and scheduled execution (a delay in minutes, or a specific start time). Those are the hallmarks of hands-on-keyboard deployment timed for maximum effect, typically pushed through administrative channels or scheduled tasks rather than worm-like self-spreading.

Investigation should therefore start with internet-exposed remote access (VPN, RDP, edge appliances), contractor and operations accounts, administrator credentials without MFA, mass-deployment channels (group policy, remote management and patch distribution), the reachability of backup infrastructure, and bulk outbound traffic in the window before encryption. The full kill chain for any given case still has to come from on-site forensics.

The following rests on a single publicly reversed Windows sample (Go-compiled x64 PE, unpacked, Go symbol table intact); build parameters may differ between campaigns.

Key scheme. Each file gets its own AES-256 key and its contents are encrypted with AES-256-CTR. That per-file key is then sealed into the file trailer with AES-256-GCM, under a key derived through X25519 elliptic-curve exchange against an attacker public key embedded in the binary. For files the encryptor finished, the key cannot be recovered without the attacker's private key.

Intermittent encryption. By default only about one percent of each file is encrypted, sampling chunks at a fixed 1 MiB stride; flags exist to raise that ratio or force whole-file encryption. In default mode large files - databases, virtual disks, mail stores - therefore tend to keep substantial intact regions, which makes page-level extraction and structural rebuilds realistic. The actual ratio must still be measured on site, because the operator can change it at deployment time.

File trailer. A 1 KB structure is appended to each encrypted file holding, in order, a magic value, the encryption percentage, the IV, the per-file key, an ephemeral public key, the GCM-sealed output, the encrypted original path and a chunk counter. The magic distinguishes completed files from ones interrupted mid-encryption, whose per-file key is not yet sealed - the first thing worth checking on site.

Destruction of recovery points. Embedded WMI shellcode enumerates and deletes every Volume Shadow Copy; the recycle bin is emptied silently; and the binary finishes by overwriting itself repeatedly with random data through PowerShell before deleting itself, leaving little sample residue for forensics.

Other behaviour. It walks every drive letter from A to Z; it does not enumerate or kill services but uses the Restart Manager to force handles on locked files to release (so database and mail services can still be encrypted); it throttles its own I/O to stay under behavioural detection thresholds; and it never contacts a C2.

Still unevidenced. Whether a Linux or ESXi encryptor exists, and whether databases and virtual disks receive any special handling.