Skip to main content

Hit by ransomware? Isolate affected systems now. Do not reboot or reformat.

SheMo Noransom舍末无勒

Ransomware family

Play Ransomware Decryption & Data Recovery

  • Active
  • Critical
  • No public decryptor

Play (PlayCrypt / Balloonfly) has been active since June 2022 and is one of the few closed-group ransomware operations, recompiling its encryptor for every victim. It targets FortiOS and Exchange flaws, RDP and VPN, and maintains a dedicated ESXi encryptor. CISA counted roughly 900 victims as of May 2025, and public leak-site trackers list over 1,200 entries as of September 2026.

First seen
2022-06
File extensions
.play .PLAY
Ransom notes
ReadMe.txt
Affected platforms
Windows / Linux / VMware ESXi

Family profile

File extensions
  • .play
  • .PLAY
Ransom notes
  • ReadMe.txt
Contact patterns
  • @gmx.de mailbox (one address per victim)
  • @web.de mailbox (one address per victim)
  • Phone calls to victim staff to apply pressure
  • Play leak site (Tor)
Aliases / versions
PlayCrypt、Balloonfly、Play Ransomware
First seen
2022-06
Status
Active
Threat level
Critical
Affected platforms
  • Windows
  • Linux
  • VMware ESXi
Tags
  • Leak-site regular
  • Active
  • Double extortion
  • Targets virtualization
  • Exploits vulnerabilities
  • RDP brute force
Decryptor
No public decryptor

No public, free Play decryptor exists, and none is listed on NoMoreRansom or similar platforms.

Play uses hybrid AES plus RSA encryption with the session key wrapped under the operators' public key. Making matters harder, Play recompiles the encryptor for each victim, so sample hashes differ every time — which also undermines any signature-based universal decryption tool. No exploitable key-reuse or nonce weakness has been publicly identified in its implementation.

One specific warning: Play telephones employees of victim organisations to apply pressure, and some victims have received calls during that period from third parties claiming they can decrypt. Those are typically follow-on scams. Recovery must come from backups and snapshots, intact blocks left by intermittent encryption, and unencrypted copies and logs — see the recoverability assessment.

Latest activity

  1. Play's leak site was still posting new victims on 10 September 2026; public trackers list over 1,200 cumulative entries (ransomware.live: 1,312), well above the ~900 CISA reported as of May 2025. The group is not defunct.

    Sources
  2. Symantec found Play-linked Balloonfly exploiting Windows CLFS zero-day CVE-2025-29824 for SYSTEM before the 8 April patch, entering via an internet-facing Cisco ASA and dropping Grixba; no encryptor was deployed in that intrusion.

    Sources

Overview

Play (also PlayCrypt; Symantec tracks the operators as Balloonfly) first appeared in June 2022, named after the uniform .play extension and the single word in its ransom note. Unlike openly recruiting RaaS operations such as Akira, Qilin and RansomHub, CISA assesses Play as a closed group — no public affiliate recruitment, tooling and infrastructure kept in-house. Its tradecraft has therefore stayed remarkably consistent, which makes family-driven response unusually effective here.

CISA, the FBI and Australia's ACSC published the #StopRansomware advisory AA23-352A in December 2023 and updated it on 4 June 2025, reporting roughly 900 victim organisations as of May 2025 across businesses and critical infrastructure in North America, South America and Europe, with notable impact on government and police networks in Latin America. In April 2024 Play was briefly the most prolific ransomware group of the month, and it remains on active-family lists through 2026.

Two technical points matter for regional enterprises. First, per-victim recompilation: Play builds a fresh encryptor for each attack, so every sample hash is unique and both hash-based blocklists and "we run antivirus" assumptions fail. Second, full ESXi capability: in July 2024 Trend Micro documented a Linux variant purpose-built for VMware ESXi, using AES-256 against .vmdk, .vmem, .vmsd, .vmsn, .vmx, .vswp and .nvram files and dropping notes under /vmfs/volumes — squarely against the consolidated virtualisation designs common in manufacturing and hospitals.

Play also has a distinctive coercion habit: some victims receive phone calls from the attackers threatening to publish data. Offline pressure layered on double extortion tends to force decisions before technical assessment is complete, which is why establishing a "no payment, no unilateral contact" policy in advance matters here more than usual.

How to identify it

Extension. Encrypted files uniformly gain .play (some samples show uppercase .PLAY), with no per-file variation — Play's most immediate signature.

Ransom note. The file is ReadMe.txt, typically in C:\Users\Public\Music rather than scattered through every directory. Content is minimal: usually the single word "PLAY" plus a @gmx.de or @web[.]de address, unique per victim. The combination of a German free-mail address with near-empty text distinguishes Play clearly from other families.

Host-side artefacts.

  • The encryptor is recompiled for every attack, so sample hashes are unique — hash matching will not identify it.
  • Common tooling: Cobalt Strike, SystemBC (proxy and persistence), PsExec, AdFind, Mimikatz, WinRAR, WinSCP.
  • GMER, IOBit and PowerTool-class utilities used to disable security software, plus the custom infostealer Grixba to enumerate security products, backup software and remote-access tools.
  • Volume shadow copies deleted; bulk-execution traces across the domain (Group Policy, PsExec, scheduled tasks).

Virtualisation artefacts. On ESXi, guests go offline en masse, .vmdk/.vmem/.vmsn files are encrypted, ransom notes appear under /vmfs/volumes and in the ESXi root, and in some cases the ESXi login banner is modified to display the ransom message.

Offline signal. Staff or executives receiving calls or voicemails from the attackers threatening publication — markedly more common in Play cases than in other families.

Infection vectors

Play depends heavily on exposed edge devices and remote access, and has concentrated on a small set of known vulnerabilities for years — which is good news for defenders, because the self-check list is concrete.

1. FortiOS flaws: CVE-2018-13379 (path traversal leaking credentials) and CVE-2020-12812 (SSL VPN second-factor bypass). Both are years old and still exploited repeatedly, indicating large numbers of unpatched devices.

2. Microsoft Exchange ProxyNotShell: CVE-2022-41040 chained with CVE-2022-41082 to land directly on Exchange.

3. Remote-support software flaws: the 2025 advisory update added SimpleHelp CVE-2024-57727, which Play used to reach downstream organisations through MSP and operations channels.

4. Valid RDP and VPN accounts: logging in with leaked or brute-forced credentials, with almost no friction where MFA is absent.

The post-compromise chain is stable:

  • domain enumeration with AdFind, inventory of security and backup software with Grixba, credential theft with Mimikatz;
  • Cobalt Strike and SystemBC for persistence and proxying;
  • GMER/IOBit/PowerTool to disable antivirus and EDR;
  • staging with WinRAR and exfiltration over WinSCP to set up double extortion;
  • domain-wide deployment of the individually compiled encryptor via PsExec, Group Policy or scheduled tasks, with the Linux variant pushed to ESXi.

Because the toolchain is fixed, detections for SystemBC, Grixba, GMER driver loading and bulk WinSCP egress frequently catch Play before encryption begins.

Encryption behavior

Algorithms. A hybrid AES plus RSA scheme: file data encrypted with AES, and the AES key wrapped under the operators' RSA public key and stored with the file. The ESXi variant uses AES-256 for virtual-machine files.

Intermittent encryption. The CISA advisory records it explicitly: Play encrypts intermittently, processing files in 0x100000-byte (1 MB) units and skipping system files. For large files — VMDKs, database mdf/ndf/dbf/ibd files, archives — only part of the data is AES-covered while the rest remains usable original data. That is how Play finishes an entire domain and virtualisation cluster quickly, and it is the most practical opening for .play file recovery. Actual coverage depends on build and parameters and must be measured per case.

Per-victim compilation. The encryptor is rebuilt for every attack and every hash is unique. This affects detection and attribution, not the recovery method itself.

Destructive actions.

  • Deletes volume shadow copies.
  • Stops database, backup-agent and security services, using GMER/IOBit-class tools to unload protection where needed.
  • On ESXi, walks /vmfs/volumes encrypting virtual-machine files (.vmdk, .vmem, .vmsd, .vmsn, .vmx, .vmxf, .vswp, .vmss, .nvram, .vmtx, .log) and writes notes in the root and volume directories.
  • Clears selected log artefacts.

Double extortion. Data is staged with WinRAR and exfiltrated over WinSCP before encryption; non-payers are posted to the leak site, reinforced by phone calls.

Assess before you act

Recoverability assessment

There is no public decryptor for Play, but its intermittent encryption usually leaves more room in large-file recovery than fully encrypting families. We test in this order.

1. Backups, snapshots and shadow copies. Shadow copies are generally deleted, though residual difference blocks are worth scanning. Focus on offline and off-site backups, tape, immutable or object-locked cloud backups, and snapshots on storage arrays and NAS controllers (the ESXi variant cannot reach controller-layer snapshots). Because Play inventories backup software with Grixba before destroying it selectively, every surviving copy must be validated for restorability rather than assumed good.

2. Intact blocks left by intermittent encryption — the primary recovery source in Play cases. The 1 MB skip-block scheme CISA documents means VMDKs and database files retain large volumes of original data:

  • map the encryption layout of VMDKs, locate AES-covered 1 MB blocks against intact ranges, rebuild partition tables and filesystems from the intact ranges, and export guest databases, shares, mail stores and business files;
  • repair SQL Server, Oracle and MySQL data files at page and extent level, discarding overwritten pages, rebuilding indexes and metadata, then merging unencrypted transaction and archive logs back to consistency;
  • extract usable objects from PST files, ZIP/RAR archives, imaging and CAD data by walking format structures across intact ranges.

It depends on the encryption layout. A high skip ratio with critical metadata (partition tables, database header pages, directory entries) outside the encrypted regions usually yields a high recoverable share; the reverse reduces it sharply. Measurement precedes assessment, and we do not quote percentages beforehand.

3. Unencrypted copies and log replay. Dev/test databases, read-only reporting instances, downstream warehouses, ERP/OA staging tables and interface files, endpoint-local copies, mail attachments and scan archives frequently fill gaps; transaction and interface logs can rebuild documents.

4. Low-level carving. Depending on write behaviour, deleted originals, purged backup directories and removed VM snapshots may leave recoverable clusters.

On phone pressure. Play calls staff and even executives directly. That is a negotiation tactic and changes nothing technically. We do not pay ransoms or negotiate on a client's behalf, and we advise establishing a single external communication line so employees under pressure do not contact attackers unilaterally or fall for "third-party decryption" cold calls.

Our response plan

Hit by Play ransomware? What to do

  1. Containment, forensics and a single communication line

    Isolate affected hosts and ESXi clusters, take read-only images of datastores, database files and backup volumes, and preserve ReadMe.txt (note its location under C:\Users\Public\Music), encrypted samples, Fortinet/Exchange/VPN logs and domain execution artefacts. Do not power off, do not rebuild, do not work on original disks.

    Play cases need one extra step: establish a single external communication line immediately. Because the attackers phone staff and executives directly, and third parties claiming decryption capability often call during the same window, all external contact must route to the response team so no individual engages or pays on their own.

  2. Family identification and 1 MB skip-pattern measurement

    Confirm the family from the combination of .play extension, C:\Users\Public\Music\ReadMe.txt and the @gmx.de/@web.de address — and remember that Play recompiles per victim, so hash matching is useless; identification relies on behaviour and file structure.

    Then run per-block entropy analysis on representative large files (vmdk, mdf/ndf, dbf, ibd, pst, archives) to verify the 1 MB skip-block pattern, measure real coverage and distribution, and determine whether critical metadata such as partition tables and database header pages was overwritten. This finding sets the ceiling for everything that follows.

  3. Recoverability assessment and plan

    Consolidate measured results across routes: backup and storage-snapshot availability (validated copy by copy, not counted), the reach of partial-encryption repair, what unencrypted copies and logs can backfill, and carving opportunities.

    The deliverable is a recoverability assessment stating, per business system, the recoverable scope, achievable point in time, consistency risks, what cannot be recovered, and effort and resources — plus recovery priority (typically core databases and ERP before file shares and archives). Execution starts after sign-off, not before results are known.

  4. Recovery execution and business validation

    Execute in an isolated clean environment: restore from usable backups or storage snapshots; rebuild VMDK extents and export guest data; repair databases at page level with log merging and consistency checks; restore file shares and archives in priority batches.

    Each recovered system goes to business owners for sampling against core tables, key documents and recent activity before production cutover. Where the latest point in time is unreachable, we deliver a data-gap list so the business can backfill from paper records, upstream and downstream systems, or correspondence.

  5. Attribution, hardening and sign-off

    Reconstruct the intrusion chain against Play's fixed entry points: is FortiOS still exposed to CVE-2018-13379 / CVE-2020-12812, is Exchange unpatched for ProxyNotShell (CVE-2022-41040 / CVE-2022-41082), what version is SimpleHelp or similar remote-support software (CVE-2024-57727), and do RDP and VPN lack MFA.

    Hardening is equally concrete: patch governance for edge devices and Exchange with end-of-life hardware retired, MFA everywhere, no internet-facing RDP, restrictions on PsExec and bulk Group Policy execution, backups moved off-domain onto immutable storage, SSH disabled and lockdown mode enabled on ESXi, and detections for SystemBC, Grixba, GMER driver loads and bulk WinSCP egress — that toolchain is remarkably stable in Play cases and detects well. We close with a sign-off report and a 30-day observation recommendation.

Risk warning

What not to do

  • Do not take the attackers' calls and respond on your own. Play telephones staff and executives to apply pressure; unilateral contact disrupts the response, raises the demand, and exposes people to follow-on scams from callers claiming they can decrypt.
  • Do not use hashes or sample comparison to judge whether attacks are "the same batch". Play recompiles its encryptor per victim, so hashes always differ — identification must rely on extension, note location and behaviour.
  • Do not reboot or rebuild encrypted ESXi hosts, and do not recreate datastores. The intact blocks skipped by the 1 MB intermittent scheme inside VMDKs are the primary recovery source in Play cases.
  • Do not run chkdsk / fsck or disk-repair utilities against encrypted volumes, and do not trial unknown decryptors on original disks — both overwrite recoverable blocks.
  • Do not resume operations before FortiOS, Exchange and remote-support software are patched and attacker accounts removed. Play's entry points concentrate on these known flaws, and an unclosed door invites a repeat.
  • Do not delete ReadMe.txt, encrypted samples, SystemBC/Cobalt Strike artefacts, or VPN and Exchange logs. They underpin family identification, exfiltration scoping and compliance notification.

Emergency response

Data already encrypted? Stop and let an engineer look first

We do not pay ransoms and we do not negotiate with attackers. Engineers run a free assessment first, then propose a recovery plan and a firm quote.

Related scenarios

Related industries

Similar families

FAQ

Play Frequently asked questions

  • Can Play ransomware (.play extension) be decrypted?

    No free public Play decryptor exists; its hybrid AES plus RSA construction has no publicly exploitable weakness, and NoMoreRansom does not list one.

    Recovery of .play files is still realistic, though. The CISA advisory records that Play encrypts intermittently in 1 MB units, covering only part of large files. VMDKs, database data files, PST files and archives therefore often retain substantial original data that can be reclaimed by mapping the encryption layout and applying structured repair.

    Storage-array and NAS-controller snapshots should also be checked — the ESXi variant cannot reach that layer. How much returns depends entirely on the real coverage ratio and whether critical metadata was overwritten, so measurement comes first.

  • The attackers are calling our company threatening to publish data — what should we do?

    This is standard Play behaviour, and the CISA advisory records that some victims are contacted by phone. Three recommendations:

    One, single line of communication. Notify all staff immediately that any call or email claiming to be the attackers, the press, or a party that can decrypt goes straight to the response team — no commitments, no confirmation of internal details. In practice, follow-on scammers often exploit this window by posing as security vendors.

    Two, run the exposure assessment in parallel. Use firewall, proxy, VPN and host logs to establish the timing, channel and volume of exfiltration, scope the business data and personal information involved, and assess notification obligations under China's Cybersecurity Law, Data Security Law and PIPL. This work cannot wait for negotiations to conclude.

    Three, do not make contact or pay on your own. Payment guarantees neither deletion nor a working key, and it carries compliance and legal exposure. We do not pay ransoms or negotiate; we establish what is technically recoverable.

  • Play encrypted our whole ESXi cluster — can the virtual machines be recovered?

    Often yes. Play's Linux variant encrypts .vmdk, .vmem, .vmsd, .vmsn, .vmx, .vswp and .nvram with AES-256 and leaves notes under /vmfs/volumes, but it encrypts intermittently too — large VMDKs typically retain long runs of original data.

    Our approach: image the datastore read-only, map the encryption layout of the VMDKs, locate covered blocks against intact ranges, rebuild partition tables and filesystems from the intact ranges, and export guest databases, shares and mail stores; database files then get page-level repair and log merging.

    At the same time, check storage-array, hyperconverged or NAS-controller snapshots immediately and suspend automatic reclamation — that layer is usually beyond attacker reach and is the fastest route back. Do not reboot ESXi hosts or recreate datastores; any write can overwrite recoverable data.

  • Why didn't antivirus stop Play?

    Three concrete reasons.

    First, a separately compiled encryptor per victim. Every sample hash is unique, so hash- and known-sample-based detection fails by construction.

    Second, the attackers strip protection deliberately. Play routinely uses GMER, IOBit and PowerTool to disable antivirus and EDR, after inventorying which security products and backup software you run with its custom tool Grixba, then handling each specifically.

    Third, the entry point bypasses endpoints entirely. FortiOS CVE-2018-13379, Exchange ProxyNotShell, SimpleHelp flaws, or VPN/RDP without MFA are all breached at the edge, outside endpoint protection — by the time the encryptor lands, the attacker already holds domain admin.

    Defence therefore has to shift forward: patch governance for edge devices and Exchange, MFA everywhere, no internet-facing RDP, plus behavioural detection for SystemBC, Cobalt Strike, GMER driver loads and bulk WinSCP egress. Play's toolchain is unusually stable, so behavioural detection pays off far better than signature matching.