In April 2026, Kaspersky’s Global Emergency Response Team investigated a manufacturing organisation in the Middle East that had been taken down without a Windows encryptor.
The actor did not need one. They authenticated to the FortiGate SSL VPN with a valid domain credential, reached domain-admin-equivalent control, and turned Group Policy into the delivery system. The impact lived inside Active Directory. Endpoint malware scanners looking for a ransomware binary would have had nothing to hash.
This is a technical reading of that vector: how you get from a VPN logon to domain-wide disruption, why GPO is the wrong thing to treat as “just IT configuration,” and what public reporting agrees on.
What the public record actually says
Kaspersky published the incident on 21 September 2026 (Securelist; press release). Independent write-ups (Cybersecurity News, CyPro, IT-Connect) recap the same facts. They do not add a new initial-access proof. Treat press-cycle language (“likely phishing”) as weaker than the IR report.
The IR facts that matter for the vector:
- Initial access: valid but compromised domain account on FortiGate SSL VPN (MITRE T1078, T1133).
- Privilege: the account could create and link a GPO at the domain root—domain admin, or a delegated equivalent (Group Policy Creator Owners plus link rights on the domain object).
- Windows impact: no
.payloadfiles, no resident encryptor, no endpoint persistence. Visual lockout, ransom notes, local Administrator disabled, firewall off. - Linux/ESXi: a PAYLOAD ESXi sample was recovered. Data left file servers and other systems and later appeared on the dark web.
Encryptionless Windows disruption plus theft is the 2026 shape. The cryptographic family still exists. It was not what detonated on the workstations.
The front door was not a CVE
Insufficient FortiGate logging blocked reconstruction of how the credential was stolen. Kaspersky listed three hypotheses, in no order:
- Password spraying or stuffing against the SSL VPN portal.
- Phishing-led credential harvesting.
- Purchase from an initial access broker.
None of those is “breaking FortiGate.” The product was used as designed: an external remote service that accepts a domain principal. If that principal is privileged, or can become privileged, VPN MFA that is not phishing-resistant is the whole perimeter.
The gap after VPN is equally important. FortiGate auth logs and ESXi/virtualisation privilege-escalation logs were too thin to reconstruct the hop from “inside the network” to “can write gPLink at the domain root.” DCSync, Kerberoasting of privileged service accounts, and Pass-the-Hash / Pass-the-Ticket are the usual routes. They were neither confirmed nor ruled out. That is a logging failure, not a mystery of tradecraft.
Why Group Policy is the payload channel
A GPO is two things glued together:
- Group Policy Container (GPC) in Active Directory—the object, the GUID, the attributes (
gPCFileSysPath,gPCMachineExtensionNames,gPCUserExtensionNames,versionNumber). - Group Policy Template (GPT) in SYSVOL—the files endpoints actually apply:
Registry.pol,GptTmpl.inf, Group Policy Preferences XML, images, text.
Scope is the link. Site, domain, or OU. A link at the domain root applies to every computer and user object beneath it, unless a later block or filter says otherwise. That is not a malware C2. It is a signed, replicated, SYSTEM-privileged distribution channel that most EDR is built not to treat as hostile.
Kaspersky has written the architecture before. Other families have already used it as a launcher: Microsoft documented Ryuk distributing ransomware through Group Policy, SYSVOL startup items and PsExec; LockBit affiliates have been seen editing SYSVOL including ScheduledTasks.xml; BlackCat/ALPHV used GPOs to create scheduled tasks and deploy encryptors. PAYLOAD’s novelty in this case is the opposite: GPO Preferences and policy settings were the impact. No encryptor on Windows. The trusted channel did the defacement, the lockout, and the defence impairment.
If your detection strategy is “catch the ransomware executable,” you have defined the attack out of existence until the first reboot paints the wallpaper.
What “valid account” actually bought
Once on the network, the actor operated as the compromised principal. Creating {C897F2C7-C2AC-4E6F-BF48-58036FF29E79} (PAYLOAD) and {22099AD2-E062-4F56-B574-5099BBA4E7A6} (win Firewall Off), linking both at the domain root, and writing payload.jpg / hello.txt into SYSVOL is not a workstation exploit. It is directory write access plus SYSVOL write access.
That is Tier 0. Domain admins should not log on to workstations. GPO create rights should not be the same principal as GPO link rights. VPN should not mint an interactive path to either. None of those controls require knowing PAYLOAD’s name. They are what “the attack vector was Group Policy” actually means: the vector was privileged, trusted configuration, reached through valid remote access.
Hunting GPO ACL drift, unexpected gPLink changes, and non-replication writes under \\<dc>\SYSVOL\<domain>\Policies\ is the vector-side detection. Microsoft-oriented AD guidance has been saying this independently of this incident: correlate 5137 (new groupPolicyContainer) with 5136 on gPLink, and treat SYSVOL script/preference writes from non-replication sources as hostile until proven otherwise (Windows Active Directory).
What the vector is not
It is not a zero-day in Group Policy. It is not “ransomware that encrypts GPO.” It is not proof that every PAYLOAD job skips encryption—the ESXi sample in the same environment says otherwise.
It is a demonstration that identity plus GPO write is enough to produce ransomware outcomes (ransom notes, lockout, operational stop, leaked data) while leaving file- and process-based stacks looking healthy.
If you cannot answer “who can create or link a GPO at the domain root, from which jump host, after which MFA,” you have not modelled this vector. You have modelled last year’s encryptor.
Relevant Sources
- Group Policy hijacked: PAYLOAD ransomware weaponizes Active Directory GPO — Kaspersky GERT, Securelist (21 Sep 2026) — https://securelist.com/tr/payload-ransomware-via-group-policy/121335/
- Kaspersky uncovers new ‘Payload’ — Kaspersky press release (21 Sep 2026) — https://www.kaspersky.com/about/press-releases/kaspersky-uncovers-new-payload-the-stealth-ransomware-that-hijacks-corporate-devices-without-encrypting-files
- PAYLOAD Ransomware Hijacks Active Directory GPO — Cybersecurity News — https://cybersecuritynews.com/payload-ransomware-hijacks-active-directory/
- How to detect abuse of GPO permissions — Windows Active Directory — https://www.windows-active-directory.com/how-to-detect-abuse-of-gpo-permissions.html
- Valid Accounts (T1078) / External Remote Services (T1133) / Domain Policy Modification: Group Policy Modification (T1484.001) — MITRE ATT&CK
If your ransomware programme still starts at “the encryptor on the endpoint,” this incident is the reason to start at identity, VPN, and who can write Group Policy. I work with boards and CISOs on that control set. Contact me.