Skip to main content

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

SheMo Noransom舍末无勒

Industry solution

Gaming & Interactive Entertainment

A ransomware event at a game company usually runs on two separate loss tracks: the outage — account, top-up and leaderboard databases encrypted, with churn and refunds accruing by the hour — and double extortion over stolen source code, unreleased content and art assets. This page covers the typical entry points across live-ops and development environments, a recovery order built on data consistency and repository integrity, and how staged relaunch and exfiltration assessment are handled.

Critical business systems

  • Account, top-up and order databases (MySQL, Microsoft SQL Server)
  • Redis and similar cache clusters for leaderboards, sessions and matchmaking
  • Login, gateway and game logic servers (mixed Windows and Linux)
  • Payment callback services and channel or third-party SDK gateways
  • Version control and development systems (Perforce, Git, Jenkins build machines)
  • Art and audio asset libraries, render farms and asset NAS
  • Live-ops consoles, GM tooling and customer-support ticketing
  • Telemetry logs, data warehouse and BI analytics platforms

Threat landscape

Game companies expose far more to the internet than a typical enterprise, and attackers often need nothing sophisticated to get in. Published ransomware landscape reports rarely break gaming out as its own vertical, so the three paths below are drawn from patterns that recur across public incidents and general threat reporting:

  • Databases and caches exposed directly. To keep latency low, account stores, billing stores and Redis frequently sit on routable segments. Weaxor — the same-lineage successor to Mallox and a long-running leader in Chinese infection volume — works primarily through weak Microsoft SQL Server credentials and exposed web services. When cloud security vendor Wiz disclosed a critical Redis flaw in October 2025 it counted roughly 330,000 internet-visible Redis instances, about 60,000 of them with no authentication at all; such instances are scanned at scale, and the P2Pinfect worm — which has targeted exposed Redis servers since 2023 — began pushing a ransomware module in May 2024.
  • Remote access without multi-factor authentication. Outsourced art, external testing and multi-site studios leave behind large numbers of long-lived VPN and RDP accounts, and the signature entry point for families such as Akira is precisely a VPN without MFA or an unpatched edge device.
  • Development assets as a second lever. Public incidents show this repeatedly: Capcom was hit by Ragnar Locker in November 2020 through an old VPN appliance at its North American subsidiary that had been superseded but kept online as an emergency fallback; its final investigation confirmed personal data for 15,649 people was taken, with up to roughly 390,000 potentially affected. CD Projekt Red had source code for several projects stolen in February 2021 and publicly refused to negotiate or pay. And in late 2023 Rhysida attacked Sony's Insomniac Games, publishing roughly 1.67TB and over 1.3 million files — including unreleased project material, internal HR files and scanned employee passports — after a USD 2 million demand went unmet.

Development, test and live-ops back ends also tend to sit on a handful of ESXi hyper-converged clusters, and families such as Qilin specialise in the virtualization layer, so a single encryption run can halt development and operations at once.

Business impact

  • Downtime converts straight into revenue and retention loss. Game revenue accrues hourly, and a prolonged outage adds churn, falling store ratings and clustered refund requests — often costing far more than the recovery itself.
  • Top-ups and items stop reconciling. Payment callbacks, channel settlement and item grants live in separate systems, so a poor recovery point produces charges without deliveries, or duplicate grants, requiring item-by-item reconciliation and compensation.
  • Leaked source code and unreleased content cannot be walked back. Source code leaks directly fuel cheats and private servers, while leaked unreleased material disrupts release plans and partner relationships.
  • Player data exposure carries compliance duties. Verified identity details, phone numbers and payment records are sensitive personal information; exposure triggers reporting and notification obligations and may draw regulatory action.
  • Development stalls. When repositories, build machines and art assets are hit together, a team can fall back to its most recent usable local clones, losing weeks of progress.

Our response plan

  1. Close the exposure first, then preserve the data layer

    Contain by exposure surface rather than by machine: drop external mappings, revoke remote access credentials and cut inter-studio links, while keeping internal forensic conditions intact. Do not rush to restart or repair the data layer — image SQL Server and MySQL data files and logs, Redis persistence files and virtual machine disks read-only first. Post the outage notice early, so players do not keep topping up against a half-available service and make later reconciliation harder.

  2. Trace the entry point and assess exfiltration in parallel

    Run forensics alongside recovery, focusing on four entry classes: exposed databases and caches, VPN and RDP without MFA, unpatched edge devices and web services, and outsourced or third-party accounts. The exfiltration question ranks no lower than recovery itself: examine anomalous checkouts from repositories and build machines, bulk reads from the asset NAS, unusual egress traffic and staged archive directories, and establish whether source code, unreleased content or player data left the network, and at what scope. That conclusion drives external messaging and compliance reporting, so it cannot wait until recovery finishes.

  3. Order recovery around data consistency and repository integrity

    The hard part with game data is that several stores must agree with each other: accounts, top-up orders, inventories, leaderboards and season progress, plus Redis as the cache. Choose the recovery point on whether payments and items will reconcile, not simply on which backup is newest. Suggested order: identity and network infrastructure, then core account and billing stores, then login and logic servers, then caches and leaderboards rebuilt by recomputation from persistent stores rather than trusting an encrypted cache snapshot, then live-ops consoles and the data platform. Development follows a separate track: rebuild repositories from developer clones and build artefacts first, verifying integrity revision by revision.

  4. Relaunch in stages with reconciliation-led acceptance

    Recover and validate in an isolated environment before reopening, and reopen in stages: internal first, then a limited cohort, then everyone. Reconciliation is the heart of acceptance — do top-up orders match channel and payment platform records item by item, are item grants and consumption continuous, do leaderboards and season progress agree with the persistent stores, do cross-server and matchmaking features work. Log every discrepancy individually and settle the compensation plan before announcing it. Development-side acceptance covers whether repositories check out completely and build successfully, and whether art asset checksums and references remain intact.

  5. Shrink exposure and harden the development chain separately

    Remediation means taking back the shortcuts opened for convenience: move databases and caches off the public internet behind gateways and internal access with enforced strong credentials and access control; enable MFA on every remote access path; funnel outsourced and third-party access through a jump host, authorised per work order, fully audited and revoked automatically on expiry. Harden the development chain in its own right — build machines and repository servers should not share a domain or credentials with game servers, the asset NAS should have anonymous shares disabled and versioned snapshots enabled, backups should keep an offline or immutable copy, and recovery drills including reconciliation should run on a schedule.

Common ransomware families

Hardening recommendations

  • Keep databases and caches off the public internet. Bind account stores, billing stores and Redis to internal addresses, set access credentials and ACLs, disable dangerous commands and patch promptly; directly reachable unauthenticated instances are scanned continuously and are the easiest entry class to abuse.
  • Require MFA on all remote access. VPN, jump hosts, maintenance bastions and cloud consoles all need MFA, leavers' and contractors' accounts need a clean-up process, and dormant accounts should disable automatically.
  • Separate development from live operations. Repositories, build machines and the asset NAS should not share a domain or credentials with game servers, and build machines should not hold release rights into production.
  • Funnel outsourced and external collaboration. Route art outsourcing, external testing and channel integration through a controlled path, authorised per work order, fully audited and revoked on expiry, with no shared accounts.
  • Back up development assets too. Many studios back up only the player databases and overlook repositories, build artefacts and art assets; all three need an offline or immutable copy.
  • Patch edge devices and middleware promptly. Public reporting puts exposed web services and edge-device vulnerabilities among the leading initial access routes of the past two years, so the patch window should be measured in days.
  • Least privilege for live-ops consoles and GM tooling. Grant support, contractor and operations accounts by role, log and alert on sensitive actions, and keep the back office from becoming an exfiltration channel.
  • Drill the outage, not just the restore. Run a quarterly recovery drill that includes payment reconciliation, record the real RTO and RPO, and prepare outage announcement and player compensation templates in advance.

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.

+86 15639272850See contact details

Related scenarios

FAQ

Frequently asked questions

  • How do we handle top-ups and items during the outage?

    Close the payment channel first so a half-available service does not keep generating unreconcilable orders. After recovery, cross-check three sources: channel and payment platform settlement records, your own order store, and item grant logs. Gaps after the recovery point can usually be closed from channel statements and payment callback records, while duplicate grants are de-duplicated by order number and idempotency key. Log discrepancies individually with their cause before deciding on re-issue or compensation, and state the basis in the announcement — players care more about consistency than speed.

  • Our source code was stolen — will paying get it deleted?

    There is no way to verify that anyone actually deleted the data. Public incidents include cases where data was published or resold after payment, and the games industry has several public precedents for refusing: CD Projekt Red said in 2021 that it would neither negotiate nor pay, and Riot Games — whose development environment was breached by social engineering in 2023 and whose source code was stolen — said publicly it would not pay the ransom demand it received. We do not pay ransoms and do not negotiate on your behalf. The realistic path is to determine the scope of what was taken as fast as possible, assess cheat and private-server risk and prepare countermeasures in parallel — key and certificate rotation, stronger server-side validation, anti-cheat updates — complete the required reporting and notification, and keep control of your own communication timeline.

  • Our Redis leaderboard and session data was encrypted — can it be recovered?

    In most cases you do not recover from Redis itself. The correct path for cache data is recomputation from the persistent stores: recalculate leaderboards from season scores, invalidate sessions and have players log in again, flush and rebuild matchmaking queues. Where some data exists only in Redis and was never persisted — a common piece of design debt — assess the encryption state of the RDB or AOF files: some families encrypt large files intermittently, and untouched blocks may yield partial records. That is a case-by-case assessment, not a dependable route.

  • Our SQL Server was encrypted — is there a free decryptor?

    It depends on the family and the encryption date, and the extension alone is not enough to tell. A common misconception: Weaxor (extensions such as .rox and .weax) is assessed as sharing Mallox's lineage, so people try Avast's Mallox decryptor on it — that does not work, because the operators fixed the cryptographic flaw it relied on. The correct approach is sample analysis of real encrypted files and the ransom note to pin down family and build before judging whether a public tool applies, while running backup inventory and database file repair feasibility in parallel rather than spending the whole window on decryptors.

  • How long will recovery take, and can we avoid a full shutdown?

    Timing depends on backup availability, the scope affected and how strict the consistency requirements are; we give a range after the on-site inventory rather than committing to a number up front. Whether a full shutdown is needed depends on your partitioning: if each region's databases and logic servers are genuinely independent and confirmed untouched by lateral movement, isolating the affected region can be enough. But where accounts, payments and the live-ops console are shared globally, partial operation usually costs more than it saves — letting players into an inconsistent shard raises the later reconciliation and compensation bill.

Updated