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.
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, 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). 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). 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). 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/EtwRegisterin the ransomware’s ownntdllmapping. 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,
execInstalledOnlyoff, 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; RansomLook) 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:
- Debugger check:
/proc/self/status→TracerPid:; non-zero leads to self-delete. - Inventory: parse
/etc/vmware/hostd/vmInventory.xml(//ConfigEntry), pull VM paths;vim-cmd vmsvc/power.offto shut VMs down before touching disks. - Targeting: encrypt files > 5 GB—the VMDK-shaped objects—skip already-suffixed
.xx0001. - 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.
- 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). - Note: overwrite ESXi UI greeting
/usr/lib/vmware/hostd/docroot/ui/welcome.txt—same “Welcome to Payload!” product language as the Windows legal notice. - Threads: pool ~2× CPU cores;
prctlnamesFBIthread-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
- Group Policy hijacked: PAYLOAD ransomware weaponizes Active Directory GPO — Kaspersky GERT, Securelist — https://securelist.com/tr/payload-ransomware-via-group-policy/121335/
- Payload Threat Actor Ransomware — Abdullah Islam (0x3oBAD), ESXi sample RE (Apr 2026) — https://0x3obad.github.io/posts/payload-ransomware-writeup/
- Payload / Esxi — Technical Analysis — RansomLook — https://www.ransomlook.io/group/payload/analysis/esxi
- 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
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.