Service
Data Recovery
- Recovery beyond decryption: backup repair, database repair and remnant extraction.
When direct decryption is not viable, we recover usable production data through backup and snapshot repair, file-level database repair, and extraction of unencrypted remnants and fragments.
What this service covers
This service handles the case where decryption is not viable but the data still matters. A substantial share of ransomware incidents cannot be solved with a decryptor, yet the data is rarely all gone: backup chains are often partly usable, storage snapshots get overlooked, database files may have only headers and some pages encrypted, and encryptors frequently skip large files or whole directories.
The main recovery paths
- Backup and snapshot repair: verifying backup chain integrity, repairing damaged backup catalogues and indexes, and extracting usable restore points from storage snapshots, hypervisor snapshots and cloud copies.
- File-level database repair: page- and block-level repair of SQL Server, Oracle and MySQL data and log files, system table reconstruction, log replay and data extraction — the goal is exporting usable business data, not forcing a damaged database to mount.
- Unencrypted remnant extraction: searching unallocated space, temporary directories, shadow copy fragments, application caches and exported files for untouched original data.
- Reassembly of intermittently encrypted files: some families encrypt only fixed regions, so large files can yield intact data areas that are rebuilt into usable records.
- Array and storage structure repair: where RAID metadata is lost, LUN mappings are wrong or NAS volume metadata is damaged, the storage structure is rebuilt before the file layer is addressed.
Stated honestly
Data recovery is a question of scope, not of yes or no. During assessment we state which systems and which points in time we expect to recover, and what may be permanently missing. Physically damaged media, overwritten regions and fully encrypted files all sharply reduce the odds. We will not burn your time window on a speculative attempt, and we do not keep billing an engagement we have assessed as unrecoverable.
Deliverables
- Survey findings: extent of encryption, backup usability, integrity of the storage structure
- Per-path recovery plan with priorities across backup restore, database repair and remnant extraction
- Delivery manifest for recovered data, annotated by system and point in time
- Verification report: file open rate, database consistency checks, business sampling
- Statement of permanently lost data with advice on re-entry and reconstruction
How it works
Survey of the current data state
We inventory the affected volumes, directories and file types, determine how much is encrypted and whether encryption was intermittent, check backup servers, storage and hypervisor snapshots and off-site copies for usable restore points, and confirm whether disks or arrays have physical or structural problems.
Read-only imaging and working copies
Key disks and volumes are imaged read-only and every recovery action happens on the copy, leaving the original media untouched. This protects the data and also preserves the original evidence needed later for forensics and police reporting.
Feasibility testing across paths
Each path is tested in parallel on small samples: a pilot backup restore, a pilot database repair, and a pilot remnant and fragment scan. The results give an expected recovery ratio, effort and risk per path, which becomes a tiered, quotable plan.
Execution by business priority
We recover the minimum dataset that core production needs first so the business can run, then fill in historical and archived data. The achieved ratio is reported at checkpoints, and if a path underperforms we change the plan rather than push it through.
Verification and handover
Before handover we verify: sampled bulk file-open checks, database consistency checks with row counts on key business tables, and application-level business sampling. We deliver the data manifest and verification report, and list what is confirmed unrecoverable so re-entry can be planned.
When to use it
- The family is confirmed to have no public decryptor and another path is needed
- Backups exist but the backup server was encrypted, the chain is broken or the catalogue is damaged
- Database files are partly encrypted: the instance will not mount but historical data is still needed
- A Synology or QNAP NAS was encrypted and volume metadata or snapshots are also damaged
- Virtual disk files are corrupted and business data must be extracted from VMDK or VHDX
- Damage control after mistakes: formatting, reinstallation or partial overwriting has already happened
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
Database Encrypted by Ransomware
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.
Oracle Database Encrypted by Ransomware
When Oracle datafiles (.dbf), control files and archived redo logs are encrypted, hospital HIS, large ERP and group finance systems typically go down as a whole. This page covers triage order, the role of control files and archived logs, and when block-level repair or RMAN restore applies.
MySQL / MariaDB Database Encrypted by Ransomware
When MySQL's ibdata1, .ibd and .frm files are encrypted, websites, online stores, OA and other web workloads all go down. Most cases start at a web application flaw or an exposed management panel. This page covers what InnoDB's file layout means for recovery, the value of binlogs, and the correct sequence.
Synology NAS Encrypted by Ransomware
Synology incidents come in two shapes: the NAS itself is compromised (DSM exposed to the internet, accounts brute-forced), or an infected Windows host on the LAN encrypts it over SMB. The handling and recovery paths differ completely. This page explains how to tell them apart and what Btrfs snapshots and Hyper Backup can actually do.
Backups Deleted or Destroyed
Modern ransomware follows a fixed sequence: destroy the backups, then encrypt the data — deleting shadow copies, encrypting repositories, disabling jobs, and exploiting backup software flaws to steal credentials. This page covers what can still be inventoried once backups fail, why replication propagates encrypted files off-site, and what offline and immutable copies are really worth.
Related ransomware families
- 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
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
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.
- Some versions decryptable
Crysis / Dharma
Crysis (CrySiS) and its successor Dharma have been active since 2016, breaking in through brute-forced RDP and spawning many variants including .cezar, .arena, .bip, .combo and .java. Early versions have free decryptors; the .cezar family from 2017 onward does not.
- Some versions decryptable
STOP / Djvu
STOP/Djvu is one of the highest-volume ransomware families worldwide, infecting individuals and micro-businesses mainly through software cracks, activators and game cheats. Extensions are typically four random lowercase letters and the note is _readme.txt. Files encrypted with an offline key can be decrypted free with Emsisoft's tool.
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.
FAQ
Frequently asked questions
If decryption fails, is the data simply gone?
Not necessarily — decryption is only one path. In practice these openings are common:
- backup chains still hold usable restore points and only the index or catalogue is damaged;
- storage-layer or hypervisor snapshots were missed by the attacker;
- database files have only headers and some pages encrypted, allowing file-level repair and data extraction;
- large files retain substantial intact regions because the encryptor skipped them or encrypted intermittently.
Each path has to be tested in practice; the assessment stage gives a quantified expectation.
How far can a damaged database be repaired?
The goal is usually not to mount the damaged instance as-is, but to get the business data out. A typical outcome is: core business tables largely intact, some indexes and statistics needing rebuild, and a small number of recent transactions missing.
How far it goes depends on which pages were encrypted, whether the log files are usable, and whether any historical backup exists for reference. We trial the repair on a copy first and let the measured result decide whether to proceed at full scale.
How is the recovery rate measured, and can it be promised up front?
We do not quote a recovery rate before the survey. Once the assessment is done we give expected ranges by system and data type — for example a core database recoverable to a specific point in time, or a file-server directory recoverable within a stated band — together with the reasoning.
At handover you get a manifest of what was actually recovered plus verification results, itemized by system rather than reduced to a single headline percentage.
We already ran consumer recovery software — does that hurt?
It can. Some tools write scan results back to the source disk, create temporary files or modify partition data, overwriting remnants that were still extractable; disk check and repair commands can also rewrite key structures.
Stop all writes to the source disk and keep it as it is. We image it read-only first, then assess what remnant data is actually still usable.
Updated