Scenario solution
Database Encrypted by Ransomware
- Microsoft SQL Server
- Oracle Database
- MySQL
- MariaDB
- PostgreSQL
- 达梦 DM
- 人大金仓 KingbaseES
When database files are encrypted, every business system that depends on them stops at once. This page explains how we triage an encrypted database, how recoverability is assessed, and when file repair, backup-plus-log restore, or rebuild is the right path.
Typical symptoms
- Data and log files carry an appended extension, such as ERP.mdf.locked, orcl.dbf.[random-id].weax or ibdata1.crypted
- The database service fails to start; the error log reports an invalid file header, a page checksum failure, or that the physical file cannot be opened
- Applications report connection failures or timeouts; business systems hang at login or return blank pages
- Ransom notes in TXT / HTML / HTA form appear in the data and backup directories, and the desktop wallpaper has been replaced
- Backup files (.bak, .dmp, .sql, archived redo logs) are encrypted as well, or the backup directory has been wiped
- Unknown local administrator accounts exist on the host, and RDP logs show external IP logons outside normal maintenance windows
Business risk & common mistakes
A database is usually the only authoritative copy of a company's data. When it is encrypted, finance, production, inventory, clinical and academic systems fail simultaneously — and downtime is normally determined by the recovery plan, not by the malware. Most prevalent families now use double extortion, exfiltrating data before encryption, so data-exposure and regulatory notification obligations must be assessed alongside the outage.
In practice, what makes data unrecoverable is rarely the encryption itself. It is what happens next:
- Repeatedly rebooting the host or restarting the database service generates new writes, overwrites unallocated space, and lets the engine damage files that were still repairable.
- Formatting, reinstalling the OS, or reinstalling the database into the original directory overwrites residual files and recoverable fragments.
- Running recovery software against the original disk and writing results back to the same volume — self-overwrite, the most common irreversible mistake.
- Running the attacker's decryptor, or a "universal decryption tool" downloaded from the web. The first often decrypts only part of the data and leaves a backdoor; the second frequently carries a second encryption stage or a miner.
- Restoring an already-encrypted .bak or .dmp over production files, destroying the last usable material.
- Disabling endpoint protection and then bringing the host back online to investigate, before the entry point has been closed.
Our position is explicit: we do not recommend paying, and we do not act as negotiators. Payment neither guarantees a working key nor removes the organisation from the target list.
Our response plan
Isolate and preserve evidence
Disconnect the network but do not rush to power off — memory, sessions and live logs matter. Take a read-only image or storage-layer snapshot of the data volumes; all later analysis and recovery runs against the copy. Collect ransom notes, encrypted samples, suspicious binaries, Windows security logs, database error logs, RDP and firewall logs, scheduled tasks and service inventories.
Identify the family and encryption behaviour
Determine family and version from the extension, ransom note filename, contact patterns and sample characteristics, then use entropy distribution to establish the encryption mode: full-file, intermittent (encrypt n bytes, skip m bytes), or header/footer only. This single step decides how many usable pages remain inside the database file, and it cannot be guessed.
Assess recoverability
Score three paths and state a conclusion for each: whether a public decryptor exists for this family and version; how much table data file-level repair can extract, given the encryption coverage established above; and what point in time backup-plus-log restore can reach, given the completeness of full, differential and log backups. The deliverable is a written assessment covering recoverable scope, achievable recovery point, gaps and timeline — before any implementation.
Execute recovery
Work in an isolated recovery environment, against the image. Prefer backup plus log replay to the latest usable point. Where no usable backup exists, perform page-level repair and data extraction, loading readable tables and rows into a fresh instance and reconciling table by table with the business owners. Where neither suffices, rebuild the schema and load whatever data can be obtained, stating explicitly where the gaps are. Every step is logged, and critical operations are double-checked.
Harden and sign off
Remove persistence and backdoors (rogue accounts, services, scheduled tasks, web shells), rotate all credentials, and reduce exposure by removing port forwards and restricting database listener addresses. Rebuild the backup architecture with at least one offline or immutable copy, and run a real restore drill. Sign-off is measured in business terms: row counts on key tables, closing balances, latest document numbers — accompanied by an incident report and hardening recommendations.
Recovery paths
There are five possible recovery paths after a database is encrypted. Their preconditions differ sharply, so assessment must precede action — the wrong order destroys data that was still recoverable.
| Path | Preconditions | Typical outcome |
|---|---|---|
| Public decryptor | Family keys leaked or algorithm flawed, and version matches | Full file-level restoration, but only for a small number of families |
| Encrypted-file repair | Header/footer-only or intermittent encryption, most data pages intact | Readable table data extracted; indexes, LOBs and some rows may be lost |
| Backup plus log restore | Full backup unencrypted, transaction / archived redo / binlogs available | Best outcome; recovery close to the point of failure |
| Snapshots and VSS | VSS is usually deleted, but storage, hypervisor and NAS snapshots may survive | Rollback to snapshot time, losing subsequent changes |
| Low-level carving | Disk not heavily overwritten; deleted backups, exports or tempdb remnants exist | Incomplete data, used as a supplement |
Points we state plainly:
- File repair produces readable data, not the original file. For large databases, families that encrypt only the header often allow most business data to be recovered; against full-file encryption this path is largely ineffective.
- There is no universal decryption method. Current families protect per-file keys with asymmetric cryptography; without the key there is no mathematical shortcut. Public tools exist only under specific conditions.
- We do not use phrases such as "100%" or "guaranteed recovery", and we do not quote a recovery rate before assessment. The assessment states what can be recovered, to which point in time, and what is definitively lost.
- No ransom payment, no negotiation on your behalf. Where insurers, legal counsel or regulators need to be briefed, we supply the technical facts and reports.
Common ransomware families
- Some versions decryptable
Mallox
Mallox (also known as TargetCompany) breaks in mainly through brute-forced MS SQL Server credentials, targets database servers specifically, and has a Linux/ESXi variant. Files encrypted between 2023 and early 2024 may be decryptable with Avast's free tool; later builds have no public decryption method.
- No public decryptor
Weaxor
Weaxor emerged in late 2024 as a same-lineage successor to Mallox, continuing its focus on MS SQL Server and exposed web services. It appends .rox, .weax or .wxx and drops a RECOVERY INFO.txt note. It has led infection volume in China through 2025 and 2026 (45.45% in July 2026, 65.74% in August 2026) and has no public decryptor.
- No public decryptor
TellYouThePass
TellYouThePass is the archetypal vulnerability-driven ransomware family in China, mass-deployed against internet-facing ERP, OA, finance and middleware systems. It appends .locked and hits both Windows and Linux servers. No public decryptor exists.
- Free decryptor available
Phobos
Phobos is a RaaS family that relies mainly on brute-forced RDP and has spawned a long list of variants (.eking, .faust, .elbie, .devos and more). It has been a persistent presence in Chinese server-ransomware cases, and in July 2025 Japan's National Police Agency released a free decryptor covering part of the lineage.
- Some versions decryptable
GlobeImposter
GlobeImposter has been active since 2017 and is highly prevalent in China through its Chinese-zodiac variants (such as .Dragon4444) and Olympian-gods variants (such as .Ares666). It spreads by brute-forcing RDP/SMB and moving laterally, and caused widespread hospital infections in China in 2018. Mainstream variants have no decryptor.
- No public decryptor
Makop
Makop has operated as a RaaS since 2020, with affiliates breaking in mainly through brute-forced remote desktop credentials and deploying by hand. Extensions include .makop, .mkp and .baseus, with a readme-warning.txt note. It ranks consistently high in Chinese infection statistics and has no public decryptor.
Hardening recommendations
- Keep database servers off the public internet. Never port-forward 1433, 1521, 3306, 5432 or 3389; route remote administration through VPN plus a jump server with MFA. Public reporting indicates RDP brute force and vulnerability exploitation together account for close to 80% of ransomware delivery in China.
- Tighten database accounts. Eliminate weak and default passwords (especially sa, system, root), disable high-risk extensions such as xp_cmdshell, separate database accounts from domain accounts, and give application connection strings least-privilege credentials.
- Follow 3-2-1-1 for backups: three copies, two media types, one off-site, and at least one offline or immutable (WORM / object lock). Keep the backup server out of the production domain with dedicated, non-reused credentials.
- A "backup succeeded" message proves nothing. Run real restore drills on a schedule, record actual RTO/RPO, and verify both file readability and database consistency.
- Deploy EDR on every database server, with tamper protection, shadow-copy protection and ransomware behaviour blocking enabled. Do not exempt database hosts out of performance anxiety.
- Patch the front end too. Beyond the database engine itself, ERP, OA, middleware and web applications need patching — a large share of database compromises begin at an exposed application.
- Segment the network and whitelist ports. Allow only required ports from application servers to the database tier, and never let the office network reach the database segment directly.
- Retain logs for at least six months, with database auditing, failed-logon alerting and anomalous-export alerting, so the entry point can be traced afterwards.
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 questions
- First response
What should I do if I've been hit by ransomware?
Isolate first and keep the power on: unplug the network cable or turn off Wi-Fi, but do not reboot, format, delete the ransom note or contact the attackers. Then work in order: confirm it is ransomware and whether it is still spreading, preserve the note, encrypted samples and logs, identify the family, inventory backups and snapshots to assess recovery paths, and report the incident. Do not reconnect restored systems until the entry point is closed, credentials are rotated and backdoors are removed.
- Recovery
Can files encrypted by ransomware be recovered?
Often in part, sometimes almost entirely, but nobody can promise it before seeing samples. Recoverability comes down to four things: the family and version (is there a public decryptor, seized keys or a known flaw), how the files were encrypted (in full, or only partly), which backups, snapshots and other copies survived, and what has been written to the disks since. Where a modern family encrypted files correctly and completely, no copies survive and the remnants have been overwritten, the data may genuinely be gone. Stop all writes and identify the family first.
- First response
What should we do when a server is hit by ransomware?
Isolate first and do not reboot: cut the affected server off at the switch or in the cloud security group, but leave it running. Then snapshot or image the system and data disks, keep the ransom note and encrypted samples, and check read-only whether shadow copies, cloud snapshots and backups survived. If several servers are down, set a restore order by business dependency, and bring nothing back online until the entry point is closed and every credential has been changed. What can be recovered depends on the family, the encryption mode and the backups.
- Ransom & cost
How much does ransomware decryption cost, and how long does recovery take?
There is no fixed price and no fixed timeline. Cost and duration depend mainly on whether the family and version can be decrypted, how many hosts and how much data are affected, how hard database and virtual machine repair will be, whether work is remote or on site, and whether overnight parallel work is needed. We do not quote over the phone: we assess first, then issue a written quotation covering scope, deliverables and expected timing, and start once both sides confirm. An initial family read usually takes hours; a full recoverability assessment normally takes one to several business days.
- Ransom & cost
Should we pay the ransom after a ransomware attack?
We advise against treating payment as the default, and we neither pay ransoms nor negotiate on anyone's behalf. Some organisations do pay, but payment guarantees neither a working decryptor nor deletion of stolen data, it often invites repeat extortion, and buying and moving cryptocurrency for a ransom carries legal and sanctions exposure in China and abroad. Identify the family and establish what backups, snapshots and database repair can recover before deciding anything.
- Recovery
Which ransomware decryption tools exist, and are downloaded ones safe to use?
Yes, but not many. Legitimate free decryptors come from the No More Ransom project, law enforcement agencies and the official channels of vendors such as Emsisoft, Avast, Kaspersky, Bitdefender and 360, and each usually works only for specific versions of a specific family. Programs circulating online as universal or dedicated decryptors are often malware or paid scams. Even with a genuine tool, confirm the family and version match first, and run it only on copies of your files.
- First response
My files all have a new extension and won't open - what should I do?
Do not rename or repair anything yet. If files of many types share the same unfamiliar appended extension (often with an ID and an email address), text, HTA or HTML notes have appeared in every folder and the wallpaper has changed, it is almost certainly ransomware. If only one file type fails, USB files turned into shortcuts, or names are garbled but content opens, a file association, USB worm or encoding problem is more likely. Until you know, disconnect the network, keep the machine on, and save a sample plus the note for identification.
- Systems & software
What should we do when a Linux server or BT Panel is hit by ransomware?
First work out which kind of incident you have: website and database files that have genuinely been encrypted (new extensions, ransom notes in the directories), or databases that were dropped and replaced with a ransom table. The second involves no encryption, nobody can prove beforehand that the attacker kept a copy, and paying is not a recovery path. In both cases cut public access but keep the host running, do not reinstall or keep restarting the database, snapshot or image the data partition, then look for the data in backups, binlogs and disk remnants - and remove every back door before going live again.
- Systems & software
What should we do when Guanjiapo or Suda account sets are encrypted by ransomware?
Isolate the server holding the account sets from the network but keep it powered on. Do not reinstall the accounting software, restore an account set over the original disk, or run decryptors from the internet. Guanjiapo, Suda, Chanjet T+ and T3, Kingdee KIS Professional and similar products mostly keep account sets in SQL Server, with built-in automatic backups on the same machine, so both tend to be encrypted together. How much comes back depends on the family and how it encrypted, whether a clean backup exists beyond that server, and whether the database files were only partly encrypted. After recovery, reconcile stock, receivables and payables line by line, and close the entry point before going back online.
Related industries
Manufacturing Ransomware Response and Recovery
Ransomware in manufacturing hits information systems and production cadence at the same time: with ERP down there are no orders, with MES down there is no schedule, and an encrypted drawing library takes the process documentation for an entire product line with it. This page covers the asset profile, recovery priorities and targeted defences.
Healthcare Ransomware Response and Recovery
When a hospital is hit, registration, consultation, orders, billing, laboratory and imaging fail at the same moment and care falls back to paper. This page covers the healthcare threat picture, a recovery priority built around clinical continuity, and the handling of patient data and compliance obligations.
Financial Services Ransomware Response and Recovery
Financial and quasi-financial institutions face far stricter requirements on data integrity, transaction continuity and regulatory reporting than most sectors, so one ransomware event hits availability, customer trust and compliance simultaneously. This page covers the threat profile, a recovery approach centred on transactional consistency, and hardening priorities.
Retail and E-commerce Ransomware Response
In retail and e-commerce, ransomware translates directly into an inability to sell: order systems, membership, POS and warehouse fulfilment stop together and losses accrue by the hour. This page covers the sector's attack patterns, a recovery order built around the order-to-fulfilment chain, and handling of member data exposure.
Related services
Ransomware Decryption
Identify the family first, then commit to a recoverable scope — without paying a ransom.
Data Recovery
Recovery beyond decryption: backup repair, database repair and remnant extraction.
Incident Response
Round-the-clock intake: contain first, preserve evidence second, recover third.
Attack Forensics & Attribution
Establish the intrusion path, timeline and impact — in a report usable for police reporting and compliance.
FAQ
Frequently asked questions
Can an encrypted database still be recovered?
Often yes, but it depends on three objective conditions: the family's encryption mode, how complete the backups and logs are, and whether overwriting operations occurred after the incident. Large database files are frequently only header/footer-encrypted or intermittently encrypted, leaving most data pages intact and allowing readable table data to be extracted; if full backups and transaction logs survive, the outcome is better still. Conversely, full-file encryption combined with wiped backups and a site that has been repeatedly rebooted and reformatted leaves very little room. A real answer comes from assessment, not from a promise.
Our database is hundreds of GB — was only part of it encrypted?
Very likely. To finish before detection, most families encrypt only the beginning (sometimes also the end) of large files, or use intermittent encryption — encrypt a block, skip a block. LockBit, BlackCat, Play and Qilin have all advertised intermittent encryption. For databases this matters: rows live in pages spread across the whole file, and untouched pages still hold complete data. However, encryption coverage must be measured with entropy analysis; it cannot be inferred from file size, and it must not be probed by trying to start the database.
Should we reboot the server or try to start the database service?
No. Isolate the network first and preserve the current state while you engage incident response. Repeatedly starting the database service lets the engine keep writing to and rolling back damaged files, potentially destroying pages that were still extractable. Rebooting also discards valuable memory artefacts and overwrites unallocated disk space, hurting both carving and attribution. The correct sequence is: disconnect, document the scene, stop writing to the original disk, image or snapshot the data volumes read-only, then analyse the copy.
Our backup files were encrypted too — is it hopeless?
Not necessarily. Attackers usually go after online, reachable backups first, but several copies are often missed: storage- or hypervisor-layer snapshots, read-only or immutable snapshots on a NAS, media held off-site or offline, older exports in dev/test environments, and application-side intermediates such as end-of-day exports, reconciliation files and report snapshots. An encrypted .bak may itself be header-only encrypted and still worth repairing. We inventory all of these sources rather than trusting the backup console alone.
How long does it take from first contact to business recovery?
Remote access normally begins shortly after the engagement is confirmed; isolation, evidence preservation, family identification and an initial recoverability read typically yield a directional conclusion within hours. Actual recovery duration depends on data volume, encryption coverage and backup completeness: cases with usable full backups and logs are fastest, while cases requiring page-level repair and table-by-table business reconciliation take considerably longer. We provide a staged timeline during assessment rather than a single vague figure up front.
Will you negotiate with the attackers for us?
No. We do not negotiate and we do not advise paying. Payment cannot guarantee a working key or a complete decryptor, it funds further attacks, and it places the organisation on a list of targets worth revisiting. We put our effort into technical recovery, root-cause attribution and hardening. Where you need to brief insurers, counsel or regulators, we provide a factual technical report to support that.
Updated