# PAYLOAD Ransomware Itself: Family Capabilities vs What Ran in This Incident

Date: 2026-10-02

PAYLOAD is easy to misname after the Kaspersky GPO case.

On Windows, in that manufacturing incident, it behaved like a policy weapon: notes, wallpaper, lock screen, Administrator disabled, firewall off, data stolen. No encryptor on disk. On Linux servers in the *same* environment, GERT recovered an ESXi-targeting PAYLOAD sample. Public reverse engineering of `locker_esxi.elf` shows a conventional, well-engineered hypervisor encryptor. The Windows family, analysed from other samples, still knows how to kill security processes, wipe logs, and delete VSS.

<!--more-->

Those are not the same artefact. Mixing them is how you write detections for encryption I/O that never happened, or skip ESXi because “this strain doesn’t encrypt.”

## Two bodies, one extortion brand

**This incident (Windows endpoints).** Kaspersky confirmed: no `.payload` files, no bulk encrypt patterns in the MFT, no resident malicious binary, no endpoint persistence, no live malicious process at analysis time. Impact was GPO. The only ransomware binary in-scope was ESXi/Linux. Stolen file-server data was later published.

Kaspersky’s moderate-confidence read of missing Windows encryption: either a deliberate stay below irreversible destruction (keep a follow-on encrypt option), or an operation interrupted. Do not read “no encryption” as a failed ransomware job. Domain-admin-equivalent control plus a leak is the job.

**PAYLOAD as a family.** Independent tracking (e.g. [0x3oBAD](https://0x3obad.github.io/posts/payload-ransomware-writeup/), citing public victimology) described an actor active from February 2026 with victims across several countries. Treat victim lists as OSINT, not as GERT findings. The point is: the name on the wallpaper is a brand that also ships encryptors.

## What public RE says the Windows encryptor can do

Kaspersky is explicit: the following are **family-level** behaviours from public sample analysis. They were **not** confirmed as executed in the GPO incident unless host, memory, process, event-log or hypervisor evidence said so. Use them to enrich detections. Do not write them into *this* IR timeline as facts.

**Event log clearing ([T1685.005](https://attack.mitre.org/techniques/T1685/)).** Dynamic resolve of `wevtapi.dll`: `EvtOpenChannelEnum`, `EvtNextChannelPath`, `EvtClearLog`; channels including Security, System, Application, PowerShell; command-line switch to enable. Indicators: Security **1102**, channel record IDs resetting, gaps vs forwarded logs. 1102 alone is not enough—correlate 4688/Sysmon 1, 4624, EDR trees, WEF. Absence of 1102 does not prove logs were untouched (direct EVTX wrecking, service kill, bad audit).

**Security process and service termination ([T1489](https://attack.mitre.org/techniques/T1489/)).** Stop EDR, backup, databases, lock holders. Indicators: 7036/7040, Sysmon 5, estate-wide agent death, dedicated killers. GERT published two process-killer hashes used as IOCs for the *ecosystem* of this case, not as “ran on every workstation”:

| File | MD5 |
|---|---|
| `killer.exe` | `0108656A3E1ADE6CA4F21B084F5E1208` |
| `kill.exe` | `BEA5E267F24D7DA59F6821BFFDBFF293` |

**VSS / recovery inhibition ([T1490](https://attack.mitre.org/techniques/T1490/)).** Shadow copies deleted before encryption in the encrypting Windows sample. Broader backup-platform compromise was **not** established in the investigated incident. Hunt `vssadmin`/`wmic shadowcopy`, catalog wipes, backup admin logons off-hours, jobs failing immediately before impact.

## Ecosystem techniques—do not pin them on this sample

Kaspersky lists three as **common ransomware tradecraft**, not proven PAYLOAD intrinsics and not seen in this IR:

- **Process-local ETW patching** of `EtwEventWrite` / `EtwEventWriteFull` / `EtwEventWriteTransfer` / `EtwRegister` in the ransomware’s own `ntdll` mapping. Not a global ETW kill. Strongest proof is memory.
- **BYOVD** (signed vulnerable drivers). Relevant to modern ransomware. Public PAYLOAD analyses were insufficient to call it a family feature.
- **ESXi policy weakening** (SSH on, `execInstalledOnly` off, lockdown exceptions, snapshot wipe, custom binaries on datastores). Operationally relevant because an ESXi PAYLOAD binary *was* present. GERT did **not** show those policy changes in the investigated hypervisor evidence.

If you put BYOVD in a “PAYLOAD always does X” slide, you are writing fiction.

## The ESXi locker (public analysis)

Independent analysis of `locker_esxi.elf` ([0x3oBAD](https://0x3obad.github.io/posts/payload-ransomware-writeup/); [RansomLook](https://www.ransomlook.io/group/payload/analysis/esxi)) describes a 64-bit ELF built for ESXi:

| Field | Value |
|---|---|
| SHA-256 | `bed8d1752a12e5681412efbb8283910857f7c5c431c2d73f9bbc5b379047a316` |
| MD5 | `f91cbdd91e2daab31b715ce3501f5ea0` |
| Notes | Stripped ELF; strings RC4-obfuscated (3-byte key `FBI`) then used at runtime |

Behaviour that matters operationally:

1. **Debugger check:** `/proc/self/status` → `TracerPid:`; non-zero leads to self-delete.
2. **Inventory:** parse `/etc/vmware/hostd/vmInventory.xml` (`//ConfigEntry`), pull VM paths; `vim-cmd vmsvc/power.off` to shut VMs down before touching disks.
3. **Targeting:** encrypt files **> 5 GB**—the VMDK-shaped objects—skip already-suffixed `.xx0001`.
4. **Crypto:** per-file X25519 (Curve25519) ephemeral keypair, shared secret with attacker public key, **ChaCha20** (scalar / SSE2 / AVX2 selected via CPUID). Partial encryption: five segments, up to ~1 GB each, in-place. Fast enough to brick a datastore without waiting to encrypt 80 TB.
5. **Footer:** ~56-byte trailer including ephemeral public key (lightly RC4’d) and magic consistent with `payload\0` (`70 61 79 6C 6F 61 64 00`).
6. **Note:** overwrite ESXi UI greeting `/usr/lib/vmware/hostd/docroot/ui/welcome.txt`—same “Welcome to Payload!” product language as the Windows legal notice.
7. **Threads:** pool ~2× CPU cores; `prctl` names `FBIthread-pool-%d`—a cheap host IOC.

Ransom copy in the note is classic double extortion: 72 hours before naming/tree publication, 240 hours to negotiate, Tor portal, proof decrypts of small files. That matches theft-first Windows GPO plus a hypervisor encryptor if they choose to burn the estate.

This ESXi write-up is **not** Kaspersky’s IR appendix. Do not assert that `bed8d175…` is the exact hash GERT recovered unless they publish it. It is the publicly analysed PAYLOAD ESXi lineage that explains what “we found a PAYLOAD sample targeting ESXi” is capable of.

## IOCs from the GPO incident (Windows / AD)

Use these for the *policy* attack. They will not find the ELF.

**GPO GUIDs**

- PAYLOAD: `{C897F2C7-C2AC-4E6F-BF48-58036FF29E79}`
- win Firewall Off: `{22099AD2-E062-4F56-B574-5099BBA4E7A6}`

**Files:** `payload.jpg`, `hello.txt` (SYSVOL) → `README-payload.txt` on Desktop/`C:`/`D:`.

**Registry:** `legalnoticecaption = Welcome to Payload!`

**Hunting IPs** (from GERT; defang in your TI platform): `37.19.210.12`, `146.70.117.239`, `149.102.229.154`, `104.164.55.46`, `104.28.162.228`, `104.28.163.162`, `64.190.76.14`, `192.42.116.50`, `192.42.116.12`, `192.42.116.56`, `192.42.116.97`, `192.42.116.52`.

**Events:** 5137 (GPO create), 5136 (`gPLink` / GPO attributes).

## What to actually detect

| Layer | Signal |
|---|---|
| AD | New `groupPolicyContainer`; domain-root `gPLink`; SYSVOL non-replication writes |
| Windows host (this case) | Policy History/Shadow; legal notice; wallpaper from SYSVOL; Administrator disabled; firewall GPO |
| Windows host (family) | 1102, VSS delete, security service death, killer hashes |
| ESXi | `welcome.txt` ransom HTML; `.xx0001`; `FBIthread-pool-*`; unexpected `vim-cmd` power-off; ELF with ChaCha20 constant + `vmInventory.xml` strings |

A SOC that only alerts on `vssadmin delete shadows` would have graded this incident as a wallpaper ticket. A SOC that only alerts on GPO would miss the next PAYLOAD job that *does* run the Windows encryptor. You need both, labelled as **family** vs **this campaign**.

---

### Relevant Sources

1. **Group Policy hijacked: PAYLOAD ransomware weaponizes Active Directory GPO** — Kaspersky GERT, Securelist — [https://securelist.com/tr/payload-ransomware-via-group-policy/121335/](https://securelist.com/tr/payload-ransomware-via-group-policy/121335/)
2. **Payload Threat Actor Ransomware** — Abdullah Islam (0x3oBAD), ESXi sample RE (Apr 2026) — [https://0x3obad.github.io/posts/payload-ransomware-writeup/](https://0x3obad.github.io/posts/payload-ransomware-writeup/)
3. **Payload / Esxi — Technical Analysis** — RansomLook — [https://www.ransomlook.io/group/payload/analysis/esxi](https://www.ransomlook.io/group/payload/analysis/esxi)
4. **Kaspersky uncovers new ‘Payload’** — Kaspersky press release — [https://www.kaspersky.com/about/press-releases/kaspersky-uncovers-new-payload-the-stealth-ransomware-that-hijacks-corporate-devices-without-encrypting-files](https://www.kaspersky.com/about/press-releases/kaspersky-uncovers-new-payload-the-stealth-ransomware-that-hijacks-corporate-devices-without-encrypting-files)

**If you want this split turned into detections—GPO write vs ESXi locker vs Windows family behaviours, without collapsing them into one useless “PAYLOAD” rule—that is engineering I do with security teams.** [Contact me](https://goldmanmalka.com/about).