PAYLOAD ransomware hit a whole Windows domain through two Group Policy objects and no endpoint malware

Three days, two policy objects, no malware on any Windows machine

Kaspersky's reconstructed timeline puts three days between the first VPN logon (11 April 2026) and domain-wide disruption at a Middle East manufacturer (14 April). The attacker's entire Windows toolkit was two Group Policy Objects, both linked at the domain root. One of them, named PAYLOAD, carried six settings. Kaspersky's Global Emergency Response Team (GERT) found no encrypted files on Windows machines, no malicious binaries on disk, no endpoint persistence and no malicious processes. The account is in its Securelist report, published on 21 September 2026.

The desktops still ended up displaying a ransom wallpaper, a ransom lock screen, a logon banner reading "Welcome to Payload!" and a read-only ransom note on the desktop and on C:\ and D:\. The built-in local Administrator account was disabled and Windows Firewall was turned off on all three profiles. Data had already been taken from the file servers and was later published on the group's leak site.

The lesson for UK Windows estates is not about this particular malware family. The attacker never needed to move from machine to machine. One authorised-looking write to Active Directory was enough, and Windows' own management plane carried it to every domain-joined computer. The rest of this briefing sets out what is on the record, tests the idea that "trusted management tooling" is a safeguard, and turns Microsoft's own documentation into a detection and hardening order.

Who PAYLOAD is

Kaspersky's report is about the technique and says little about the group. The best public technical account of the malware is a full reverse-engineering write-up by the independent researcher site Derp.ca, last updated 25 July 2026. Its main findings:

• First seen: active "since at least February 17, 2026". The Windows binary's compile timestamp is 2026-02-17 08:39:07 UTC, and the first leak-site victim appeared within hours.
• Lineage: a derivative of the Babuk source code that leaked in September 2021. The HC-128 cipher was swapped for ChaCha20, with Curve25519 used for key exchange. Derp.ca found no weakness in the cryptography. Without the operator's private key, files cannot be recovered.
• Variants: a Windows PE and a Linux ELF aimed at ESXi. Encrypted files get the extension .payload. The Windows mutex is MakeAmericaGreatAgain.
• Model: double extortion, run through a Tor negotiation portal and a separate Tor leak blog. Derp.ca treats the "ransomware-as-a-service" label seen in some coverage as unverified, because no public source shows an affiliate programme.

PAYLOAD at a glance: what each source establishes and what it does not (sources fetched 21 September 2026)

Source	What it establishes	What it does not establish
Kaspersky GERT, Securelist	One April 2026 intrusion at a Middle East manufacturer, carried out through two domain-root GPOs; ESXi variant found on Linux servers	How the group operates generally; victim name; how data was exfiltrated
Derp.ca reverse engineering	Babuk lineage, cryptography, anti-forensics, kill lists, first seen 17 February 2026	Who runs it, or any affiliate structure (treated as unverified)
ransomware.live leak-site tracker	Leak-site claims: 74 in its API, 36 countries, 17 February to 20 August 2026	That any claim is true, or that any listed organisation was actually breached

On UK exposure. Kaspersky's victim was not in the UK. The ransomware.live API, queried on 21 September 2026, listed two claims with a GB country code, dated 14 March and 25 March 2026. These are the criminals' own leak-site posts as scraped by a tracker. They have not been verified, and this briefing does not name the organisations. The honest summary is that the UK has appeared on PAYLOAD's leak site, but nothing public ties a UK organisation to the Group Policy technique described here.

How the attacker got in and got domain rights

Entry was a valid domain account used to log on to the organisation's FortiGate SSL VPN (MITRE ATT&CK T1078 and T1133). Logging on the appliance was too thin to show how the credential had been obtained. Kaspersky lists three possibilities with equal weight: password spraying or credential stuffing, phishing, or buying access from an initial access broker.

Everything between the VPN session and the GPO write is unknown. Kaspersky reasons backwards from what happened: because the account could create a GPO and link it at the domain root, it had either domain admin privileges "or a delegated equivalent". Its example is membership of Group Policy Creator Owners combined with link rights on the domain object. The usual routes to that level, DCSync, Kerberoasting of privileged service accounts and pass-the-hash or pass-the-ticket, "could not be confirmed or ruled out".

Exactly how Group Policy was used

A GPO has two halves. The Group Policy Container is an object in Active Directory. The Group Policy Template is a folder in SYSVOL. The link decides where it applies, and a link at the domain root covers every computer and user object beneath it. Kaspersky reconstructed PAYLOAD's contents from a Resultant Set of Policy (RSOP) analysis on affected workstations.

The six PAYLOAD GPO settings, as reconstructed by Kaspersky GERT from RSOP (Securelist, 21 September 2026)

Client-side extension	Setting	Effect on every endpoint
Files (Group Policy Preference)	SYSVOL\hello.txt copied to Desktop, C:\ and D:\	Ransom note dropped as read-only README-payload.txt
Registry (Computer)	legalnoticecaption	Logon banner title: "Welcome to Payload!"
Registry (Computer)	legalnoticetext	Logon banner body: the ransom demand
Personalization policy	Lock screen image	payload.jpg from the DC's SYSVOL
Desktop policy (User)	Wallpaper path	payload.jpg from the DC's SYSVOL
Security Settings (GptTmpl.inf)	Accounts: Administrator account status	Built-in local Administrator disabled

The second GPO, win Firewall Off, was also linked at the domain root. It turned Windows Firewall off on the domain, private and public profiles (T1562.004). Kaspersky reads this as clearing the way for any follow-on network access. The registry history on workstations includes a Loopback-GPO-List entry, which means the policy was processed in loopback mode. The user-side wallpaper setting therefore applied to whoever logged on, not only to users in a particular OU.

The two files were written to the root of the domain's SYSVOL share (\\DC.THECOMPANY.local\sysvol\THECOMPANY.local\) and handed out through the Files preference. THECOMPANY is Kaspersky's anonymised placeholder.

Common GPO ransomware techniques against what this incident used (Kaspersky's reconstruction)

Technique	Used here?	What the record says
Scheduled tasks pushed by GPO (ScheduledTasks.xml)	No	No malicious tasks found; Kaspersky cites LockBit and BlackCat affiliates for this method, not PAYLOAD
Startup or logon scripts	Not in reconstruction	The RSOP settings list contains none; Kaspersky calls the two GPOs "the entire offensive toolkit"
File copy from SYSVOL	Yes	Files preference copied hello.txt from the SYSVOL root
File copy from NETLOGON	Not stated	Only SYSVOL paths appear in the report
Encryptor launched by GPO	No	No .payload files and no encryption I/O on Windows
Security tools disabled	Firewall only	Firewall off by GPO; killer.exe and kill.exe listed as indicators without saying where they ran

The one-day fuse, and what Microsoft's documentation adds

Kaspersky treats the gap between writing the GPO on 13 April and the visible impact on 14 April as the most instructive detail in the case. MFT timestamps and the Group Policy History key show the policy was in SYSVOL and cached on endpoints on 13 April. Kaspersky says the computer-side settings "only apply upon reboot or policy refresh". Because no endpoint had restarted, the attack sat dormant until the machines were rebooted as normal the next day.

Microsoft's documentation makes that picture more complicated. Its Group Policy processing page says computers refresh policy in the background every 90 minutes, plus a random offset of up to 30 minutes. Its page for the logon message title setting says changes take effect "without a device restart" when distributed through Group Policy. Some extensions, such as software installation and folder redirection, only run at startup or logon.

Encryption and exfiltration: observed or family capability

There was no encryption on Windows. The only ransomware binary Kaspersky reports finding was a PAYLOAD sample targeting ESXi on the victim's Linux servers. The report does not say whether it ran. Separately, data exfiltration "was observed originating from the file servers and several additional systems" on 13 April, and the data was later published on the dark web. Channel, tooling, volume and destination are not given. The indicators list includes twelve IP addresses and two process-killer tools, killer.exe and kill.exe, with MD5 hashes, but the report does not say which host each indicator came from.

Kaspersky is careful to separate what happened in this incident from what the PAYLOAD Windows encryptor is known to be able to do from public reverse engineering. That separation is worth keeping.

PAYLOAD capabilities: family level versus observed in this incident (Kaspersky, cross-checked with Derp.ca)

Capability	Family level (public reverse engineering)	Observed in this incident
File encryption, .payload extension	Yes: Curve25519 and ChaCha20	No on Windows; ESXi sample present, execution not stated
Event log clearing (wevtapi, EvtClearLog)	Yes, optional switch	Not stated
Security and backup service termination	Yes, kill lists	Process-killer tools in indicators; execution not described
Volume Shadow Copy deletion	Yes, before encryption	Not established
ETW patching in process	Yes per Derp.ca; Kaspersky lists it as ecosystem-relevant	Not encountered
BYOVD (vulnerable signed driver)	Not established as a PAYLOAD feature	No
ESXi policy weakening (SSH, execInstalledOnly)	Common in the ecosystem	No evidence

Kaspersky offers two explanations, "with moderate confidence", for why Windows machines were not encrypted. Either the attacker deliberately stayed short of irreversible damage and kept the option to encrypt later, or the operation was interrupted. The report does not choose between them. It is also worth being clear about what "no encryption" means for recovery. The domain was still compromised at domain admin level, and data had already been stolen and published.

"Trusted management tooling" is a description, not a control

Kaspersky calls Group Policy "a signed, allowlisted, SYSTEM-privileged distribution channel". Two of those three words are doing work that should be tested.

What Windows actually checks. Since MS15-011 in 2015, Microsoft has recommended hardened UNC paths for \\*\SYSVOL and \\*\NETLOGON. These require mutual authentication and integrity so that clients are protected against "spoofing and tampering attacks". That confirms the policy came from a real domain controller and was not altered in transit. It does not, and cannot, check whether the person who wrote the policy meant well. Nothing in the client asks whether it is sensible to disable the local Administrator on every machine. In this setting "trusted" means authenticated source, not vetted content.

Why that makes the attack efficient. Once someone holds GPO write and link rights at the domain root, lateral movement is no longer a phase of the attack. There is nothing to spread and no hosts to hop between. Every domain-joined client pulls the change itself, runs it as SYSTEM, and applies it again at every refresh. That also means cleaning endpoints achieves nothing while the GPO still exists, which is why Kaspersky's remediation starts on the domain controller.

The claim about EDR blindness. Kaspersky says most EDR tools are "designed not to inspect" Group Policy. The report offers no data to back that up, so treat it as the vendor's assertion. The narrower claim is well supported: there was no binary or process for a file-based or process-based detector to find.

Detection, from Microsoft's documentation

The events that matter are generated on domain controllers by the Audit Directory Service Changes subcategory. Microsoft documents three limits that decide whether you will see anything:

1. The subcategory "only logs events on domain controllers".
2. Events are generated only for objects with a SACL that matches the access. Enabling the audit policy without the SACLs produces nothing.
3. Event volume is "High on domain controllers", so filter by object class and attribute rather than collecting everything.

Directory and SYSVOL audit events for GPO abuse (Microsoft Learn event reference)

Event	Microsoft's meaning	What to watch, per Microsoft and Kaspersky
5137	A directory service object was created	Class groupPolicyContainer: Microsoft recommends monitoring "all new group policy objects creations"
5136	A directory service object was modified	Attribute gPLink on class domainDNS (the domain root) or on sensitive OUs; also gPCMachineExtensionNames, gPCUserExtensionNames, gPCFileSysPath, versionNumber
5141	A directory service object was deleted	Class groupPolicyContainer: Microsoft recommends monitoring GPO deletions
4663	An attempt was made to access an object	Writes under SYSVOL Policies and the SYSVOL root; needs Audit File System plus a SACL, since default SACLs produce none

Microsoft notes that a single change typically produces two 5136 events, "Value Deleted" followed by "Value Added". It advises watching the Value Added event and using the shared correlation ID to recover the previous value. For gPLink this means one pair shows exactly which GPO was linked where, and who did it (SubjectUserName). The filters below are XPath queries for Event Viewer or a Windows Event Forwarding subscription on domain controllers. They are for detection only.

Security log, domain controllers only

GPO created:
*[System[(EventID=5137)]] and *[EventData[Data[@Name='ObjectClass']='groupPolicyContainer']]

Any GPO link changed (review every hit at the domain root and Tier 0 OUs):
*[System[(EventID=5136)]] and *[EventData[Data[@Name='AttributeLDAPDisplayName']='gPLink']]

GPO deleted:
*[System[(EventID=5141)]] and *[EventData[Data[@Name='ObjectClass']='groupPolicyContainer']]

Kaspersky adds two heuristics worth adopting. First, if a GPO's SYSVOL content changes without a matching 5136, someone may have edited the template directly, bypassing the Group Policy Management Console. Misconfigured auditing produces the same gap, though, so check your SACLs before treating it as an attack. Second, on endpoints, a sudden domain-wide change in applied policy shows up in the Microsoft-Windows-GroupPolicy/Operational log. That is useful after the fact, but by then the policy has already been delivered. Kaspersky also suggests a canary GPO whose application anywhere would signal that an attacker has GPO write access.

Tiering and backups the domain cannot reach

Tiering. Kaspersky recommends the AD tiered administration model, with domain admins confined to Tier 0 and never logging on interactively to workstations or member servers. Microsoft has since folded the tier model into its enterprise access model, where Tier 0 becomes the control plane, and has retired the ESAE "red forest" as a default recommendation. Its retirement notice still says to "Use a tiered approach implementing least-privilege administrative model". The PAYLOAD case adds one concrete test: list every principal that can create GPOs or write gPLink on the domain root and Tier 0 OUs, including delegated groups such as Group Policy Creator Owners, and treat each one as a domain admin.

Backups. Microsoft's ransomware backup guidance says it is "critical to have backups that a malicious attacker can't access". It recommends multiple copies in "isolated, offline (air-gapped) locations", offline or immutable storage, and out-of-band steps such as MFA or a security PIN before an online backup can be changed or deleted. The Group Policy lesson follows from that (our inference): a backup server joined to the production domain receives the same domain-root GPOs as every other machine. A firewall-off GPO, or a later encryptor push, would reach it too. A backup system managed by domain accounts is only as isolated as the least-protected GPO editor.

Method, and Kaspersky's interest

The report is incident-response work by Kaspersky's GERT, with a clearly reasoned evidence chain: RSOP, MFT timestamps, registry history and the IOC list. It is careful to separate what it saw from what it infers, and incident-level findings from family-level ones. It is also a sales document in part. It promotes a paid Kaspersky SIEM correlation-rule package for this attack, Kaspersky EDR Expert rules for GPO creation, change and deletion, and a new GPO event type due in the next major EDR release. None of that affects the underlying detections. Events 5136, 5137 and 5141, SYSVOL SACLs and Group Policy Operational logs are Windows features any SIEM can collect, and this briefing's guidance relies only on Microsoft's documentation of them.

What to do, in order

The question that exposes the gap

Every Windows estate gives Group Policy the power to change every machine at once. That is what it is for. The question is not whether your EDR would catch a ransomware binary. It is this: if a GPO were linked at your domain root at two in the morning by an account you do not recognise, which system would tell you, and would it tell you before the next 90-minute refresh? If the answer depends on a SACL nobody has checked since the domain was built, the PAYLOAD case describes your estate.

Key facts