Play ransomware ships the encryptor by Group Policy

Play, also tracked as PlayCrypt, is an active double-extortion group. What separates it from the average ransomware intrusion is not how it gets in but how it deploys: it turns Group Policy into a domain-wide delivery system. If you plan your response around isolating infected endpoints, you will lose, because the mechanism pushing the encryptor is a GPO that every domain-joined machine still pulls on its next gpupdate.

How it works

The intrusion follows a familiar arc with a specific ending. Play typically gains initial access through an exposed public-facing service (T1190), plants a remote-access tool for hands-on-keyboard control, then moves to recon and credential theft. For recon they lean on AdFind to enumerate the domain and the Grixba infostealer to profile hosts and, crucially, which security products are installed. Credential dumping from LSASS and the NTDS store (T1003) gets them to Domain Admin.

Then the signature move. With Domain Admin, Play edits a broadly-linked Group Policy Object to add a scheduled task (T1053.005) that stages and runs the encryptor, and to disable endpoint protection fleet-wide (T1562.001). Before detonation they clear the Windows event logs on staging hosts (T1070.001) to blind responders. The encryptor itself uses intermittent, or partial, encryption: it writes only portions of each file. That runs faster and produces an I/O pattern many detection tools were not tuned to catch. The final impact is data encrypted for extortion (T1486) alongside inhibited recovery (T1490), on top of data already staged for the leak-site side of the double extortion.

Why GPO deployment makes it org-wide

A GPO linked to thousands of machines is, to an attacker, a code-execution channel you built and trust. The scheduled task in that policy does not run once on one box. It applies to every computer in scope on that computer’s next policy refresh. This is Group Policy Modification, T1484.001, and it is what turns a single Domain Admin foothold into simultaneous, domain-wide execution at a moment of the attacker’s choosing.

The operational consequence is the part responders get wrong under pressure. The encryptor is not spreading laterally, host to host, in a way you can chase and cut off. It is sitting in SYSVOL, waiting to be pulled. Every domain-joined machine is a subscriber. Isolating the three hosts that lit up first does nothing about the several thousand that will pull the same policy on their next cycle.

How to detect it

Watch Group Policy itself. Audit directory object modifications on GPO objects (Events 5136 and 5137), watch changes to gPCMachineExtensionNames, and alert on new or modified files in SYSVOL. A GPO version number that increments with no change-control record behind it is a strong signal on its own. The lethal combination is a broadly-linked GPO suddenly carrying a scheduled task and a defense-disable, appearing right after fresh Domain Admin activity.

There is a second tell specific to Play: intermittent encryption leaves a distinctive footprint. Files partially rewritten, extensions changed, and unusually fast bulk modification across a share are the pattern to alert on. If you also see the Windows Security log cleared (Event 1102) on hosts that were healthy minutes earlier, treat it as pre-detonation, not housekeeping.

Contain and shut it down

Because deployment rides Group Policy, the decisive containment action is to revert or remove the malicious GPO and block its SYSVOL replication so no machine can pull it, and to do that before the next gpupdate cycle. That is the move that actually denies domain-wide detonation. Isolating individual endpoints does not, because it leaves the policy every other machine still fetches.

Then cut the foothold that created the GPO. Reset the compromised Domain Admin account and rotate krbtgt (twice, allowing replication between rotations) because a Domain Admin compromise means the credential base is exposed regardless of whether encryption ran. Forensics has to lean on the directory side: the attacker cleared local event logs, so reconstruct the GPO edit and its spread from DC-side change auditing (5136/5137, SYSVOL and replication logs) and from centralized EDR telemetry the local wipe could not reach.

Practice it

We built this as a Play scenario in GraphLattice Range so administrators and IR teams can rehearse the one decision that matters here: recognizing the GPO, not the endpoint, as the thing to stop, and reverting it before the next gpupdate pushes the encryptor fleet-wide.