Weaxor encrypts a game operator's account database

The client is a mobile game operator publishing several casual and card titles. Player accounts, recharge orders and item-grant records all ran on one MS SQL Server instance on a single Windows server — separate databases in the same instance, with data files and the daily backup written to another partition on that same machine.

To give an outsourced channel-settlement team remote access, port 1433 was mapped directly to the internet long-term, the sa account still used the password set when the project launched, and the application connection string reused sa as well.

Early one weekend morning, the support desk filled with player complaints: logins returned account verification failures, items never arrived after a charge went through, and callbacks from the payment channel all timed out. The on-duty engineer found the SQL Server service stopped, the .mdf and .ldf files in the data directory and the .bak files on the backup partition all carrying an appended .rox extension, and a ransom note named RECOVERY INFO.txt in the same folders. The note directed the victim to a Tor negotiation page, gave two anonymous mailboxes as a fallback, and offered free test decryption of three files up to 5MB each while explicitly excluding databases and backups. Shadow copies had been cleared.

Before calling us, the engineer had already started the database service twice by hand and tried restoring one encrypted .bak back into the instance.

Containment instructions went out on the first call: keep the server powered but off the network, stop writes and scheduled tasks, make no further attempt to start the instance, run no DBCC repair or force-attach against the .mdf files, and close the top-up channel so a half-available service could not keep generating unreconcilable orders.

• Evidence and imaging. Read-only images of the system disk, data disk and backup partition, plus SQL Server error logs and logon auditing, records of xp_cmdshell being enabled, Windows security logs, firewall forwarding rules, scheduled tasks, traces of remote-access tool installation, the original ransom notes and encrypted samples of varying size. All later work ran on copies.
• Family confirmation and recoverability. The .rox extension with the RECOVERY INFO.txt note identified Weaxor, clearly distinct from Mallox — Avast's Mallox decryptor did not apply, no public decryptor existed, and decryption was ruled out immediately. Large-file handling is not consistent across this family's builds and cannot be extrapolated from Mallox, so each file was measured: in this sample the .mdf files showed the segmented entropy pattern of intermittent encryption, keeping a substantial proportion of intact 8KB pages in the middle and tail, with lighter damage to the .ldf logs — making page-level repair viable here.
• Recovery. A clean instance was built in an isolated environment; page-structure scanning rebuilt system tables and allocation structures, and usable pages were extracted table by table into a fresh database — the output being readable data rather than the original files. Untouched log segments were replayed to fill in writes up to the outage, and recharge orders were reconciled line by line against channel settlement records.
• Payload removal and hardening. Residual payloads and persistence were cleared before anything faced the internet again — this family uses multi-layer obfuscated loading, process injection and AMSI bypass, and remnants make re-encryption very likely. The public 1433 mapping was then replaced by VPN access with enforced multi-factor authentication, credentials were reset with source-IP restrictions, xp_cmdshell was disabled, the application moved to a least-privilege account, and backups moved to an independent host plus an offline immutable copy.
• Deliverables. An attribution and incident report, per-database and per-table recovery coverage, a conclusion on data exfiltration, and a staged-relaunch and reconciliation sign-off checklist.