Payload was first observed in mid-February 2026. The analyzed Windows binary was compiled on 17 February 2026 (08:39 UTC), and the first victim appeared on the leak site within hours. Public technical write-ups followed in March 2026. Trackers (Ransomware.live, WatchGuard) and follow-on reporting continue to record active postings through at least June 2026.

The Babuk linkage is the best-supported claim in the profile. It rests on direct binary comparison against the leaked Babuk source, plus broad anti-virus consensus. No major vendor publicly disputes the Babuk-derived characterization.

Payload inherits Babuk code, not Conti code. Accordingly, Conti-cluster parent designations do not apply to this profile. Wizard Spider (CrowdStrike) and Gold Ulrick (Secureworks) describe the parent Conti organization and are not relevant to Babuk-derived families. Babuk's own operators were tracked separately (for example Secureworks Gold Northfield); that designation attaches to the original Babuk crew, not to Payload.

For Payload itself, no group-specific vendor codename exists in open source as of June 2026. The Babuk-derivative assessment is made explicitly by Derp.ca and independent researchers and echoed by Ransomware.live; it is not yet framed as a formal lineage finding by large IR vendors such as Mandiant or CrowdStrike.

Several news outlets describe Payload as ransomware-as-a-service, but that label is repeated without supporting evidence. The primary static analysis is explicit that no public source shows an affiliate program, recruitment, revenue-share terms, or a builder panel. Treat RaaS branding as unverified.

The one ambiguous signal toward multiple operators is that the Windows and Linux/ESXi builds carry different embedded operator public keys, consistent with per-campaign or per-affiliate key generation. This is suggestive but not conclusive. On current evidence, the working assessment is a small closed crew or a limited builder-based operation rather than a broad RaaS marketplace.

• Exfiltration first: data is stolen before encryption, creating two leverage points.
• Encryption: files locked with the .payload extension; recovery infeasible without the operator key.
• Negotiation portal: each victim receives unique credentials for a Tor portal. Up to 3 free file decryptions (15 MB each) are offered as proof of capability.
• Publication threat: a separate Tor leak blog publishes stolen data under countdown timers if payment is not made.
• Offline operation: the payload stage has no command-and-control traffic; the binary is fully self-contained.

The decrypted ransom note frames a 72-hour initial pressure window (file-tree publication and naming of the company) and a 240-hour total negotiation window. No wallet address appears in the note; payment is arranged exclusively through the Tor portal. There is no public corpus of negotiation transcripts yet, so demand ranges, discounting behavior, and payment timing remain intelligence gaps.

Both sites were confirmed reachable as of mid-March 2026. The distinct backends (portal versus nginx leak blog) indicate deliberate separation of negotiation and publication infrastructure.

The Windows build is roughly ten times larger than the Linux build, mostly due to static MSVC runtime linking plus the service/process kill lists, event-log wiper, and ETW patcher, none of which exist in the ESXi build.

Public analysis focuses on the payload stage. No specific initial access vector (RDP, phishing, VPN/edge-device exploitation) and no exploited CVE have been documented for Payload. This is a primary gap. No Payload-specific CVE exists to verify against the NVD.

• Per-file keypair: CryptGenRandom produces a 32-byte Curve25519 private key (clamped) and a 12-byte ChaCha20 nonce for each file.
• ECDH: the shared secret of the per-file private key and the embedded operator public key is used directly as the ChaCha20 key, with no key-derivation step.
• Cipher: ChaCha20 in 1 MB chunks. Files over 2 GB are partially encrypted (about 20%, in evenly spaced 1 MB chunks) for speed on large volumes.
• Footer: a 56-byte footer is appended, RC4-encrypted with the 3-byte key "FBI"; it holds the per-file public key, nonce, and a payload\0 marker.
• Key hygiene: the per-file private key is zeroed from memory immediately after the footer is written and never touches disk.

• ETW patching: patches four ntdll functions (EtwEventWrite, EtwEventWriteFull, EtwEventWriteTransfer, EtwRegister) to return immediately, blinding EDR that relies on ETW.
• Event-log wipe: loads wevtapi.dll at runtime and clears every Windows event-log channel via EvtClearLog.
• NTFS ADS self-deletion: renames its own data stream to an Alternate Data Stream (:payload), releasing the file lock so the executable deletes on close with no child process or temp batch file.
• Shadow copies and recycle bin: deletes shadow copies via vssadmin.exe delete shadows /all /quiet and empties the recycle bin.
• Kill lists: stops ~34 services (Veeam, Acronis, BackupExec, Symantec/Veritas, Sophos, Qihoo 360, Intuit QuickBooks) and ~31 processes (SQL, Oracle, Office suite, Thunderbird, Firefox, Steam).

Payload ships a Windows PE and a Linux/ESXi ELF. The ESXi build links libxml2 and parses /etc/vmware/hostd/vmInventory.xml via XPath to locate VM disk paths for targeted encryption; it uses a C thread pool and /dev/urandom, and lacks the Windows anti-forensics. The core crypto is identical across builds, but the operator public keys differ, indicating per-campaign or per-affiliate key generation.

Public analyses do not confirm a hardcoded CIS locale or keyboard kill switch. In the absence of evidence, CIS-exclusion behavior should be treated as unknown rather than assumed.

No practical cryptographic weakness or universal decryptor exists. Defense must rely on prevention, detection, and immutable offline backups.

Primary reporting cites healthcare, real estate, energy, telecom, and agriculture, particularly in emerging markets. Ransomware.live's aggregate view (which includes later victims) lists manufacturing, business services, consumer services, healthcare, and financial services among top activity sectors. The range suggests opportunistic targeting guided by perceived ability to pay rather than strict ideological criteria.

Seven countries affected at the March snapshot, weighted toward emerging-market regions. Documented or sampled locations include Bahrain (Royal Bahrain Hospital), the Philippines, Egypt, Mexico, and Thailand. No CIS-region victims are documented, but no explicit CIS exclusion has been confirmed either.

Targeting focuses on mid-size and large organizations (healthcare providers, real-estate firms, energy/telecom, agriculture). There is no evidence of consumer targeting. The most prominent named victim to date is Royal Bahrain Hospital, a 70-bed private facility, listed 15 March 2026 with 110 GB claimed stolen and a 23 March publication deadline. The group's low overall count and recency mean few brand-name enterprises have been named so far.

Payload sits inside a documented Babuk-derivative family. The ClamAV signature Win.Ransomware.Babuk-10032520-1 matches 154 samples across eight operations sharing the leaked codebase: RAWorld (143), Babuk original (4), Nitrogen (2), Payload (1), plus SchoolBoy, Neshta, and Cylan.

Current trackers (Ransomware.live, WatchGuard, SOC Prime) all treat Payload as an independent entry, acknowledging code heritage without merging it with Babuk or other families.

Payload ramped quickly from inception to roughly a dozen victims in its first month, reaching 16 or more by late March and remaining active through June 2026. It integrated strong crypto, ETW patching, ADS self-deletion, and partial encryption from the outset, indicating a relatively mature technical baseline, and ships Linux/ESXi variants with multi-platform YARA coverage, suggesting ongoing development. With no seizures or arrests reported, the group appears operationally intact, though its short history makes longer-term trajectory (rising versus plateauing) unclear.

• Initial access and intrusion ecosystem (access brokers, phishing kits, specific CVEs).
• Negotiation and ransom-demand patterns; payment amounts.
• Cryptocurrency types, wallet infrastructure, and laundering pathways.
• Geographic base, language indicators, and any law-enforcement interest.
• Whether the differing per-build operator keys reflect multiple affiliates or a single operator running separate campaigns.