Play

Management summary

Play, also called PlayCrypt, is a ransomware profile that is practically important to defenders by combining valid accounts, misuse of public-facing applications and strong attempts to erase traces. CISA, FBI and ASD ACSC published an updated advisory in which Play-IOC p.a. and TTPs are included based on investigations until early 2025.

For governance, Play is relevant because the attack often starts with known, renowned weaknesses: vulnerable external systems, old edge equipment, Exchange or Fortinet-like exposure, or accounts that can be abused without sufficient MFA or monitoring. This makes Play a good key profile for basic weasurability: patching, identity, logging, EDR, segmentation and recovery.

The advisory mentions that Play binaries can be compiled back by attack, which limits hash detection. This forces organizations to detect behaviour: access, discovery, lateral movement, log removal, data diode and encryption preparation.

Grouping and development

Play is visible as a blackmail group with its own publication and communication patterns. Unlike some RaaS ecosystems, Play is often described as recognizable operation with consistent methods, but also here remains incident evidence. A claim on a leak site is OSINT, not complete technical evidence.

CISA mentions abuse of valid accounts and public-facing applications as important access routes, including known vulnerabilities in FortiOS and Microsoft Exchange in historical context. For Amuneth this means that Play briefings should be directly linked to attack surface: which public systems are vulnerable, which accounts are usable and what logging shows?

The group is relevant to organisations with internet-facing applications, legacy remote access, incomplete patch processes or limited lateral motion detection. Play is less an abstract threat name and more a checklist for visible exposure.

Operation and attack chain

Research starts at edge and identity. Collect firewall, WAF-, VPN-, Exchange-, Fortinet-, proxy-, SSO- and EDR-logs. Check exploit tracks, suspicious requests, successful logins from unusual locations, MFA- status, service accounts, old accounts and use of remote access outside normal pattern.

After access, discovery and lateral movement are decisive. Search for domain enumeration, network scanning, admin share access, remote service creation, PowerShell, WMI, RDP, PsExec-like behaviour, credential access and privilege escalation. Check that the actor moves quickly to file servers, backup servers or domain controllers.

Play research should explicitly look at indicator removal. CISA mentions erasing Windows Event Logs as technique to hide intrusion activity. Check eventlog gaps, log clearing events, EDR telemetry gaps, security service stops and modified audit policy. A lack of logs can be an artifact of the attack, not just a management problem.

Data diode and encryption must be set separately. Search for archives, staging directories, large file entries, cloud uploads, outgoing traffic and ransom notes. Since binaries may be unique per attack, the encryption phase should be reconstructed mainly through behaviour, command lines, process trees and file changes.

Attack pattern from public cases

Play is described by CISA/FBI/ASD ACSC as a ransomware group that uses valid accounts and public-facing applications. Historical context mentions, among other things, abuse of known vulnerabilities in FortiOS and Microsoft Exchange.

After access, Play searches for internal systems, data and management channels. The group is known to focus on indicator removal: delete logs or reduce visibility. Therefore central logging is a defense, not an administrative luxury.

CISA mentions that Play-binaries can be recompiled by attack. As a result, hash detection is limited. The main defense image is behaviour: exploit tracks, valid account abuse, lateral movement, datataging, log removal and encryption.

In ESXi-impact, CISA mentions that ransom notes such as PLAY_Readme.txt can appear in root paths and /vmfs/volumes/. That makes Play relevant to organizations that do not centrally monitor virtualization.

Known IOCs and artifacts

CISA AA23-352A mentions WinSCP as a tool used by Play-actors for data transfer. Plink is mentioned for persistent SSH- tunnels. Both are legitimate tools, but suspicious in combination with night-time staging, new accounts or unknown destinations.

The advisory mentions PLAY_Readme.txt as ransom-note artifact. On ESXi systems, the note may appear in /vmfs/volumes/, for example. Such a find means that the impact phase is already underway; preventive detection should be in the chain sooner.

Play used according to CISA include intermittent encryption with AES-RSA- hybrid encryption. For visitors it is especially relevant that sudden partial file changes, service stops and ransom notes should be viewed together.

CISA also published detection logic around GRIXBA-webhistory scanning. For defense, this is an example that Play preparation via network and SMB- behaviour can be visible before encryption starts.

Victims and historical context

Play is publicly visible at organisations in multiple sectors. For organizations, victim history is especially useful when linked to access patterns: Fortinet, Exchange, VPN, valid accounts, sector and data types. A list of names without technical context does not help researchers enough.

Save per victim claim sector, country, claim date, source, suspected access, data types, publication status and evidence level. Use that history to warn customers with similar exposure targeted.

Detection and follow-up

Priorities: patch public-facing applications quickly, limit external access, enforce MFA, monitor service accounts, protect and centralize logs, detect eventlog clearing, limit admin shares, segment servers, harden EDR and test immutable backups. Make sure logging is kept outside the compromised domain.

In a Play signal, the first response should be source validation, edge scan, identityhunt, log integrity check, data diode research and recovery validation. The group is dangerous when organisations think that missing logs mean little has happened.

Deep forensic file

Play research should begin at the edge of the environment. Public-facing applications, VPN, Exchange, Fortinet-like applications and remote access are the first hypothesis. Record by system whether it was internet-facing during the relevant window, which version was running when patched and which logs are available. Without that exposure line, the cause remains too vague.

Valid account abuse is a second main track. Check that accounts were used from new locations, without normal device, off-work time or immediately after reset. Also check if service accounts interact with login or admin accounts appear on regular workstations. Play-like activity can actually abuse accounts that are technically allowed but show operational strange behaviour.

Log removal makes Play-forensically special. Eventlog clearing, audit policy changes, EDR-telemetry gaps and lost application logs should be investigated as active indicators. A good report not only records what has been found but also where evidence is missing and why. Missing logs can be an attack trail and should not automatically be dismissed as a management error.

Because Play binaries can be unique per attack, detection at hash level is limited. The researcher must reconstruct process behaviour, command lines, remote execution, file modifications, service stops and network activity. This gives a more reliable picture than waiting for a known indicator. Hard IOC pictorials remain useful for scope but behavior determines the defense.

Datastaging should be linked to publication printing. Search for archives, large file entries, unusual directory traversal, cloud uploads and actor communication. If there is no datastall evidence, please report this carefully: no evidence is the same as evidence of absence, especially when logs are erased or kept restricted.

Preventing Play attacks calls for an edge-device security programme: clear asset ownership, patching service-level agreements, emergency patching, external scan validation, centralised logs and segmented management interfaces. This profile is useful when it encourages teams to manage public-facing applications and logging as carefully as endpoints.

What to look for

Play is especially relevant to organizations with public-facing applications, VPN, Exchange-like systems, firewallappliances and remote access. Note exploit tracks, suspicious web quests, valid accounts that are unusually logged in and logs that are suddenly missing or erased.

Important signals include eventlog clearing, audit policy changes, EDR-telemetry gaps, remote service creation, PowerShell, WMI, RDP- jumps, archiving, large file entries and unique ransomware binaries. Since Play-binaries can change, behavior should be central.

Play becomes dangerous when an organization does not have a good view of public systems and logging. If an actor combines operation with log removal, afterwards proving what happened becomes much more difficult.

How to arm yourself against Play

Manage public systems tightly. Point out an owner by application and application, patch quickly, monitor versions, connect unnecessary access and scan externally to exposure. Public-facing systems without owner are an invitation to abuse.

Protect logs. Send Windows-, EDR-, firewall-, VPN- and application logs centrally through, detect eventlog clearing and guard audit policy. Local logs that can be erased by an attacker are insufficient for Play-like incidents.

Use behavioral detection: valid account abuse, exploit tracks, lateral motion, remote execution, datataging and encryption preparation. Hashes are useful for scope but not enough if the actor per attack uses new binaries.

Victim pattern and lessons

Play is visible in multiple sector organisations, but the lesson is mainly shared technology. When victims have the same edge equipment, VPN, Exchange environment or remote access form, that is more relevant than just sector.

For visitors, the most important lesson is that logging is a security check. Without central logs, an attack with log removal can seriously delay the investigation. If you want to arm yourself against Play, evidence must be kept out of reach of the attacker.

Use Play as a reason to control patch processes and external attack surface. Which systems are accessible to the public, who manages them, how quickly emergency patches are performed and what detection exists on abuse?

A practical check is to put the list of public systems next to logging. If a VPN, firewall, webmail environment or application portal does not provide central logs, that is a weakness that has to be solved before an incident.

Also check if eventlog clearing immediately reports. When an attacker can erase logs without central track, Play-like research becomes unnecessarily difficult and data diode is longer uncertain.

Indicators of compromise (IOCs)

Indicators are historical observations, not proof of a current infection. Validate source, age and context before hunting or blocking; legitimate administrative tools can produce false positives.

Sources

• CISA #StopRansomware: Play Ransomware
• CISA updated guidance on Play ransomware
• Ransomware.live — Play

Evidence and limitations

Attribution describes the source assessment, not a verified identity. A leak-site listing alone does not prove encryption, data theft, a particular vulnerability or an affiliate relationship. Missing information is left explicit.