# PAYLOAD Ransomware: The GPO Attack Chain, Day by Day

Date: 2026-10-01

The PAYLOAD incident did not detonate when the GPO was written. It detonated when machines rebooted.

That one-day gap is the most useful forensic fact in Kaspersky GERT’s April 2026 case. Weaponisation lived in SYSVOL and the policy cache on 13 April. Visible impact—wallpaper, logon banner, disabled local Administrator, firewall off—arrived on 14 April with the first mass restart. Directory logs and user-visible chaos therefore sit on different days unless you are auditing DS Access.

<!--more-->

This is the chain as reconstructed from the investigation: two domain-root GPOs, SYSVOL staging, delayed computer-configuration apply, parallel exfiltration, and what was *not* on the endpoints.

## Timeline (April 2026)

| Date | What happened |
|---|---|
| **11 Apr** | Compromised domain credential authenticates to FortiGate SSL VPN. |
| **13 Apr** | GPO **PAYLOAD** `{C897F2C7-C2AC-4E6F-BF48-58036FF29E79}` created and linked at the domain root. |
| **13 Apr** | `payload.jpg` and `hello.txt` written to `\\DC.THECOMPANY.local\sysvol\THECOMPANY.local\`. |
| **13 Apr** | GPO **win Firewall Off** `{22099AD2-E062-4F56-B574-5099BBA4E7A6}` linked at the domain root. |
| **13 Apr** | Policy cached on endpoints; computer configuration not yet applied (no reboot). |
| **13 Apr** | Data exfiltration from file servers and additional systems. |
| **14 Apr** | Endpoints reboot under normal procedure. Computer policies apply. Operational disruption begins. |
| **15 Apr** | Kaspersky GERT engaged. |
| **16 Apr** | Assessment: no Windows file encryption, no resident malware, no endpoint persistence. |

The delay is characteristic of GPO operations, not a custom timer implant. Computer configuration (machine wallpaper/lock screen policy, security settings, firewall) applies on reboot or background refresh. User configuration can apply at logon. If nobody reboots, the bomb sits in cache. MFT timestamps plus Group Policy History confirmed staging on the 13th and mass apply on the 14th.

Two consequences for defenders: (1) a quiet window for theft and further staging between write and impact; (2) a broken mental link between “GPO created” (directory) and “the estate looks ransomed” (helpdesk). Without Event 5136/5137 forwarded off-box, you will investigate the wallpaper.

## Stage 1 — Execution without a binary

Kaspersky reconstructed impact with Resultant Set of Policy (RSOP) on affected workstations. The offensive toolkit on Windows was two GPOs. Nothing else was required.

### PAYLOAD GPO — impact as policy

Client-side extensions did the work that malware usually does:

| CSE / extension | Setting | Result |
|---|---|---|
| Files (GPP) | SYSVOL `hello.txt` → Desktop, `C:\`, `D:\` | Read-only `README-payload.txt` |
| Registry (Computer) | `HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\legalnoticecaption` | `Welcome to Payload!` |
| Registry (Computer) | `legalnoticetext` | Ransom demand |
| Personalization | Lock screen image | SYSVOL `payload.jpg` |
| Desktop (User) | Wallpaper | Same `payload.jpg` |
| Security Settings (`GptTmpl.inf`) | Administrator account status | **Disabled** |

Loopback processing mattered. A `Loopback-GPO-List` entry in user Group Policy state meant the wallpaper applied regardless of who logged on. That is how a machine policy plus user personalisation becomes “every session looks ransomed.”

Disabling the built-in Administrator via `GptTmpl.inf` is impact and recovery-inhibition at once ([T1531](https://attack.mitre.org/techniques/T1531/)). Defacement of wallpaper and lock screen is [T1491.001](https://attack.mitre.org/techniques/T1491/001/). Group Policy modification is [T1484.001](https://attack.mitre.org/techniques/T1484/001/). There is no hash of `payload.exe` because there was no `payload.exe` on Windows.

### win Firewall Off GPO — defence impairment

A second domain-root GPO disabled Windows Firewall on domain, private and public profiles ([T1686](https://attack.mitre.org/techniques/T1686/) / T1562.004 in older mappings). Independent of PAYLOAD, it degraded host filtering so later reachability did not depend on the first object. Two GPOs, one intent: lock the estate and keep the network path open.

## Stage 2 — Persistence is the link, not the endpoint

Standard persistence was clean:

- No malicious scheduled tasks
- Run / RunOnce clean
- Startup folders clean
- No malicious service
- No WMI event subscriptions
- MBR unmodified

Live process and memory analysis found no injected threads, hollowing, or anomalous outbound C2 on the workstations at analysis time. Delivery was GPO ([T1071](https://attack.mitre.org/techniques/T1071/) was not confirmed as live C2).

If you wipe a PC and leave the domain-root link, the next `gpupdate` re-infects it. **Containment order is invert-the-usual:** delete the GPOs and SYSVOL artefacts on the DC first, then force refresh, then re-enable Administrator and firewall via a *clean* policy. Endpoint cleanup first is theatre.

Registry breadcrumbs on the workstation still matter for timeline:

- `HKLM\...\Group Policy\History\{35378EAC-683F-11D2-A89A-00C04FBBCFA2}\1`
- `HKLM\...\Group Policy\Shadow\{827D319E-6EAC-11D2-A4EA-00C04F79F83A}\0`
- `HKLM\...\Group Policy\State\Machine\GPO-List\7`
- `HKCU\...\Group Policy\History\{7150F9BF-48AD-4da4-A49C-29EF4A8369BA}\1`
- `HKCU\...\Group Policy\State\S-1-5-21-…\Loopback-GPO-List\5`

Those GUIDs in History/Shadow are CSE identifiers, not the PAYLOAD GPO GUID. Do not hunt the wrong object.

## Stage 3 — Exfiltration in the quiet day

On 13 April, while computer configuration sat unapplied, data left file servers and other systems and was later published. Collection is mapped as [T1005](https://attack.mitre.org/techniques/T1005/). The Windows “ransomware look” was the second act. The first act was theft. Encryptionless extortion needs the leak more than it needs ChaCha20 on `C:\`.

MFT review found no `.payload` extension and no bulk encrypt I/O on Windows. Absence of encryption is not absence of compromise. Domain-admin-equivalent write to GPO is the severity.

## Detection that can see this chain

File- and process-based stacks are structurally blind until wallpaper. Hunt the directory and SYSVOL.

**DS Access (Advanced Audit Policy on every DC), forwarded:**

| Event | Meaning | Hunt |
|---|---|---|
| **5137** | DS object created | Who created `groupPolicyContainer` objects? Must be an authorised GPO admin. |
| **5136** | DS object modified | `gPLink` on domain root or sensitive OUs; `gPCMachineExtensionNames` / `gPCUserExtensionNames` / `gPCFileSysPath` / `versionNumber`. |
| **5141** | DS object deleted | Tamper and remediation. |

A `gPLink` change at the domain root by a non-standard account is the loudest pre-detonation signal. SYSVOL change *without* 5136 can mean direct template edit (PowerView, SharpGPOAbuse, and friends) bypassing GPMC—or broken auditing. Treat missing expected 5136 as suspicious, then verify the audit policy before you declare tradecraft.

**SYSVOL FIM:** unexpected images, text, scripts, `ScheduledTasks.xml`, mutated `registry.pol` / `GptTmpl.inf`, writers that are not DFSR/FRS.

**Endpoint:** Microsoft-Windows-GroupPolicy/Operational plus History/Shadow. A sudden estate-wide change in the applied set is the post-detonation siren.

Kaspersky’s SIEM package `[OOTB] Group policy hijacked: PAYLOAD ransomware – ENG` is built around Sysmon 11 and Security 4663 / 5136 / 4657. EDR rules they name (`gpo_creation`, `setting_the_gpcmachineextensionname_attribute`, `gpo_deletion`) are the same idea: watch the container, not the encryptor.

## Containment sequence (abbreviated)

1. Delete PAYLOAD and win Firewall Off via GPMC (or equivalent).
2. Delete `payload.jpg` and `hello.txt` from SYSVOL.
3. Reset the compromised account; audit privileged groups; rotate `krbtgt` twice if DA compromise is confirmed.
4. `gpupdate /force`; restore Administrator and firewall with a known-good GPO.

Then harden: tiered AD, split create vs link, 5136/5137/5141 to SIEM, SYSVOL integrity, phishing-resistant MFA on VPN, LAPS, PAW, PIM. A canary GPO that should never apply is a cheap tripwire for write access.

The chain is short. The mistake is looking for a long malware path that was never there.

---

### 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 Ransomware Used Two GPOs to Cripple a Company** — IT-Connect — [https://www.it-connect.tech/payload-ransomware-how-attackers-crippled-a-company-with-two-gpos-without-encrypting-a-single-file/](https://www.it-connect.tech/payload-ransomware-how-attackers-crippled-a-company-with-two-gpos-without-encrypting-a-single-file/)
3. **PAYLOAD Ransomware Hijacks Active Directory GPO** — CyPro — [https://cypro.co.uk/insights/cyber-bulletins/payload-ransomware-hijacks-active-directory-gpo/](https://cypro.co.uk/insights/cyber-bulletins/payload-ransomware-hijacks-active-directory-gpo/)
4. **Audit Directory Service Changes** — Microsoft — Event IDs 5136, 5137, 5141

**Incident response that starts on the workstation will re-infect the workstation.** I advise on AD-first containment and the audit trail that would have caught this on 13 April, not 14. [Contact me](https://goldmanmalka.com/about).