M3rx ransomware: inside a new leak-site actor and Go encryptor

M3rx is a new ransomware name with a leak site, a Tox contact, and a Windows encryptor that is already doing real work.

RansomLook lists M3rx (opens in new tab) with six public posts as of April 27, 2026. One appeared on April 23. Five more appeared on April 26. PurpleOps used the spelling M3RXDLS (opens in new tab) in its April 26 ransomware activity report, and the victim set lines up with the M3rx leak-site entries. I am treating M3rx, M3RX, and M3RXDLS as labels for the same observed activity unless better attribution appears.

We pulled apart a PE32+ x64 Go sample tied to that contact footprint. The binary was submitted to Triage on 2026-04-25 as task 260425-gayffagw3x (opens in new tab). It carries an embedded config, writes RECOVERY_NOTES.TXT, renames encrypted files to random 16-character names with the .8hmlsewu extension, empties the Recycle Bin, and deletes itself through PowerShell at the end of execution.

The crypto and file format are worth the teardown. M3rx uses per-run X25519 key exchange, AES-CTR for file content, AES-GCM to wrap each per-file AES key, and a fixed 0x400-byte footer. The config is recoverable. The footer is readable. Interrupted files can also expose a different state than completed files.

The short version: M3rx is new, the public trail is still thin, and the encryptor already has a recognizable file format.

If you operate a threat intelligence platform with API access and can provide a researcher account, please reach out to kirk@derp.ca. Additional data sources directly increase the quality and coverage of the threat intel published here.

---

A new public name

RansomLook's group page showed six M3rx posts as of April 27, 2026. The April 26 batch spans the US, Canada, Australia, the UK, and Switzerland in the actor's own claims.

Those numbers are actor-posted claims. They still matter because they show timing and shape: a new name, a short public burst, and contact infrastructure that also appears in the ransomware note.

The contact footprint is also small:

The note says files were stolen and encrypted, asks for Bitcoin after negotiation, offers to decrypt three files as proof, and threatens publication plus sharing with competitors. It reads like standard double-extortion copy, but the contact anchors are useful for correlation.

The Windows sample

Observed host behaviors:

Config hidden in plain Go

M3rx stores its operator material in a 0x1000 blob in .rdata at virtual address 0x55ecbf. The blob is not directly gzip on disk. It becomes gzip after prepending:

1f 8b 08 00 00 00 00 00 00 ff

After decompression, the payload is Go gob data. The decoded struct shape is EC{K1, EX, NN, NT}.

The decode path is short: reconstruct the missing gzip header, decompress the body, then gob-decode the config. The recovered note contains the same Tor client area and Tox ID listed above.

The config is not clever. It is just annoying enough to make strings lie. The Go symbol table makes the rest easier: main.load_config at 0x517740 calls the gzip and gob paths directly.

File encryption

M3rx has two layers of key material.

Per process, main.load_config generates an X25519 ephemeral keypair. It copies the runtime ephemeral public key to global 0x6c80c0, loads the operator public key from config field K1, performs X25519 ECDH, and copies the resulting 32-byte shared secret to global 0x6c80e0.

Per file, main.encode_file generates a 16-byte IV and a 32-byte AES key. The file body is encrypted with AES-CTR. The per-file AES key is then wrapped with AES-GCM, keyed by the per-run X25519 shared secret.

The final footer gives the operator enough to recover files with the private side of the X25519 exchange. Without that private side, completed files depend on the live process shared secret.

The 0x400-byte footer

Every encrypted file gets a 0x400-byte footer. The same record moves through two states.

The staging state matters. If encryption is interrupted while the footer still has magic 0x3828ac45, record+0x18 can still hold the plaintext per-file AES key.

Completed files are different. The final footer magic is 0x741fbe88; record+0x18 has been overwritten; the real file key is wrapped at record+0x58.

Intermittent encryption

The default global percentage is 1. Fast mode sets it to 100.

The nominal per-1 MiB window is:

((percentage * 256) / 100) * 0x1000

At the default setting, that is 8192 bytes per 1 MiB window. Write-level capture refined the exact behavior for a 2 MiB test file: the first processed chunk read 8192 bytes, then wrote 7168 encrypted bytes, which is 8192 - 0x400. The footer chunk counter then recorded 1.

The test file makes this concrete:

This is not victim data. It gives byte-accurate proof of the encryption schedule and footer behavior.

Recovery notes

During analysis, the runtime ECDH shared secret was captured from global 0x6c80e0:

ce1a0de9338a3aeb622ebaf27d4b73def4fcdd203e684084b5da8280357c3b4f

Using that shared secret, the final footer's AES-GCM field unwrapped the per-file AES key:

1c648500122bb140d0857c15e3af92a1a3f3084e9f7247c8c21fc406a384136f

The validation script then reversed the observed AES-CTR body span and restored the test file:

That result proves the mechanism. It depends on capturing the process secret before it disappears, so it is a narrow recovery condition rather than a general decryptor.

The staging case is simpler. A partial file with footer magic 0x3828ac45 may still contain its plaintext per-file AES key at record+0x18.

Scope

The sample shows the file-impact side of the case: encryption, note dropping, Recycle Bin clearing, Restart Manager file unlocking, and self-delete behavior. The ransom note and leak-site posts supply the extortion claims. I did not find enough public evidence to tie M3rx to a known crew, affiliate toolkit, or specific intrusion path.

Detection Artifacts

M3rx is still a fresh name. The sample gives it concrete shape: a Go binary, a recoverable gzip+gob config, a .8hmlsewu extension, and a final footer marked by 0x741fbe88.