In April 2026 a single Group Policy Object named PAYLOAD, linked at the domain root, delivered domain‑wide ransom notes, hijacked wallpapers and lock screens, enforced a logon banner and disabled the local Administrator account — all without dropping a single ransomware binary on endpoints, Kaspersky’s Global Emergency Response Team (GERT) reports.
How the PAYLOAD GPO achieved impact
Kaspersky’s investigation reconstructed an attack that weaponized native Active Directory Group Policy rather than conventional malware. The attacker created two domain‑root linked GPOs: PAYLOAD ({{C897F2C7-C2AC-4E6F-BF48-58036FF29E79}}) and win Firewall Off ({{22099AD2-E062-4F56-B574-5099BBA4E7A6}}). PAYLOAD used Group Policy Preference and registry CSEs to:
- drop \\DC.THECOMPANY.local\sysvol\THECOMPANY.local\hello.txt to desktops and root drives as README-payload.txt;
- set \\DC.THECOMPANY.local\sysvol…\payload.jpg as both wallpaper and lock screen image;
- modify HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\legalnoticecaption to “Welcome to Payload!” and legalnoticetext to display the ransom demand;
- disable the built‑in Administrator account by editing Security Settings in the GptTmpl.inf file.
The separate win Firewall Off GPO disabled Windows Firewall across domain, private and public profiles, degrading host defenses independently of the visual disruption.
April 2026 intrusion timeline
Kaspersky reconstructed the key events as follows: initial access occurred on 11 April via a compromised domain credential used against a FortiGate SSL VPN. On 13 April the attacker authored and linked PAYLOAD at the domain root and staged payload.jpg and hello.txt in SYSVOL. The GPOs were cached on endpoints that day but many machines had not rebooted, so the computer configuration did not apply. On 14 April endpoints began rebooting and the policy applied en masse, producing the visible ransom wallpaper, logon banner and disabled local Administrator accounts. Kaspersky observed data exfiltration from file servers on 13 April and later publication of stolen data on the dark web. GERT engaged on 15 April and confirmed on 16 April that no Windows file encryption, resident malware, or endpoint persistence was present.
This site is the portfolio.
OSINTSights runs on Cloudflare Workers, D1, R2, and Vectorize, with an AI pipeline on Hetzner ARM. Nubivance designed, built, and operates it. We do the same for clients.
See what we buildKaspersky GERT forensic findings
The investigation produced several notable technical findings:
- No file encryption on Windows endpoints — MFT review found no .payload file signatures or bulk renaming/encryption I/O patterns;
- No endpoint‑resident malware or persistence mechanisms — scheduled tasks, Run keys, startup folders, services, WMI event subscriptions and boot sectors were clean;
- Policy application artifacts in registry keys (Group Policy History, Shadow and State) confirmed PAYLOAD applied in loopback mode so user wallpaper applied regardless of user account;
- Two files staged in SYSVOL: payload.jpg (ransom image) and hello.txt (ransom note), and the note dropped as README-payload.txt on desktops and drive roots.
Detection engineering, SIEM rules and indicators
Kaspersky emphasizes detection in the directory and SYSVOL layer rather than file/process indicators. High‑value telemetry includes Directory Service Change auditing (Advanced Audit Policy → DS Access → Audit Directory Service Changes) with alerts for Event IDs 5137 (object creation), 5136 (object modification) and 5141 (object deletion). Key SIEM signatures and rules Kaspersky prepared include:
- GPO creation or domain‑root gPLink change by a non‑standard account;
- file creation/modification under \\DC.THECOMPANY.local\sysvol\THECOMPANY.local\Policies\ from non‑replication sources;
- detection of Windows Event Log clearing, LSASS access, shadow copy deletion, Defender disablement, and firewall registry modifications (rule package names and IDs provided by Kaspersky).
Kaspersky published a SIEM rule package named “[OOTB] Group policy hijacked: PAYLOAD ransomware – ENG” and listed IOCs including the two GPO GUIDs, filenames (payload.jpg, hello.txt, README-payload.txt) and MD5 hashes for killer.exe and kill.exe. The report also provides a list of related IP addresses observed in the incident.
What this means for VPN operators, Active Directory administrators, and security teams
- VPN operators: ensure detailed, centrally collected FortiGate SSL VPN logging (auth events, session detail, source IP geolocation) — Kaspersky highlights insufficient FortiGate logging as a gap in this case.
- Active Directory administrators: separate GPO creation from linking rights, enable GPO change auditing (5136/5137/5141), monitor SYSVOL with file integrity tooling and consider a canary GPO to detect unauthorized write access.
- Security teams and SIEM engineers: shift detection to include directory‑service and SYSVOL events; deploy the Kaspersky SIEM rule set where appropriate and ensure Security event auditing for 4663, 5136, 4657, 7036 and 1102 is configured.
Conclusion: PAYLOAD turned a trusted, signed distribution channel — Active Directory Group Policy — into the payload, not the delivery mechanism. The decisive lesson in Kaspersky’s April 2026 case is simple and stark: if your detection relies primarily on catching binaries and malicious processes, you may be blind until the first workstation reboot shows a ransom wallpaper. The immediate priorities are protecting privileged credentials, hardening GPO controls and collecting the directory‑level telemetry that will reveal this attack class.
https://securelist.com/tr/payload-ransomware-via-group-policy/121335/
