Skip to main content

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

SheMo Noransom舍末无勒

Case study

LockBit encrypts OA and file servers after wiping the backups

The attacker took domain administrator rights, deleted the backups first and then encrypted domain-wide. Recovery was layered across storage snapshots, offline media and remnant data, with a forensic report for the police filing.

Industry
Government and Public Sector Ransomware Response
Family
LockBit
Scenario
Backups Destroyed
Handled
2026-06

This case study is composed from typical scenarios to illustrate our approach and the recovery paths involved. It does not describe a specific customer incident; real cases involving customer data are published only with authorization.

  • 约 92%

    File shares recovered

  • 约 5 天

    OA and document system restored

  • 存储快照 + 离线磁带

    Primary recovery sources

  • 已出具并配合报案

    Forensic report

Incident background

The client is a public-sector organization running OA, document circulation, a portal and several file servers on an internal network, all joined to a single Windows domain. A backup server orchestrated all jobs into network storage, with both the backup service and storage management using domain administrator accounts — the classic "backups in the same domain with the same credentials as production" arrangement.

The intrusion had run for some time before discovery. The attacker entered through a host providing external services, moved laterally across servers using credential-theft tooling, and eventually obtained domain administrator rights. As in many targeted ransomware cases, encryption was not the first step: the attacker cleaned out backup jobs and historical data in the backup storage and deleted shadow copies, and only then deployed the encryptor overnight.

The next working morning the OA login page would not open, documents across several file server shares were encrypted with ransom notes alongside them, and the desktop wallpaper had been replaced. Only when IT tried to restore did they find the backup repository emptied and no recent restore point available. The organization had to report to its supervising authority while responding, and prepare material for a police filing.

What we did

When backups are gone there is no shortcut: every possible data source has to be inventoried and then ranked by feasibility.

  • Containment and scoping. Affected servers were disconnected from the internet, domain controllers isolated, suspicious accounts disabled and all privileged domain credentials rotated, so that recovery could not be re-encrypted mid-flight.
  • Forensics first. Because a police filing and a report to the supervising authority were required, acquisition preceded cleanup: domain controller security logs, backup server operation logs, edge device and VPN logs, plus hashed disk and memory images of key hosts.
  • Source inventory. Item by item: storage-layer snapshots on the network storage (partly retained, untouched by deletions performed at the backup software layer); a set of offline tape media supplied years earlier with the hardware and still in rotation; local caches and offline document copies on end-user machines; and the OA database's log files.
  • Layered recovery. Storage snapshots restored most file server shares; the OA database was rebuilt from partially intact data files plus log replay; offline media filled in historical archives; and remaining documents were re-collected from endpoint caches and mail attachments.
  • Support for the filing. A forensic report with the timeline, entry-point determination, compromised asset inventory and indicators of compromise was delivered and submitted with the organization's police report.

Recovery result

OA and document circulation were running again on the fifth day after response began. File server shares were largely restored from storage snapshots, with a further portion of historical archives coming from offline tape. A small number of files created outside the snapshot window that existed only on the servers were confirmed unrecoverable, and the organization handled those through document re-entry with a documented process note.

The point most worth recording: what actually saved the data was not the backup software but storage-layer snapshots and a set of tapes that had nearly been retired. The attacker deleted what the backup software could see, but the array's snapshot policy was managed independently and happened to sit outside those privileges, while offline tape was immune by virtue of being physically disconnected. Because both paths existed, the organization never had to weigh the ransom question at all.

Remediation followed one principle — backups must assume the production domain is already lost: the backup system now runs outside the production domain with its own credentials; snapshot retention on the network storage was extended and deletion rights restricted; tape rotation was normalized with an added annual restore exercise; privileged domain accounts were separated and given MFA; and bulk file renaming, shadow copy deletion and unexpected backup job termination on key servers were added to alerting.

This is an illustrative case compiled from typical scenarios and anonymized; it does not refer to any specific organization.

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.