Ransomware Uses ChaCha20 and Curve25519 to Encrypt Windows Files

Payload ransomware is a new Windows ransomware family that combines ChaCha20 stream encryption with per-file Curve25519 ECDH key exchange, making victim data effectively unrecoverable without the attackers’ private key.

It also implements strong anti-forensics, including ETW patching, VSS deletion, event log wiping, and aggressive process/service termination to hinder detection and recovery.

Payload first appeared publicly in February 2026 and quickly adopted a classic double-extortion model: data theft, followed by file encryption and pressure on leak sites.

Within weeks, the group claimed victims across Egypt, Mexico, Poland, and other regions, showing an immediate global footprint rather than a localized campaign.

The group’s debut listing involved SODIC, a major Egyptian real estate developer, which served as the first public indicator of Payload’s operations and leak infrastructure.

As of 24 March 2026, the leak site had grown to 50 listed victims, with recent cases such as A‑Sonic Logistics Solutions confirming continued momentum and an emphasis on high-disruption targets tied to supply chains.

Payload’s targeting is broad and opportunistic, but several sectors stand out as priority focus areas. Logistics and transportation firms, including A‑Sonic Logistics Solutions, are frequent victims due to the high financial and operational impact of downtime across freight and supply-chain operations.

Real estate and construction organizations, especially in Egypt and the wider MENA region, also feature prominently, likely because these entities manage large volumes of sensitive financial and project data.

Beyond these, Payload has hit manufacturing, professional services, technology, and general commercial enterprises, indicating a strategy centered on disruption value rather than a single vertical.

Ransomware Uses ChaCha20 and Curve25519

According to Dark Atlas, Payload is delivered as a PE32 Windows executable that encrypts user data with ChaCha20, deriving a unique key per file via Curve25519 ECDH.

For each file, the malware generates a fresh 32‑byte victim private key and a 12‑byte ChaCha20 nonce using CryptGenRandom, computes a shared secret with the embedded operator public key, and uses that 32‑byte shared secret directly as the ChaCha20 key without any KDF.

After encryption, Payload renames files with the .payload extension and appends a 56‑byte RC4-encrypted footer that stores the victim’s ephemeral public key, nonce, and a “payload” tag, allowing the operators to reconstruct the shared secret during decryption.

Because the per-file private key is ephemeral and wiped from memory, and the ECDH shared secret is never written to disk, recovery is not feasible without the attackers’ Curve25519 private key.

On infected systems, Payload drops RECOVER_payload.txt ransom notes in affected folders and writes key handoff data to recovery.ini using a g:payload label format that embeds the victim’s ephemeral ECDH public key.

The binary contains multiple branding artifacts, including the .payload extension, RECOVER_payload.txt filename, a ??\C:\payload.log log path, and the g:payload key label, collectively confirming the “Payload” operator name.

Internally, the ransomware stores secondary key material as a double‑encoded base64 blob, which resolves at runtime to a 32‑byte ASCII string used directly as the RC4 key for decrypting the embedded ransom note.

The note instructs victims to install Tor, visit the Payload leak and negotiation sites, and initiate contact within strict time windows (72 hours for initial contact and 240 hours for full negotiation) under the threat of full data publication.

The malware exposes 14 command-line flags to tune behavior, including options for custom logging paths, target directory overrides, SIMD algorithm selection, thread counts, background execution, mutex control, ransom-note suppression, self-deletion, process/service killing, ETW bypass, and event log clearing.

It enforces single-instance execution via a mutex named MakeAmericaGreatAgain, exiting if a previous instance is found and mutex handling is not disabled.

Before encryption, Payload deletes all VSS shadow copies using vssadmin, patches ETW routines in ntdll to return immediately without logging, and iterates through Windows Event Log channels to clear their contents via wevtapi APIs.

It then uses direct NT APIs (NtOpenFile, NtReadFile, NtWriteFile, NtSetInformationFile, and others) plus IOCP-based multithreading to encrypt files in parallel, while terminating a wide range of database, backup, security, and productivity processes and services to maximize damage and disrupt recovery tooling.

IOCs

IOC Type	Value
MD5	E0FD8FF6D39E4C11BDAF860C35FD8DC0
SHA1	DDE1B933AAD33C5D96C2E45AD46434A200DC46A6
SHA256	1CA67AF90400EE6CBBD42175293274A0F5DC05315096CB2E214E4BFE12FFB71F
Mutex	MakeAmericaGreatAgain
File extension	.payload
Ransom note filename	RECOVER_payload.txt
Recovery file label	g:payload
Log file path	??\C:\payload.log
VSS deletion command	/c vssadmin.exe delete shadows /all /quiet
Tor blog / leak site	payloadrz5yw227brtbvdqpnlhq3rdcdekdnn3rgucbcdeawq2v6vuyd[.]onion
Tor negotiation portal	payloadynyvabjacbun4uwhmxc7yvdzorycslzmnleguxjn7glahsvqd[.]onion

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.