Scenario solution
Backups Deleted or Destroyed
- Veeam Backup & Replication
- Windows Server Backup
- Commvault / NetBackup
- NAS 备份目标
- 磁带库
- 卷影副本 VSS
- 云对象存储
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.
Typical symptoms
- Every job in the backup console fails, and the repository shows as inaccessible or reports abnormal capacity
- Backup files on platforms such as Veeam (.vbk / .vib / .vbm) carry appended extensions or have been deleted, leaving an empty restore point list
- Previous Versions is empty, shadow copies have been cleared, and vssadmin delete shadows activity appears in the logs
- The backup directory on a NAS now contains encrypted files, and the off-site replication job has dutifully synchronised them
- The backup server itself has been encrypted or logged into, with backup administrator accounts disabled, password-changed or newly created
- Tape jobs have been cancelled, retention shortened, or versioning and lock policies changed on an object storage bucket
Business risk & common mistakes
"We have backups" and "we can recover" are two different statements. In real incident response, the reasons backups fail cluster tightly into a handful of categories.
First: the backup target sat inside the attacker's permission scope. Backups written to an SMB share, a NAS share, or another partition on the same host that the production server could write to. As the encryptor enumerates network shares it follows write permissions outward, and the backup files fall squarely inside. This is far and away the most common cause.
Second: backup credentials were stolen. The backup server is domain-joined and runs jobs under a domain administrator account, so a compromised domain controller takes the backup estate with it. Further, public reporting documents ransomware operators exploiting flaws in backup software itself — for example the credential-disclosure vulnerability in Veeam Backup & Replication (CVE-2023-27532), which allowed unauthenticated retrieval of encrypted credentials from the configuration database and their decryption for lateral movement. Backup software is part of the attack surface.
Third: replication carried the encrypted files away. A recurring pain point: the NAS or cloud drive is configured for synchronisation rather than versioned backup, so after encryption the sync job faithfully pushes the encrypted files off-site and overwrites the only good copy. Sync is not backup — without version retention, sync is close to worthless in a ransomware scenario.
Fourth: shadow copies were cleared. Virtually every major family deletes shadow copies, usually before encryption begins, so VSS cannot be relied upon.
Fifth: the backups were never verified. Jobs reported success and the files exist, but no real restore was ever performed — and only when needed does the broken chain, incomplete version set or unreadable data come to light.
A caution: do not delete the encrypted backup files to free space once you discover the failure; they may be header-only encrypted and still repairable. Nor should you reinitialise the repository. We do not recommend paying, and we do not negotiate on your behalf.
Our response plan
Stop all sync and overwrite activity first
The first priority is not recovery but stopping the situation from getting worse. Immediately pause every backup and synchronisation job — NAS sync, cloud drive sync, replication tasks, tape rotation — and disconnect the backup server from the production network, so encrypted files stop propagating to off-site copies and retention policies do not expire the last good version. Preserve the backup server as-is for forensics: no reinstall, no repository reinitialisation.
Inventory every copy that still exists
Inventory by one criterion — whether the attacker could reach it. Cover offline media (tape, periodically detached external drives, archived optical media); immutable storage (object lock / WORM, repositories with immutability enabled); storage and hypervisor snapshots (array snapshots, read-only NAS snapshots, VM snapshots); off-site copies (secondary data centre, cloud, third-party custody); logical copies (database standbys, downstream warehouses, interface landing files); and distributed copies on endpoints and sync services. Many organisations discover at this step that usable resources do exist.
Assess whether damaged backups can be repaired
An encrypted backup file is not automatically worthless. Backup files are typically enormous — tens of gigabytes to several terabytes — and many families encrypt only the header of large files or use intermittent encryption, so the untouched portions may still yield complete backup data blocks. The method is segmented entropy analysis of .vbk, .bak, .tib and similar files; once coverage is established, rebuild the header or extract content directly from the unencrypted segments. Deleted backup files can also be carved while the storage has not been heavily overwritten.
Build a recovery plan from what is usable
Combine the inventory with the recoverability of production data and build a composite plan rather than a single path: restore from offline or immutable copies to an earlier point, close the gap using database logs, downstream systems and interface data, and fill in what the backup did not cover by repairing encrypted files on the production side. Agree priorities and an acceptable data gap with the business, and state explicitly which data will not come back so re-entry can be planned in advance.
Rebuild a ransomware-resistant backup architecture
After recovery, the backup architecture must be rebuilt or the next incident ends the same way. The core principles: the backup target must not be writable from production, the backup estate must not share credentials with production, and at least one copy must be offline or immutable. In practice: take the backup server out of the production domain with its own accounts and MFA; enable immutable backups or object lock; maintain an offline media rotation; patch the backup software itself and restrict access to its management ports; and validate RTO/RPO with real restore drills rather than job success rates.
Recovery paths
Once backups have failed, the work becomes finding copies the attacker could not reach, and extracting as much as possible from the wreckage.
Path 1: genuinely offline copies. Tape, periodically detached external drives, archived optical media, media held in a safe. Their value in ransomware scenarios is badly underrated — they were simply not online when the attack happened, so the attacker could not touch them. Even if the data only runs to last month, it is a certain, usable starting point.
Path 2: immutable backups and object lock. Repositories with immutability flags, cloud buckets with object lock, WORM-retained snapshots — none deletable within the retention period even with compromised administrator credentials. This is the central direction of recent backup architecture work.
Path 3: storage and hypervisor snapshots. Array snapshots, read-only NAS snapshots and VM snapshots generally sit outside the permission scope of the encrypted filesystem, and survive far more often than shadow copies.
Path 4: repairing encrypted backup files. Backup files are large and are often only header- or segment-encrypted. Once entropy analysis establishes coverage, headers can be rebuilt and data blocks extracted from unencrypted regions. The result may be some restore points usable or some VMs or databases extractable rather than an intact chain — but where other paths have failed, that is worth a great deal.
Path 5: carving deleted backup files. Deletion only releases metadata references, so files can be recovered while the storage has not been heavily overwritten. Again, this depends on writes stopping immediately.
Path 6: logical and distributed copies. Physical database standbys, downstream data warehouses, reporting systems, interface reconciliation files, third-party platform data, and version history on endpoints and sync services. None of these is a backup in the traditional sense, yet in practice they frequently do the heavy lifting in restoring critical business data.
Stated plainly: where every copy was online and writable, sync overwrote the off-site version, and the storage continued to be written after the incident, very little room remains. We avoid "100%" and "guaranteed recovery"; the assessment states what can and cannot be retrieved. No ransom payment, no negotiation.
Common ransomware families
- Some versions decryptable
Akira
Akira is a ransomware-as-a-service operation that emerged in March 2023, breaking in through VPNs without MFA and edge-device flaws, then encrypting Windows estates and VMware ESXi clusters under double extortion. CISA's November 2025 advisory update calls it an imminent threat to critical infrastructure.
- No public decryptor
Qilin
Qilin (formerly Agenda) is a Rust-rewritten cross-platform RaaS operation focused on VMware ESXi and Linux estates. It has ranked as the world's most active ransomware group for several consecutive quarters since 2025, with confirmed victims among electronics manufacturers in Taiwan and Hong Kong.
- Some versions decryptable
LockBit
LockBit is one of the largest ransomware-as-a-service operations in the world. Despite the 2024 law-enforcement takedown it returned as LockBit 5.0, with working Windows, Linux and VMware ESXi payloads, and it remains one of the most frequently seen families in China.
- Some versions decryptable
Black Basta
Black Basta was a Conti-derived RaaS operation that emerged in April 2022 and affected more than 500 organisations, known for QakBot delivery and Microsoft Teams IT-impersonation social engineering. It disbanded in February 2025 after its internal chat logs leaked, though its tradecraft carried over to successors such as Cactus.
- No public decryptor
RansomHub
RansomHub launched in February 2024 as a rebrand of Knight/Cyclops and rapidly absorbed affiliates from ALPHV and LockBit with a 90% revenue share, accumulating hundreds of victims within a year. Its infrastructure went offline in early April 2025 and the operation has been dormant since, with affiliates largely migrating to Qilin and DragonForce.
- No public decryptor
Play
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.
Hardening recommendations
- 3-2-1-1 is the floor, not the aspiration. Three copies, two media types, one off-site, and at least one offline or immutable. That final copy is the one that actually helps in a ransomware scenario.
- The backup target must never be writable from production. Do not write backups to an SMB or NAS share the production server can reach; use a dedicated backup host, separate storage, an object-locked cloud bucket, or tape.
- Decouple the backup estate from production. Keep the backup server out of the production domain, with its own local accounts, strong passwords and MFA, and separate backup and production networks. A compromised domain controller must not take the backup estate with it.
- Patch the backup software itself. Public reporting documents ransomware operators exploiting credential-disclosure flaws in backup platforms (such as Veeam's CVE-2023-27532) to obtain environment credentials for lateral movement. Keep management ports closed externally and versions supported.
- Sync is not backup. Cloud drive sync and real-time NAS sync push encrypted files off-site during a ransomware event; use versioned backup with a retention window long enough to matter.
- Verify backups by actually restoring them. Each quarter, fully restore a different data type and record real RTO/RPO, and run periodic consistency checks on backup files rather than watching job success rates.
- Monitor the backup estate for anomalies. Alert on jobs being disabled, retention being shortened, repositories being deleted, restore points disappearing en masse, and unusual backup-account logons — these are often the last warning before encryption begins.
- Keep a cold-start package for critical systems. Store system images, configuration documentation, licences, keys and certificates offline, so recovery is not blocked on rebuilding the environment.
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.
- 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.
- Aftermath
Why do we keep getting hit by ransomware, and how do we stop it for good?
Repeat infections are rarely bad luck; the previous incident was almost always left unfinished. The real entry point was never found or never closed, accounts, scheduled tasks, remote-access tools or web shells left by the attacker are still there, credentials were only partly changed, or systems were restored from backups that already contained the backdoor. Environments that paid, or whose access was resold, also get revisited. The fix follows an order: forensics to find the real entry point, a rebuild-or-clean decision, closing the entry and removing persistence, a full credential reset, then verified hardening and ongoing monitoring.
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.
Logistics and Supply Chain Ransomware Response
Logistics is acutely time-sensitive: when TMS, WMS, dispatch and sorting systems stop, goods pile up in warehouses and on routes immediately, and the effect propagates up and down the supply chain. This page covers the sector's threat profile, a recovery order built around goods movement, and hardening for EDI-interconnected environments.
Related services
Incident Response
Round-the-clock intake: contain first, preserve evidence second, recover third.
Data Recovery
Recovery beyond decryption: backup repair, database repair and remnant extraction.
Attack Forensics & Attribution
Establish the intrusion path, timeline and impact — in a report usable for police reporting and compliance.
Security Hardening
Close the handful of paths attackers actually use: exposure, weak credentials, patches, privilege, backups.
FAQ
Frequently asked questions
Our backup files are encrypted — are they still worth anything?
Very possibly. Backup files are usually enormous, and many families encrypt only the header of large files or work intermittently, so complete backup data blocks often survive in the untouched regions. The approach is segmented entropy analysis to establish coverage, then rebuilding the header or extracting content directly from unencrypted segments. The result may be a few usable restore points, or a handful of extractable VMs and databases, rather than an intact chain — but when every other path has failed, that is frequently decisive. So do not delete encrypted backup files.
We had off-site sync — why are the off-site files encrypted too?
Because sync is not backup. A sync job's purpose is to keep both ends identical: once local files are encrypted, it pushes the "new version" — the encrypted files — off-site and overwrites the good copy. Cloud drive sync, real-time NAS sync and folder mirroring all share this flaw. The fix is versioned backup: retain enough history with a sensible retention window, or move to immutable backups and object lock. This is the central item in rebuilding the backup architecture after recovery.
How were the attackers able to delete our backups?
Usually one or a combination of three causes. Reachable permissions: the backup target was a share the production server could write to, so the encryptor simply followed those permissions. Shared credentials: the backup server was domain-joined and ran jobs as a domain administrator, so a compromised domain controller took the backup estate too. The backup software itself was exploited: public reporting documents ransomware operators using credential-disclosure flaws in backup platforms to extract environment credentials for lateral movement. The three remediations map directly: make the target unwritable from production, give the backup estate its own credentials and network, and keep the backup software patched and supported.
Can we still count on shadow copies?
Not as a primary reliance. Deleting shadow copies is standard behaviour for virtually every major family, usually completed before encryption starts, so an empty Previous Versions list is the norm rather than the exception. Worth noting: the deletion itself is a valuable alerting point — if EDR blocks and alerts at that step, there is often a ten-minute window to intervene. So the right approach is to enable EDR shadow-copy and tamper protection, and to build real recovery capability on offline and immutable copies.
When rebuilding backup architecture, what matters most?
One rule must hold: at least one copy the attacker cannot reach at the moment of the attack. There are several ways to achieve it — offline media (tape, external drives detached after use), immutable storage with object lock or WORM retention, or a backup system with independent credentials outside the production domain. Everything else — multiple versions, off-site copies, encrypted transport, drills — matters too, but if this one does not hold, the rest can fail together in a ransomware scenario. Beyond that, backups must have been validated by a real restore, or they are just an untested assumption.
Updated