Behind .payload: In-Depth Technical Analysis of Payload Ransomware

Payload ransomware is a Windows ransomware family that appends the .payload extension to encrypted files, drops RECOVER_payload.txt ransom notes, and uses ChaCha20 encryption with per-file Curve25519 ECDH key exchange. The sample also includes anti-forensics features such as ETW patching, VSS deletion, Windows Event Log clearing, and process/service termination.

Key Takeaways

• Payload ransomware first appeared publicly in February 2026 and quickly showed a global victim footprint across Egypt, Mexico, Poland, and other regions.
• As of 24 March 2026, the group had listed 50 victims on its leak site.
• The ransomware encrypts files using ChaCha20, with a fresh Curve25519 ECDH key exchange per file.
• Encrypted files receive the .payload extension and include a 56-byte RC4-encrypted footer.
• The sample drops RECOVER_payload.txt, writes recovery data to recovery.ini, and uses strong anti-forensics techniques.
• Anti-forensics behavior includes ETW memory patching, VSS shadow copy deletion, Windows Event Log clearing, and targeted termination of processes and services

Overview

On 15 February 2026, a new ransomware group known as Payload appeared on the cybercrime landscape. Although the group initially claimed only a limited number of victims, its operations quickly showed a global footprint, with targets across Egypt, Mexico, and Poland.

The group’s first publicly disclosed victim was SODIC, one of Egypt’s leading real estate development companies. That listing marked the debut of Payload’s leak site and provided the first public indicator of the group’s emergence as a new ransomware operation.

Despite its early-stage victim count, Payload’s rapid expansion beyond a single region suggests that the group may be positioning itself as an international ransomware operation from the outset. Therefore, tracking its infrastructure, victimology, encryption design, and anti-forensics behavior is important for understanding where it fits within the broader ransomware ecosystem.

Payload Linked Victim Listings

As of 24 March 2026, the Payload ransomware group had listed 50 victims on its leak site. This shows a steady increase in activity since the group first appeared. The most recently disclosed victim at the time of analysis was A-Sonic Logistics Solutions, which further demonstrates the group’s continued operational momentum.

Payload’s victimology shows a broad geographic targeting strategy, with affected organizations across multiple continents and industries. However, the victim list also shows a noticeable concentration in Egypt and the broader Middle East and North Africa (MENA) region. This may indicate regional opportunity, exposed attack surfaces, or deliberate targeting priorities.

Targeted Sectors

Payload’s 50 publicly listed victims show a broad but opportunistic targeting pattern rather than a strict focus on one vertical. The group appears especially active against logistics and transportation, with victims such as A-Sonic Logistics Solutions highlighting interest in organizations tied to supply chains, freight forwarding, and operational logistics.

This sector is attractive for ransomware operators because downtime can quickly create financial pressure, operational disruption, and customer-facing consequences.

Another noticeable segment is real estate and construction, particularly in Egypt and the wider MENA region. High-value development firms and property-related enterprises can provide attackers with leverage because they often hold sensitive financial data, project documents, contracts, and time-critical operational records.

Payload’s victimology also includes manufacturing, professional services, technology, and general commercial enterprises. As a result, the group appears to prioritize organizations with high disruption value rather than limiting itself to one niche.

What Is Payload Ransomware?

Payload ransomware is a PE32 Windows executable that encrypts victim files using ChaCha20. For each file, it generates a fresh 32-byte victim private key and a 12-byte nonce, then uses Curve25519 ECDH to derive the shared secret used as the ChaCha20 key.

After encryption, the malware appends the .payload extension to encrypted filenames. It also writes RECOVER_payload.txt ransom notes in affected directories and stores victim key recovery data in recovery.ini using the g:payload label format.

The encrypted file format includes a 56-byte RC4-encrypted footer. This footer contains the victim’s ephemeral public key, nonce, and the "payload" tag. In addition, the sample includes anti-forensics capabilities such as ETW memory patching, VSS shadow deletion, Windows Event Log clearing, and targeted termination of processes and services.

Sample Metadata

Operator Self-Identification (“payload” Branding)

The binary uses four independent strings that collectively confirm “payload ransomware” as the operator’s brand name:

The g:payload string is especially important because it appears in the key-handoff design written to recovery.ini. In this design, the victim’s ephemeral ECDH public key is written in the format g:<base64_victim_pubkey>. Therefore, the g: prefix likely represents the group key label, while payload acts as the embedded campaign label.

Technical Analysis

Command-Line Argument Parsing (14 Flags)

The ransomware parses command-line arguments using GetCommandLineW and CommandLineToArgvW. It supports 14 flags that control logging, encryption behavior, thread count, background execution, mutex handling, ransom note writing, service/process termination, ETW patching, and event log clearing

All flag states are logged to \??\C:\payload.log with [Args] prefix strings. Examples include [Args] The mutex WILL BE created and [Args] ETW WILL BE patched.

Mutex and Single-Instance Check

Payload ransomware creates a mutex named:

MakeAmericaGreatAgain

If GetLastError() returns 0xB7 (ERROR_ALREADY_EXISTS) and the mutex is not disabled, the ransomware prints [Mutex] locker running.. and exits.

Pre-Encryption Call Sequence

Before file encryption begins, the ransomware follows this call sequence:

0x0040AF3F   test  [0x45F6F3], 0xFF     ; check --bypass-etw flag
0x0040AF48   call  fcn.004092D2          ; ETW bypass (conditional)
0x0040AF4D   call  fcn.0040A855          ; encryption setup (ECDH key derivation, service/process kills, VSS)
0x0040AF52   call  fcn.0040A22C          ; main file locker (IOCP, ChaCha20 encryption)

Cryptographic Architecture

Curve25519 ECDH Key Exchange

Payload performs ECDH key derivation once per file. The operator public key is decoded once in the main locker and stored globally. The binary validates the 32-byte key size requirement using the error string:

SIZE OF PUBKEY IS LOWER THAN NEED (32)

Operator ECDH public key embedded in .rdata:

Base64:  aH9Tbdc+qPcQkPwhclaNYFadhF04GzuGsuRxDbKMRkU=
Decoded: 68 7F 53 6D D7 3E A8 F7 10 90 FC 21 72 56 8D 60
         56 9D 84 5D 38 1B 3B 86 B2 E4 71 0D B2 8C 46 45
Length:  32 bytes (Curve25519 key size)

Per-File Key-Handoff Design

1. CryptGenRandom generates a fresh 32-byte victim private key into [ebp-0xD8], once per file
2. Curve25519 clamping applied in-line: [ebp-0xD8] &= 0xF8; [ebp-0xB9] = ([ebp-0xB9] & 0x3F) | 0x40
3. fcn.0040598E (curve25519_donna): output = victim public key into [ebp-0x110], scalar = [ebp-0xD8], base_point = curve25519 standard generator ([ebp-0x2EC])
4. fcn.0040598E called again: output = shared secret into [ebp-0xB8], scalar = [ebp-0xD8], base_point = operator public key (loaded from global 0x45F6E8)
5. Shared secret copied directly to ChaCha20 key slot [ebp-0x80] via memcpy, no KDF
6. Victim public key (in [ebp-0x110]) is the first 32 bytes of the 56-byte file footer
7. Attacker runs X25519(operator_private, victim_public) to reconstruct the shared secret → ChaCha20 key

Notably, the ransomware uses the raw 32-byte X25519 shared secret directly as the ChaCha20 key, with no KDF.

Secondary Key Material :

The ransomware stores secondary key material near the ransom note filename.

Outer base64 (44 bytes): aFFFUElOdVRZMmx5dHVmTERwSlFkVmtyV2xvdkMxUVI=
Outer decoded (32 bytes): 68 51 45 50 49 4E 75 54 59 32 6C 79 74 75 66 4C
                          44 70 4A 51 64 56 6B 72 57 6C 6F 76 43 31 51 52
As ASCII string:         "hQEPINuTY2lytufLDpJQdVkrWlovC1QR"  (all printable)
Inner base64 (32 chars): hQEPINuTY2lytufLDpJQdVkrWlovC1QR
Inner decoded (24 bytes): 85 01 0F 20 DB 93 63 69 72 B6 E7 CB
                          0E 92 50 75 59 2B 5A 5A 2F 0B 54 11

This double-encoded structure (outer base64 → printable ASCII that is itself valid base64 → 24 raw bytes) is intentional. The operator generated 24 random bytes as key material, base64-encoded them to produce a 32-character printable string (“hQEPINuTY2lytufLDpJQdVkrWlovC1QR”), then base64-encoded that string again for embedding in the binary. At runtime, only one decode step is performed producing the 32-byte ASCII string which is used directly as the RC4 key. The 24-byte inner value is the pre-encoding key material; it has no direct runtime role. The double-encoding is an obfuscation technique to make the actual key bytes less visible to static scanners.

Ransom Note

Inside .rdata, an encrypted blob was found. After RC4 decryption, it was identified as the ransom note deployed on the victim machine as RECOVER_payload.txt.

RC4 implementation: KSA (256-byte S-box init), PRGA (i/j counter XOR). Both are called from the ransom note writer function.

RC4 key derivation: The secondary key (aFFFUElOdVRZMmx5dHVmTERwSlFkVmtyV2xvdkMxUVI=) is base64-decoded to 32 ASCII bytes: hQEPINuTY2lytufLDpJQdVkrWlovC1QR. This 32-byte string is the RC4 key.

Ransom note:

Base64 length:   2044 characters
Decoded size:    1896 bytes (ciphertext)
RC4 key:         hQEPINuTY2lytufLDpJQdVkrWlovC1QR (32 bytes)
Decryption:      Successful - UTF-8 plaintext

Decrypted content:

Welcome to Payload!

The next 72 hours will determine certain factors in the life of your company:
the publication of the file tree, which we have done safely and unnoticed by all of you,
and the publication of your company's full name on our luxurious blog.
NONE of this will happen if you contact us within this time frame and our negotiations are favorable.

We are giving you 240 hours to:
1. familiarize yourself with our terms and conditions,
2. begin negotiations with us,
3. and successfully conclude them.
The timer may be extended if we deem it necessary (only in the upward direction).
Once the timer expires, all your information will be posted on our blog.

ATTENTION!
Contacting authorities, recovery agencies, etc. WILL NOT HELP YOU!
At best, you will waste your money and lose some of your files, which they will carefully take to restore!
You should also NOT turn off, restart, or put your computer to sleep.
In the future, such mistakes can make the situation more expensive and the files will not be restored!
We DO NOT recommend doing anything with the files, as this will make it difficult to recover them later!

When contacting us:
you can request up to 3 files from the file tree,
you can request up to 3 encrypted files up to 15 megabytes
so that we can decrypt them and you understand that we can do it.

First, you should install Tor Browser:
1. Open: https://www.torproject[.]org/download
2. Choose your OS and select it
3. Run installer
4. Enjoy!

In countries where tor is prohibited, we recommend using bridges,
which you can take: https://bridges.torproject[.]org/

You can read:
http://payloadrz5yw227brtbvdqpnlhq3rdcdekdnn3rgucbcdeawq2v6vuyd[.]onion (Tor)

To start negotiations, go to http://payloadynyvabjacbun4uwhmxc7yvdzorycslzmnleguxjn7glahsvqd[.]onion and login:
User: hEg62n6K
Password: iuThQRYm5D6HRSF4

Your ID to verify: 1Q6NsTqfT023CTcDSFCt4oyCNKOyochF

SIMD-Adaptive Encryption Paths

Payload supports three encryption execution paths selected by --algo or auto-detected at runtime.

File Encryption Mechanics

IOCP Parallel File Encryption

Payload uses I/O Completion Ports (IOCP) for parallel file encryption. The thread count is either set through --threads <n> or defaults to the physical core count returned by GetSystemInfo.

Drive and network share enumeration are controlled by the -s flag after IOCP worker thread creation.

Per-File Encryption Pipeline

Each file processed by the IOCP worker thread runs the following pipeline:

1. NtOpenFile    - open target file
2. LockFileEx    - exclusive lock
3. CryptGenRandom → 32B victim privkey  
4. CryptGenRandom → 12B ChaCha20 nonce 
5. Curve25519 clamp victim privkey      
6. curve25519_donna → victim pubkey     
7. curve25519_donna → ECDH shared sec  
8. memcpy shared_secret→ChaCha20 key[ebp-0x80]  
9. memcpy nonce→ChaCha20 nonce[ebp-0x5C]         
10. memcpy 0x00000000→ChaCha20 ctr[ebp-0x60]     
11. HeapAlloc 0x100000 (1 MB chunk buffer)        
12. ReadFile → (chacha_fnptr) → write   - encrypt in 1MB chunks
13. Seek to EOF; build 56-byte footer            
14. RC4_KSA("FBI", 3B) + RC4_PRGA(footer, 56B)  
15. Write 56-byte RC4-encrypted footer to file   
16. NtSetInformationFile rename to .payload      
17. UnlockFileEx; NtClose                        

Critical Encryption Properties

• CryptGenRandom is called per file not once in the locker. Nonce reuse is structurally impossible.
• Victim private key is ephemeral (generated fresh, used once, zeroed at VA 0x4098CC–0x4098DB).
• Shared secret → ChaCha20 key with no KDF (raw 32-byte X25519 output = key).
• File encrypted in 1 MB chunks; final partial chunk processed before footer write.
• Footer RC4 key is the 3-byte suffix “FBI”

Encrypted File Format

Payload writes encrypted files in the following format:

[  N bytes  ]  ChaCha20-encrypted original content  (1MB-chunked in-place)
[ 56 bytes  ]  RC4-encrypted footer

Footer structure is (56 bytes, RC4-encrypted with key "FBI" before write):

Offset   Size  Field             Notes
------   ----  -----             -----
0        32    Victim pubkey     Curve25519 public key; ecx=[ebp-0x110] output of donna call 1
32       12    ChaCha20 nonce    CryptGenRandom 12B; written directly to [ebp-0xF0] = offset 32
44        4    Unknown           Stack-uninitialized gap; likely 0x00000000 or garbage
48        8    "payload\0"       0x6C796170 + 0x0064616F (little-endian dwords)

Direct NT API File I/O (Anti-Hook)

All file operations bypass user-mode API hooks by using function pointers resolved dynamically from ntdll:

File Enumeration and Exclusion Lists

Excluded Directories (17 entries, UTF-16LE):

Payload avoids encrypting several system, browser, and recovery-related directories, including:

AppData, Boot, Windows, windows.old, Tor Browser, Internet Explorer, Google, Opera, Mozilla, $Recycle.Bin, ProgramData, All Users, $WinREAgent, and WindowsPowerShell.

Excluded File Names (28 entries, UTF-16LE):

The ransomware excludes sensitive system and recovery files such as:

autorun.inf, boot.ini, bootmgr, desktop.ini, ntldr, ntuser.dat, pagefile.sys, hiberfil.sys, swapfile.sys, recovery.ini, boot.sdi, system.ini, win.ini, RECOVER_payload.txt, and others.

Excluded Extensions (54 entries, UTF-16LE):

Payload excludes executable, system, script, log, temporary, font, disk image, and already-encrypted .payload files. Examples include:
.exe, .dll, .dll.mui, .sys, .drv, .efi, .cpl, .ocx, .mui, .msc, .bat, .cmd, .ps1, .ps1w, .psm1, .psd1, .vbs, .jse, .wsf, .wsh, .ini, .inf, .reg, .admx, .adml, .xml, .theme, .desktheme, .dat, .log, .log1, .log2, .evtx, .sav, .tmp, .vsidx, .regtrans-ms, .blf, .lnk, .url, .library-ms, .search-ms, .searchconnector-ms, .ttf, .otf, .fon, .fnt, .wim, .vhd, .vhdx, .bcd, .sdi, .boot, .cur, .ani, and .payload

Process and Service Kill Lists

Process Kill List

Killed via CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS) → Process32First/Process32Next → TerminateProcess. String list in .rdata:

Service Kill List

Killed via OpenSCManagerA + OpenServiceA + ControlService(SERVICE_CONTROL_STOP):

Anti-Forensics Techniques

ETW Event-Tracing Bypass

When --bypass-etw is enabled, the ransomware patches ETW-related functions inside ntdll. The routine calls VirtualProtect, marks each function page as PAGE_EXECUTE_READWRITE, overwrites the function prologue with a xor eax, eax; ret stub, and then restores the original page protection

Patched targets:

VSS Shadow Copy Deletion

ShellExecuteW called with:

• Verb: open 
• File: cmd.exe 
• Params: /c vssadmin.exe delete shadows /all /quiet 

Executed before file encryption begins, permanently destroying all VSS snapshots. No recovery via Windows shadow copies after this point.

Windows Event Log Clearing

Payload dynamically loads wevtapi.dll and resolves the following APIs:

The ransomware clears Windows Event Log channels, including Application, System, Security, Setup, and provider-specific logs.

IOCs

Yara Rule

rule Windows_Ransomware_Payload
{
    meta:
        description = "Payload ransomware"
        author      = "Dark Atlas; @ELJoOker"
        date        = "2026-05-21"

    strings:
        $s1         = "aH9Tbdc+qPcQkPwhclaNYFadhF04GzuGsuRxDbKMRkU=" ascii
        $s2         = "aFFFUElOdVRZMmx5dHVmTERwSlFkVmtyV2xvdkMxUVI=" ascii
        $s3         = "expand 32-byte kFBI" ascii
        $s4         = "RECOVER_payload.txt" ascii
        $s5         = ".payload" wide
        $s6         = "/c vssadmin.exe delete shadows /all /quiet" wide
        $s7         = "NtQueryDirectoryFile" ascii
        $s8         = "EtwEventWriteFull" ascii
        $s9         = "BackupExecVSSProvider" ascii

    condition:
        uint16(0) == 0x5A4D and
        uint32(uint32(0x3C)) == 0x00004550 and
        uint16(uint32(0x3C) + 4) == 0x014C and
        filesize < 1MB and
        (
            $s1 or
            $s2 or
            ($s3 and $s4 and $s5) or
            ($s6 and $s7 and $s8 and $s9)
        )
}

FAQ

What is Payload ransomware?

Payload ransomware is a Windows ransomware family that appends .payload to encrypted files and uses ChaCha20 encryption with per-file Curve25519 ECDH key exchange.

When did Payload ransomware first appear?

Payload first appeared publicly on 15 February 2026, when it listed SODIC as its first disclosed victim.

How does Payload ransomware encrypt files?

Payload uses ChaCha20 for file encryption. For each file, it generates a fresh Curve25519 victim private key and nonce, derives a shared secret using the operator public key, and uses that shared secret directly as the ChaCha20 key.

What extension does Payload ransomware add?

Payload appends the .payload extension to encrypted files.

What anti-forensics techniques does Payload use?

Payload uses ETW patching, VSS shadow copy deletion, Windows Event Log clearing, and targeted process/service termination to reduce detection and recovery options.v

Conclusion

Payload ransomware is a technically mature Windows locker with a clear operator identity, strong cryptographic design, and aggressive anti-forensics behavior. Although the group appeared recently, its victim listings show fast growth and a global footprint, with noticeable activity in Egypt and the wider MENA region.

The most important technical finding is the ransomware’s per-file encryption design. Payload generates fresh key material and nonces for each file, uses Curve25519 ECDH to derive a ChaCha20 key, and stores recovery material inside an RC4-protected footer. Meanwhile, its anti-forensics layer targets telemetry, recovery mechanisms, logs, processes, and services before or during encryption.

For defenders, Payload should be tracked as an emerging ransomware operation with international ambitions and a technically capable locker. Monitoring its leak site activity, victimology, infrastructure, and future code changes will be essential as the group continues to mature.