The PAYLOAD ransomware GPO incident shows that ransomware-style disruption does not always require encrypting Windows files. Kaspersky says attackers with domain-admin-equivalent access at a Middle East manufacturing organization created malicious domain-root Active Directory Group Policy Objects that changed endpoint behavior, disabled defenses, restricted local administration and displayed ransom messaging across Windows systems.
What happened in the PAYLOAD ransomware GPO attack?
Kaspersky says the attackers obtained high-level Active Directory control and created two malicious Group Policy Objects. One GPO, named PAYLOAD, distributed ransom messaging and changed endpoint policy. A second GPO, named win Firewall Off, disabled Windows Firewall across domain, private and public profiles.
Kaspersky found no Windows file encryption and no resident Windows ransomware binary on the examined endpoints. The operation still involved data theft and extortion, and Kaspersky separately identified a PAYLOAD ransomware sample targeting ESXi on Linux servers.
Did PAYLOAD encrypt Windows files?
No Windows file encryption was observed in this incident. Kaspersky’s forensic examination found that the disruptive Windows behavior came from Group Policy changes rather than a conventional encryptor running on each workstation.
That does not mean PAYLOAD has no encryption capability. Kaspersky separately recovered a PAYLOAD ransomware sample designed for ESXi on Linux servers. The safest distinction is therefore between the observed Windows endpoint impact in this incident and the broader PAYLOAD ransomware family’s capabilities.
Was a Windows ransomware executable deployed?
Kaspersky says it did not find a resident Windows ransomware executable responsible for the endpoint disruption. The harmful configuration was instead propagated through Active Directory Group Policy, a legitimate enterprise administration mechanism.
This matters operationally because defenders focusing only on endpoint malware processes may miss the controlling malicious state if it remains linked at the domain level.
What did the PAYLOAD GPO change?
Kaspersky says the malicious PAYLOAD GPO changed several user-facing and administrative settings across affected Windows systems. The observed actions included:
- copying ransom-note content to endpoints;
- changing desktop wallpaper;
- changing the lock-screen image;
- configuring a ransom-related Windows logon notice;
- disabling the built-in local Administrator account.
These were policy-driven changes. TPS found no evidence in the completed research that the attackers exploited a vulnerability in Group Policy itself.
What did the win Firewall Off GPO do?
Kaspersky also identified a separate malicious GPO named win Firewall Off. It disabled Windows Firewall across domain, private and public network profiles.
That change reduced endpoint defenses using the organization’s own centralized policy mechanism. It should be treated separately from the PAYLOAD GPO because the two policy objects served different operational purposes.
Did PAYLOAD exploit an Active Directory or Group Policy vulnerability?
No Microsoft or Group Policy vulnerability was established in the incident report. The attackers abused legitimate administrative functionality after obtaining domain-admin-equivalent control.
The key security failure was therefore privileged identity compromise and control-plane abuse, not a demonstrated Active Directory zero-day.
How did the attackers initially enter the network?
Kaspersky says a valid compromised domain account was used through the organization’s FortiGate SSL VPN. That establishes the access path into the environment, but not how the credential was originally stolen.
Because sufficient historical VPN logging was unavailable, Kaspersky could not reconstruct the original credential-compromise method.
Was phishing the initial access method?
Phishing was not confirmed. Researchers discussed several possible credential-theft routes, including phishing, password spraying, credential stuffing or access obtained through an initial-access broker, but the completed evidence does not identify one of those possibilities as fact.
Was data stolen as well as systems disrupted?
Yes. Kaspersky observed data exfiltration from file servers and other systems and says stolen material was later published for extortion.
The incident is therefore better described as a combined operational disruption and data-extortion attack than as conventional endpoint encryption alone.
Why can a GPO-based attack be hard to spot on endpoints?
Group Policy is designed to distribute trusted configuration across a Windows domain. Once attackers control the administrative plane, policy changes can be applied using normal domain mechanisms without requiring a separate ransomware process on every endpoint.
An affected workstation can therefore look heavily disrupted while traditional malware triage finds no encryptor process responsible for the visible behavior. The malicious state may still be present at the Active Directory and SYSVOL layers.
What should Active Directory teams inspect first?
Inspect newly created or modified GPOs
Review unexpected policy objects, especially objects linked at the domain root or other broad scopes. Compare creation and modification times with known administrative activity.
Check domain-root policy links
Verify gPLink and related directory changes so a malicious policy cannot continue propagating after endpoint cleanup.
Monitor SYSVOL integrity
Look for unexpected policy files, scripts, images, registry policy files and security-template changes that cannot be explained by legitimate administration.
Review directory-service auditing
Kaspersky highlights visibility around GPO creation, modification and deletion, including Events 5137, 5136 and 5141 where appropriate auditing is enabled.
Review privileged accounts and VPN access
Investigate domain-admin usage, privileged authentication, remote-access sessions and compromised valid accounts. Use phishing-resistant MFA where supported.
Restore the trusted policy source first
Remove malicious policy links and restore trusted domain configuration before treating endpoint reimaging as complete remediation.
Which Active Directory events matter?
Kaspersky’s defensive guidance highlights Active Directory auditing around Group Policy creation, modification and deletion. Relevant visibility can include:
- Event 5137 for directory object creation;
- Event 5136 for directory object modification;
- Event 5141 for directory object deletion.
These events are useful only when the required auditing is correctly enabled and retained. Their absence by itself is not proof that an attacker bypassed the directory layer.
What SYSVOL changes should raise concern?
Administrators should investigate unexpected Group Policy files, scripts, images, registry policy files and security-template changes that do not match authorized configuration work.
Kaspersky’s report makes SYSVOL monitoring important because GPO content is not represented only by directory metadata. Defenders need visibility into both the directory objects and the policy files those objects reference.
Does a missing Event 5136 prove direct SYSVOL tampering?
No. Missing expected directory-change telemetry can be suspicious, but it can also result from incomplete or misconfigured auditing. TPS should not treat the absence of one Event ID as proof of a particular attack path.
The safer approach is to correlate directory events, SYSVOL file changes, privileged logons and known administrative activity.
Should incident responders reimage endpoints first?
Endpoint recovery should not be the first and only containment action when malicious Group Policy remains active. If the domain controller continues distributing a hostile policy, freshly restored endpoints can simply receive the same configuration again.
The recovery sequence should therefore begin by containing privileged access, identifying and disabling malicious GPO links, restoring trusted policy state and verifying SYSVOL integrity before considering endpoint cleanup complete.
What account controls matter after this incident?
The initial access involved a valid compromised domain account used through SSL VPN, while the destructive policy stage required far greater Active Directory privilege. Organizations should therefore review both remote-access controls and privileged-domain administration.
Useful controls include phishing-resistant MFA for remote and privileged access where supported, tight domain-admin membership, separate administrative accounts, privileged-access monitoring and sufficient VPN/authentication log retention for later incident reconstruction.
Was the attack limited to Group Policy?
No. Group Policy was the Windows disruption mechanism described in the incident, but Kaspersky also observed data exfiltration and identified a PAYLOAD ransomware sample targeting ESXi on Linux servers.
That means the full event should not be reduced to a GPO prank or configuration-only incident. It was an extortion operation with both data-theft and ransomware-family components.
Is PAYLOAD attacking Windows domains globally now?
The reviewed evidence documents one Middle East manufacturing incident and PAYLOAD family behavior. It does not establish a mass ongoing global campaign using this exact malicious-GPO chain.
Additional victims or repeated use of the same technique would materially change the current risk picture and should update this same canonical.
PAYLOAD ransomware GPO attack: confirmed versus unresolved
| Question | Current evidence state |
|---|---|
| Were malicious domain-root GPOs created? | Confirmed by Kaspersky |
| Were Windows files encrypted? | No encryption observed |
| Was a resident Windows ransomware binary found? | No |
| Was Windows Firewall disabled through policy? | Yes |
| Was the built-in local Administrator disabled? | Yes |
| Was data stolen? | Yes |
| Did PAYLOAD have an ESXi ransomware sample? | Yes |
| Was a Group Policy vulnerability exploited? | Not established |
| Was phishing confirmed as initial access? | No |
| Is a mass global GPO campaign confirmed? | No |
PAYLOAD ransomware GPO: direct answers
Did PAYLOAD encrypt Windows endpoints?
No Windows file encryption was observed in the documented incident.
Does PAYLOAD have encryption capability?
Yes. Kaspersky identified a separate PAYLOAD ransomware sample targeting ESXi on Linux servers, so the Windows no-encryption finding must not be generalized to the entire family.
Was Active Directory vulnerable?
No AD or Group Policy vulnerability was identified. Attackers abused legitimate capabilities after obtaining sufficient privilege.
Can endpoint cleanup alone fix a malicious-GPO incident?
Not safely while the malicious policy source remains active. Domain-level policy and SYSVOL integrity must be restored first.
Was the victim compromised through a FortiGate vulnerability?
The reviewed evidence says a valid compromised account was used through FortiGate SSL VPN. It does not establish exploitation of a FortiGate vulnerability.
Verification method
ThePulseSignal reviewed Kaspersky’s primary incident-response report and company summary, then reconciled the GPO behavior, Windows no-encryption finding, ESXi ransomware distinction, VPN access path and current corroborating technical coverage.
Limitations
The original credential-theft method, attacker identity, broader victim count, exact ESXi operational impact and prevalence of this GPO technique remain unresolved. Some PAYLOAD family capabilities reported by researchers were not proven to have executed in this specific incident.