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.
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). Defacement of wallpaper and lock screen is T1491.001. Group Policy modification is 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 / 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 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}\1HKLM\...\Group Policy\Shadow\{827D319E-6EAC-11D2-A4EA-00C04F79F83A}\0HKLM\...\Group Policy\State\Machine\GPO-List\7HKCU\...\Group Policy\History\{7150F9BF-48AD-4da4-A49C-29EF4A8369BA}\1HKCU\...\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. 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)
- Delete PAYLOAD and win Firewall Off via GPMC (or equivalent).
- Delete
payload.jpgandhello.txtfrom SYSVOL. - Reset the compromised account; audit privileged groups; rotate
krbtgttwice if DA compromise is confirmed. 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
- Group Policy hijacked: PAYLOAD ransomware weaponizes Active Directory GPO — Kaspersky GERT, Securelist — https://securelist.com/tr/payload-ransomware-via-group-policy/121335/
- 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/
- PAYLOAD Ransomware Hijacks Active Directory GPO — CyPro — https://cypro.co.uk/insights/cyber-bulletins/payload-ransomware-hijacks-active-directory-gpo/
- 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.