Ransomware
PAYLOAD ransomware used Group Policy instead of an encryptor
PAYLOAD crippled a manufacturer's Windows domain with two rogue GPOs and no malware on endpoints. How it worked, the events to watch and what to lock down.
On September 21, Kaspersky's Global Emergency Response Team (GERT) published its investigation of an April 2026 attack by the PAYLOAD ransomware group on a manufacturer in the Middle East. The attackers disrupted every domain-joined Windows workstation without running ransomware on any of them. They wrote two Group Policy Objects (GPOs) in Active Directory, linked them at the top of the domain and let Windows deliver the damage for them.
Kaspersky found no encrypted files on Windows machines, no malicious binaries on disk and no persistence on endpoints. Data was still stolen from the file servers and later published on a dark web leak site. If your security tooling is built to catch a ransomware executable, it would have seen nothing here until the first workstation rebooted, so any organisation running Active Directory should check who can create and link GPOs.
How it works
A GPO is a bundle of settings that Active Directory hands to Windows machines. It has two halves: a groupPolicyContainer object in the directory, and a folder of files in SYSVOL, the share every domain controller replicates and every client reads. A GPO does nothing until it is linked to a site, domain or organisational unit (OU). The link is stored in the gPLink attribute of that container, and a link on the domain object itself applies to every computer and user in the domain.
The attackers built the PAYLOAD GPO and linked it at the domain root on April 13. They staged two files next to it in SYSVOL, payload.jpg and hello.txt. The GPO then used standard policy features:
- Group Policy Preferences Files copied hello.txt to the desktop and to the roots of C: and D: as a read-only README-payload.txt ransom note.
- The legalnoticecaption and legalnoticetext registry values set a logon banner reading "Welcome to Payload!" followed by the ransom demand.
- Desktop and lock screen policies pointed the wallpaper and lock screen at payload.jpg on the domain controller's SYSVOL share.
- Security settings disabled the built-in local Administrator account, which removes an easy way back into a machine that is off the domain.
- Loopback processing made the user settings, such as the wallpaper, apply whatever account signed in.
A second GPO, "win Firewall Off", turned off Windows Firewall on the domain, private and public profiles.
Nothing happened on screens for about a day. Kaspersky says the policy was cached on endpoints on April 13, but the computer settings in these GPOs only take effect at a restart or a policy refresh, and no endpoint had rebooted in the meantime. When machines restarted on April 14, the wallpaper, banner and notes appeared across the company at once. Windows clients normally refresh policy in the background every 90 minutes, plus a random offset of up to 30 minutes, which is why a quiet gap like this is easy to miss.
What attackers did
Initial access came on April 11 through the company's FortiGate SSL VPN, using a valid domain account whose credentials had been compromised. Kaspersky could not say how the credentials were obtained: phishing, password spraying, credential stuffing and purchase from an initial access broker are all possible. By April 13 the actor held domain admin rights or an equivalent delegation. Kaspersky notes that membership of Group Policy Creator Owners plus link rights on the domain object would have been enough.
On April 13, the same day the GPOs were created, data began leaving the network from the file servers and several other systems. Kaspersky was engaged on April 15. It also recovered two process-killer tools, killer.exe and kill.exe, and a PAYLOAD ransomware sample built for ESXi hosts, but found no evidence that Windows files were encrypted. The damage on Windows came entirely from the two GPOs, the stolen data and the threat of the leak.
Everything the attackers used is a trusted admin feature. Endpoint products mostly inspect files, scripts and processes, and a GPO applied by the Group Policy client looks like ordinary administration.
What to do
Turn on directory change auditing. Enable the Advanced Audit Policy subcategory Audit Directory Service Changes (Success) on domain controllers, and add auditing entries (SACLs) on the domain object and on the Policies container under CN=System. Without the SACL entries the events are not written. The events to collect are:
- 5137, a directory object was created. A new groupPolicyContainer shows who created the GPO.
- 5136, a directory object was modified. Alert on any change to gPLink on the domain root and on your top-level OUs.
- 5141, a directory object was deleted, which shows attackers tidying up or a responder removing GPOs.
- 1102, the Security log was cleared.
Decide who may link at the domain root. Kaspersky recommends separating the right to create GPOs from the right to link them, and giving both only to a dedicated, audited admin role. In practice, review the members of Domain Admins, Enterprise Admins and Group Policy Creator Owners, and the delegation on the domain object (Group Policy Management Console, select the domain, Delegation tab, "Link GPOs"). Keep domain-wide policies few and named in a list your SIEM can compare against.
Tier your admin accounts. Domain admin credentials should only be used on domain controllers and dedicated admin workstations, never on a VPN session from an ordinary laptop. Kaspersky also advises phishing-resistant multi-factor authentication (MFA) on the VPN, Windows LAPS (Local Administrator Password Solution) for unique local admin passwords and Credential Guard to protect credentials in memory.
Watch SYSVOL for writes. Apply file integrity monitoring or object access auditing to \\<domain>\SYSVOL\<domain>\Policies. Images, text files or scripts appearing there outside a change window deserve a look.
Back up your GPOs. Run Backup-GPO -All -Path <folder> on a schedule and keep the output off the domain. A backup lets you compare the current state with a known-good one and restore quickly if an attacker edits an existing policy instead of creating a new one.
If you think you were hit, check endpoints for README-payload.txt, a wallpaper or lock screen that points at SYSVOL, and entries under HKLM\Software\Microsoft\Windows\CurrentVersion\Group Policy\History that name a GPO you do not recognise. Remove the malicious GPOs and SYSVOL files on the domain controllers first, rotate every credential the attacker may have held, then run gpupdate /force so clients pick up clean policy. Kaspersky's report lists the two GPO GUIDs, the tool hashes and exfiltration IP addresses to search for.
Tier zero includes Group Policy
Many teams protect domain controllers as tier zero and then leave GPO editing with a broad helpdesk or server team. Anyone who can link a GPO at the domain root can change every workstation in the company within one policy refresh or reboot. Treat that right the way you treat Domain Admins, and alert on its use.
We review GPO delegation, audit policy and admin tiering as part of safeguarding and hardening, and our security operations team can alert on gPLink changes and SYSVOL writes. Open the chat and Yaali, our AI agent, will pass your question to an engineer.
Sources: Kaspersky Securelist, Cybersecurity News, CyberInsider, IT-Connect, SC Media, Microsoft Learn: Group Policy processing, Microsoft Learn: event 5136.