Tags: Payload ransomware, data broker extortion, double extortion, Tor leak site, ESXi ransomware, RECOVERY-xx0001.txt, IOCs, incident response
Published: 21 February 2026 (Europe/London)
1. Executive Summary
Payload is an emerging ransomware and extortion brand first publicly tracked in February 2026, with open-source reporting indicating at least a small number of victim claims across multiple countries and sectors. WatchGuard categorises Payload as a “Data Broker” and lists direct extortion and double-extortion behaviours, suggesting a leak-site driven model. (watchguard.com)
A publicly shared ransom note titled RECOVERY-xx0001.txt uses aggressive timelines (72 hours to make contact, 240 hours to conclude negotiations) and threatens publication of a victim “file tree” and naming on a Tor-hosted blog. (ransomware.live)
At the time of writing, there is no reliable public reporting attributing Payload to a known ransomware family or established threat actor cluster. Technical artefacts available in public sandboxes indicate at least one Linux-targeting binary that appears to check for VMware-related inventory files, which may indicate interest in virtualised environments such as ESXi. (joesandbox.com)
2. Contextual Background
2.1 Nature of the threat
WatchGuard’s ransomware tracker lists Payload as active, first seen in February 2026, and identifies a Tor-based extortion link. (watchguard.com)
Open-source leak-site monitoring also publishes a Payload-branded ransom note (RECOVERY-xx0001.txt) that explicitly references both data publication and decryption “proof” (decrypting up to three files), consistent with double-extortion playbooks. (ransomware.live)
2.2 Threat-actor attribution
Confidence: Possible. There is insufficient public evidence to credibly link Payload to a named actor (for example, a known ransomware-as-a-service operation, affiliate programme, or malware family). Public trackers currently show limited enrichment (for example, “TTPs Matrix” not populated). (ransomware.live)
2.3 Sector and geographic targeting
WatchGuard lists victims spanning Egypt, Mexico, Thailand, across sectors including real estate and housing, retail and wholesale, food and beverage, and engineering services (based on extortion-date entries). (watchguard.com)
Separately, ransomware leak-site aggregation attributes at least two named victim postings (including one in Egypt and one in Mexico) around 17 February 2026. (ransomware.live)
3. Technical Analysis
3.1 Publicly observed artefacts and TTPs
Ransom note behaviour and comms channel
The Payload note (RECOVERY-xx0001.txt) instructs victims to use Tor, references a Tor-hosted “blog” and a separate Tor-hosted login portal (“Payload Rescue”), and threatens public release when timers expire. (ransomware.live)
This aligns with anonymity infrastructure usage consistent with T1090.003 (Proxy: Multi-hop Proxy), given Tor’s multi-hop design.
Potential Linux and virtualisation targeting signals (inference)
A Linux analysis report for a publicly shared binary (hash listed in IOC section) shows the sample attempting to access /etc/vmware/hostd/vmInventory.xml, and error output indicates the file was not present in the sandbox environment. This behaviour may indicate logic designed to operate in VMware-hosted contexts (for example, querying VM inventory on ESXi or VMware-managed hosts), but this intent cannot be confirmed from this artefact alone. (joesandbox.com)
Observed system interaction
In the same sandbox report, the sample executed rm commands, which can map to T1070.004 (Indicator Removal: File Deletion) when used to remove artefacts, though in this run it may have been limited to cleaning temporary files. (joesandbox.com)
The sample also read CPU information from /sys, aligning with T1082 (System Information Discovery). (joesandbox.com)
Encryption for impact (actor-claimed, not independently validated here)
The ransom note references “encrypted files” and offers limited decryption as proof, consistent with T1486 (Data Encrypted for Impact). This remains an actor claim absent a full public technical teardown of encryption routines for Payload. (ransomware.live)
3.2 Exploitation status
At time of writing, public leak-site monitoring does not list a confirmed exploited vulnerability chain or a populated TTP matrix for Payload, and WatchGuard’s entry is explicitly “under construction”, indicating limited validated telemetry. (ransomware.live)
No responsible disclosure proof-of-concept exploitation or vendor advisory has been publicly tied to “Payload” as an initial access vector in the sources referenced above. (ransomware.live)
4. Impact Assessment
4.1 Severity and scope
Ransomware and extortion incidents commonly combine operational disruption with secondary impacts such as data exposure, regulatory reporting, legal cost, and reputational damage. UK organisations should treat any credible exfiltration claim as a potential personal data breach until disproven, consistent with ICO guidance on ransomware and data protection compliance. (ICO)
Even where decryption becomes possible, recovery at scale is frequently slower than restoring from tested backups and clean rebuilds, reflected in UK NCSC guidance for organisations considering payment in ransomware incidents. (NCSC)
4.2 Victim profile
Based on WatchGuard’s public tracker, early victim claims span multiple verticals and geographies, suggesting opportunistic targeting rather than a narrow sector focus at this stage. (watchguard.com)
5. Indicators of Compromise (IOCs)
5.1 IOC table
| Type | Value | Context/Notes | Source |
|---|---|---|---|
| Ransom note filename | RECOVERY-xx0001.txt | Payload-branded note name used to instruct Tor-based negotiation | Ransom note: RECOVERY-xx0001.txt (Payload) (ransomware.live) |
| Onion (leak site) | payloadrz5yw227brtbvdqpnlhq3rdcdekdnn3rgucbcdeawq2v6vuyd.onion | Referenced as a Tor “blog” in the ransom note and listed as a known location | Ransom note: RECOVERY-xx0001.txt (Payload) (ransomware.live) |
| Onion (negotiation portal) | payloadynyvabjacbun4uwhmxc7yvdzorycslzmnleguxjn7glahsvqd.onion | Referenced as a Tor login portal (“Payload Rescue”) in the ransom note and listed as a known location | Ransom note: RECOVERY-xx0001.txt (Payload) (ransomware.live) |
| SHA-256 | bed8d1752a12e5681412efbb8283910857f7c5c431c2d73f9bbc5b379047a316 | Publicly listed sample; analysed as a Linux binary in Joe Sandbox | Joe Sandbox report (Linux) for bed8d175… (joesandbox.com) |
| SHA-1 | 8cb89289bcfd1bfb96f5ea2dcd174be266cd50b5 | Associated with the same sample in Joe Sandbox | Joe Sandbox report (Linux) for bed8d175… (joesandbox.com) |
| MD5 | f91cbdd91e2daab31b715ce3501f5ea0 | Associated with the same sample in Joe Sandbox | Joe Sandbox report (Linux) for bed8d175… (joesandbox.com) |
| File path (potential targeting clue) | /etc/vmware/hostd/vmInventory.xml | Sample attempted to load this file in Joe Sandbox (VMware inventory reference) | Joe Sandbox report (Linux) for bed8d175… (joesandbox.com) |
5.2 Detection guidance
High-signal detections (low false positive, where applicable)
- Alert on creation of
RECOVERY-xx0001.txt(and consider broaderRECOVERY-*.txt) across endpoints and file shares, especially if coupled with spikes in file rename/write operations. (ransomware.live) - Monitor DNS and network telemetry for Tor usage patterns and known Tor bootstrap domains, and proxy egress to anonymity networks where policy allows, mapping to T1090.003. (attack.mitre.org)
Example YARA rule (ransom note string match)
rule RansomNote_Payload_RECOVERY_xx0001
{
meta:
description = "Detects Payload ransom note content (RECOVERY-xx0001.txt) by unique strings"
author = "CTI"
reference = "Public ransom note text via ransomware.live"
strings:
$s1 = "Welcome to Payload!" ascii nocase
$s2 = "The next 72 hours" ascii nocase
$s3 = "We are giving you 240 hours" ascii nocase
$s4 = "Payload Rescue" ascii nocase
condition:
2 of ($s*)
}
Example Sigma-style logic (file creation)
If you use Sigma, model a rule on file creation events for RECOVERY-*.txt (Windows Sysmon Event ID 11, or EDR file telemetry). Use the upstream Sigma repository for field conventions and backend mappings: SigmaHQ rule repository.
6. Incident Response Guidance
6.1 Containment, eradication, recovery
- Isolate impacted hosts (network quarantine) and preserve volatile evidence before rebooting where feasible. Follow NCSC’s guidance on mitigating malware and ransomware, prioritising rapid containment to prevent lateral movement and further encryption. (NCSC)
- Do not rely on decryption as your recovery plan. NCSC notes that even with a key, restoration across complex estates can be slow; tested backups are typically the safer recovery route. (NCSC)
- Use CISA’s structured playbook-style resources for response activities, including triage and recovery checklists: CISA StopRansomware Guide and CISA “I’ve Been Hit By Ransomware”. (cisa.gov)
6.2 Forensic artefacts to collect and preserve
- Ransom note files (
RECOVERY-xx0001.txt) and any related scripts, scheduled tasks, persistence artefacts, and newly created local accounts. (ransomware.live) - EDR process trees around suspicious file activity, especially command execution consistent with T1059.004 (Unix Shell) and deletion patterns consistent with T1070.004. (joesandbox.com)
- Network logs for outbound Tor usage and any connections to known extortion infrastructure (treat as intelligence, not definitive attribution). (ransomware.live)
6.3 Lessons learned and prevention
- Validate restore procedures through regular recovery exercises and ensure backups are offline or otherwise protected from modification, reflecting StopRansomware best practices. (cisa.gov)
- Tighten identity controls for remote administration, and reduce exposed management services. NCSC’s ransomware materials emphasise governance, preparedness, and practical resilience measures. (NCSC)
7. Threat Intelligence Contextualisation
7.1 Comparison to broader extortion trends
WatchGuard’s “Data Broker” label for Payload aligns with wider industry observations that data-only extortion and multi-extortion tactics have grown as adversaries adapt their monetisation models. For example, NCSC has published analysis on ransomware and extortion within the cybercrime ecosystem, and Unit 42 has reported sustained increases in data theft as an extortion lever. (NCSC)
Notably, the Payload ransom note still references “encrypted files”, suggesting Payload may not be purely data-only in practice, or that affiliates deploy encryption selectively. This discrepancy should be treated as an intelligence gap until validated through technical reports or incident disclosures. (ransomware.live)
7.2 MITRE ATT&CK mapping (observed and actor-claimed)
| Tactic | Technique ID | Technique Name | Observed Behaviour |
|---|---|---|---|
| Command and Control | T1090.003 | Proxy: Multi-hop Proxy | Tor-based negotiation and leak-site references in ransom note |
| Discovery | T1082 | System Information Discovery | Linux sample reads CPU info from /sys in sandbox |
| Discovery | T1083 | File and Directory Discovery | Linux sample attempts to access VMware inventory file path (possible environment check) |
| Defence Evasion | T1070.004 | Indicator Removal: File Deletion | Linux sample executes rm commands in sandbox run |
| Impact (actor-claimed) | T1486 | Data Encrypted for Impact | Ransom note references “encrypted files” and offers limited decryption proof |
8. Mitigation Recommendations
8.1 Actionable hardening steps
- Enforce phishing-resistant MFA for privileged access and remote administration, and restrict where administrative interfaces can be reached from (jump hosts, VPN with strong controls, conditional access). (cisa.gov)
- Segment backup infrastructure and test restoration frequently. Adopt immutable or offline backups where feasible. (cisa.gov)
- Reduce lateral movement paths: least privilege, separate admin workstations, and minimise shared local admin credentials.
8.2 Patch management advice (prioritisation)
Where Payload is suspected to target virtualised environments, ensure VMware and hypervisor management services are fully patched and not internet-exposed. Prioritise remediation for historically exploited ESXi vulnerabilities, including:
- CVE-2020-3992: Broadcom Advisory for CVE-2020-3992 (VMSA-2020-0023) and NVD (CVSS v3.x 9.8; listed in CISA KEV per NVD references). (nvd.nist.gov)
- CVE-2021-21974: Broadcom Advisory for CVE-2021-21974 (VMSA-2021-0002) and NVD (CVSS v3.x 8.8). (Support Portal)
If patching is not immediately possible, follow vendor workarounds and reduce exposure of management services (for example, avoid exposing SLP and other hypervisor management ports). (nvd.nist.gov)
9. Historical Context & Related Vulnerabilities
9.1 Previously exploited vulnerabilities in related product families
Ransomware campaigns have repeatedly leveraged weaknesses in VMware ESXi and related components, particularly where management services were exposed or hosts were outdated. Historical examples include OpenSLP-related ESXi issues such as CVE-2020-3992 and CVE-2021-21974, both documented in vendor advisories and NVD, and discussed in third-party incident research on ESXi-targeting ransomware waves. (nvd.nist.gov)
9.2 Related third-party coverage
- For incident-response framing and extortion ecosystem context: NCSC whitepaper on ransomware and extortion. (NCSC)
- For observed growth in multi-extortion: Unit 42 analysis on multi-extortion rise. (Unit 42)
10. Future Outlook
Payload appears to be in an early operational phase, with public trackers still building coverage. If the “Data Broker” model holds, defenders should expect continued emphasis on leak-site pressure, including harassment, accelerated countdowns, and selective data releases to force engagement. (watchguard.com)
The available Linux artefact and VMware-related file access attempts may indicate an interest in virtualisation layers, which historically provide high-impact blast radius when compromised. If confirmed in future reporting, organisations with ESXi and other hypervisors should treat this as a priority defence area. (joesandbox.com)
11. Further Reading
- Vendor and trackers
- Malware analysis artefacts
- Defender guidance
