PAYLOAD ransomware turns Active Directory into an attack tool

Ransomware response plans often begin with the assumption that a malicious executable will appear on endpoints, launch an encryption routine and generate a recognizable trail of processes, files and network connections. The PAYLOAD incident analyzed by Kaspersky’s Global Emergency Response Team (GERT) shows why that assumption is incomplete.

In an April 2026 incident affecting a manufacturing organization in the Middle East, the threat actor used compromised access to Active Directory and altered Group Policy Objects (GPOs). The resulting operation changed the configuration and appearance of domain-joined Windows systems without deploying a ransomware binary to those endpoints. Kaspersky reported no Windows file encryption, no resident endpoint malware and no active malicious processes during its forensic examination.

The case is significant not because it introduces a new exploit, but because it demonstrates how a trusted administrative system can become the delivery mechanism for disruption. The attack used Group Policy itself as the persistence and distribution layer, while data exfiltration was observed from file servers and other systems. Kaspersky said the stolen data was later published on the dark web.

This analysis is based on Kaspersky’s Securelist report. Findings confirmed by the researchers are separated below from family-level capabilities and broader ransomware techniques that were not established in this incident.

How the attack reached the domain

Kaspersky reconstructed the initial access stage as a login to the organization’s FortiGate SSL VPN using a valid but compromised domain credential. The report maps this activity to Valid Accounts (MITRE ATT&CK T1078) and External Remote Services (T1133).

The available FortiGate logging was not sufficient to determine how the credential had originally been obtained. Kaspersky considered password spraying or credential stuffing, phishing-led credential theft and the purchase of pre-compromised credentials as plausible possibilities. None was confirmed. The investigators also could not reconstruct or rule out the specific path from VPN access to the privileges needed to create and link a GPO at the domain root.

That privilege level was decisive. The account either held domain administrator rights or an equivalent combination of delegated permissions, such as GPO creation rights together with permission to link policies to the domain object. Once the actor could modify policy at that scope, a single administrative mechanism could affect computers and users throughout the domain.

Group Policy became the ransomware mechanism

A GPO consists of directory information in Active Directory and policy files in SYSVOL. Its reach depends on where it is linked. A domain-root link can apply settings broadly across domain users and computers, making unauthorized changes potentially more consequential than an isolated endpoint compromise.

In this case, Kaspersky identified two malicious GPOs. The first, named PAYLOAD, was created and linked at the domain root. Its identifier was {C897F2C7-C2AC-4E6F-BF48-58036FF29E79}. The second, named win Firewall Off, used identifier {22099AD2-E062-4F56-B574-5099BBA4E7A6} and disabled Windows Firewall across domain endpoints.

The PAYLOAD policy combined several ordinary Group Policy functions:

• It distributed a file from SYSVOL named hello.txt, which appeared on endpoints as README-payload.txt in desktop and root-directory locations.
• It changed the Windows legal-notice caption and text to display the ransom demand.
• It used payload.jpg from SYSVOL as the desktop wallpaper and lock-screen image.
• It disabled the built-in local Administrator account through security policy.

The second GPO weakened host defenses by turning off Windows Firewall for domain, private and public profiles. Kaspersky mapped this behavior to Disable or Modify System Firewall (T1562.004). The operation therefore relied on legitimate policy processing rather than a custom executable or a conventional ransomware launcher.

The delayed impact matters for detection

The policy changes were made on April 13, but visible disruption began largely on April 14, when endpoints rebooted. Kaspersky’s review of MFT timestamps and Group Policy history showed that the policy had already reached SYSVOL and been cached on affected systems. Computer-side settings were not fully applied until reboot or policy refresh.

This delay creates an important investigative distinction. The directory event showing policy creation may precede the user-visible ransom message by many hours. In the reported incident, the gap also provided time for data exfiltration and complicated efforts to connect the administrative change with the later disruption.

For defenders, a quiet endpoint does not demonstrate that a malicious GPO is harmless or inactive. Cached policy content, changes to the domain root and unexpected files in SYSVOL can represent the most valuable evidence before a reboot causes broad impact.

What Kaspersky confirmed—and what it did not

Kaspersky reported that the Windows systems examined had not been encrypted. Investigators found no bulk renaming or encryption patterns and no files with a .payload extension associated with the Windows systems. They also found no malicious scheduled tasks, services, startup entries, WMI event subscriptions or boot-sector changes.

Live analysis did not identify active malicious processes, injected threads, process hollowing or anomalous outbound connections. The effective persistence mechanism was the GPO link on the domain controller: cleaning an endpoint alone would not remove the policy that could be reapplied during a later refresh.

The assessment does not mean the incident was low impact. Local administrator access was disabled, firewall protections were weakened, ransom messaging was distributed and data theft occurred. Kaspersky assessed with moderate confidence that the absence of encryption could reflect either a deliberate encryptionless extortion strategy, preserving the option of later escalation, or an operation interrupted before a full encryption phase. That is an assessment, not a confirmed explanation.

The report also notes that a PAYLOAD Windows cryptomalware family exists and that public analysis of samples has identified capabilities such as event-log clearing, security-process termination and Volume Shadow Copy deletion. Kaspersky did not confirm those behaviors as having executed in the GPO-based Windows incident. Similarly, BYOVD activity, ETW suppression and ESXi policy weakening were discussed as ecosystem-relevant techniques, not as proven components of this attack.

Detection should start in Active Directory

Because the operation did not depend on a file-based payload on Windows endpoints, endpoint malware scanning alone would have been insufficient. Kaspersky recommends prioritizing directory-service, SYSVOL and policy-application telemetry.

Advanced Directory Service Changes auditing can provide visibility into the creation and modification of GPO-related objects. The report highlights Event ID 5137 for object creation, Event ID 5136 for directory-object changes and Event ID 5141 for deletion. Particular attention should be paid to a new GPO, a change to the domain-root gPLink, or modifications to attributes such as gPCMachineExtensionNames, gPCUserExtensionNames, gPCFileSysPath and versionNumber by an account that is not an approved policy administrator.

SYSVOL should be monitored for unexpected image files, text files, scripts, scheduled-task policy files and changes to policy templates such as registry.pol and GptTmpl.inf. A file modification without an expected corresponding directory-service event may indicate direct template editing, although Kaspersky cautions that missing events can also result from incomplete or misconfigured auditing.

Endpoint Group Policy Operational logs and Group Policy History and Shadow registry data can help confirm when a policy was processed. A sudden change in the applied policy set across many machines is a useful post-impact signal, particularly when correlated with a domain-controller change.

Relevant artifacts reported by Kaspersky include payload.jpg, hello.txt, README-payload.txt and the registry value HKLM\...\Policies\System\legalnoticecaption set to Welcome to Payload!. These indicators should be treated as incident-specific clues, not as a complete detection strategy.

What organizations should do now

1. Protect and inspect domain controllers first. If unauthorized GPO activity is suspected, review and remove malicious domain-root-linked policies before cleaning endpoints. Revert the firewall policy, remove unauthorized SYSVOL files and verify that legitimate policy replication is intact.
2. Contain compromised identities. Reset the account used for unauthorized access, review privileged group membership and investigate all accounts capable of creating or linking GPOs. If domain-administrator compromise is confirmed, Kaspersky recommends rotating the krbtgt account twice as part of recovery.
3. Force a clean policy refresh. After the source policies are removed, apply trusted settings to restore firewall protection and the local Administrator account where appropriate. Validate the result on representative systems before broad recovery.
4. Separate GPO creation from GPO linking. Use a dedicated, audited administrative role, adopt tiered administration and restrict domain administrators from interactive use on ordinary workstations and member servers.
5. Improve access controls. Apply phishing-resistant MFA to VPN and other remote-access services, use unique and rotated local administrator credentials, protect credential material with platform controls such as Credential Guard, and administer sensitive systems from Privileged Access Workstations.
6. Centralize the evidence. Forward directory-service, VPN, endpoint and SYSVOL-integrity events to protected central storage. Monitor for domain-root policy changes, unusual policy authors, unexpected SYSVOL writers and broad policy application.
7. Test recovery independently. Confirm that backups, snapshots and recovery accounts cannot be altered by the same administrative path used to control production policy. Review backup and recovery changes alongside GPO events during an investigation.

Conclusion

The PAYLOAD incident illustrates a form of ransomware impact that can evade controls built primarily around executable detection and file encryption. By controlling Active Directory, the actor used a trusted policy channel to distribute ransom messaging, alter endpoint configuration and impair defenses across the domain.

The central lesson is operational: Group Policy and SYSVOL must be monitored as security-sensitive infrastructure, not treated solely as routine administration. Directory-service auditing, strict privilege separation, centralized logging and rapid domain-controller containment can give defenders visibility before a reboot turns a hidden policy change into a domain-wide incident.

Sources

• Securelist: “Group Policy hijacked: PAYLOAD ransomware weaponizes Active Directory GPO”, by Kaspersky Security Services.