Skip to main content

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

SheMo Noransom舍末无勒

Case study

BeijingCrypt encrypts a design firm's Synology drawing library

A design and property development company had its Windows file server encrypted by BeijingCrypt after an RDP brute force, and the shares it mounted carried the damage onto a Synology NAS, leaving cost data, BIM models and CAD drawings with a .beijing extension. Recovery came from Btrfs read-only snapshots, an offline drive and workstation copies, and the tender went in on time.

Industry
Construction and Real Estate Ransomware Response
Family
BeijingCrypt
Scenario
Synology Encrypted
Handled
2026-03

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.

  • 约 97%

    Drawings and cost data recovered

  • 约 36 小时

    Core drawing library usable again

  • 5 个工作日

    Full handover and verification

  • 0

    Ransom paid

Incident background

The client is a mid-sized company doing architectural design alongside some property development. Material for the head-office design centre and two live projects sat on one Synology NAS. A separate Windows file server ran the cost estimating software and its database, mounted the NAS shares on a fixed drive letter, and copied the drawing library to local disk each night as a backup.

So that designers could pull drawings from site and from home, the team had mapped the file server's port 3389 straight to the internet on the edge router, still using an administrator password that had gone unchanged for years. NAS shared folders were set to everyone-read-write for collaboration convenience and mounted across more than ten design workstations.

The incident happened over a weekend in mid-March. The first designer in on Monday found every .dwg, .rvt and cost data file carrying a .beijing extension, with !RECOVER.txt at each directory level giving a primary and a backup mailbox and asking for a machine ID. The database service on the file server had been stopped and the local backup directory was encrypted with everything else. The company was preparing a tender due nine days later.

Before calling us the client had already run a supposed "dedicated .beijing decryptor" downloaded from the internet on one design workstation, with no effect.

What we did

Containment went out the same day: keep both machines powered but off the network, disconnect workstations with the share mounted, and do not reset the NAS or rebuild the storage pool.

  • Evidence and imaging. Read-only images of the file server's system and data disks, plus security logs, port-forwarding configuration and DSM Log Center records. The storage pool was left untouched and all work ran on copies.
  • Family confirmation and recoverability. !RECOVER.txt with a .beijing extension identified BeijingCrypt, distinct from Phobos's info.txt plus info.hta and Makop's readme-warning.txt. The family uses hybrid AES-256 and RSA-2048 encryption with no public free decryptor, so decryption was ruled out. DSM accounts and logon records were clean and SSH was not enabled: an infected host encrypting along mounted shares, not a compromised NAS, with Btrfs read-only snapshots intact.
  • Recovery. The most recent read-only snapshot predated encryption; the current state was imaged, then shares were rolled back in batches. Two shares for new projects had never been added to the snapshot task and were closed from an external drive offline at the time and from workstation copies. The cost database came back from the offline backup with its key tables checked.
  • Hardening in parallel. The public 3389 mapping gave way to VPN with enforced multi-factor authentication; attacker accounts and persistence were removed, passwords reset, share permissions narrowed by project and role, immutable snapshots enabled, and offline backup moved to two rotating drives.
  • Deliverables. An incident report with brute-force source IPs and timeline, a recovery inventory with verification records, a drawing revision checklist, and a hardening sign-off list.

Recovery result

About 97% of the drawing library, BIM models and cost data were recovered. The core library was usable again within roughly 36 hours, design work with the sites returned to normal on the third business day, and batched handover and verification finished within 5 business days. What could not be recovered was a small set of working files from the shares outside the snapshot task, created after the last offline backup; designers and collaborators redrew or re-sent them. The tender documents were recovered in full and submitted on time, no ransom was paid, and there was no contact with the attackers.

Forensics showed days of brute forcing against the internet-mapped 3389 port. After a successful logon on Saturday night the operator disabled security software, created an administrator account and ran the encryptor by hand on the file server, spreading along the NAS shares mounted there and clearing volume shadow copies and the local backup directory. The consecutive failed logons had never been covered by any alert.

BeijingCrypt shows no documented data-theft or leak-site behaviour, and outbound traffic analysis found no sign of bulk exfiltration. Even so, since access to individual files cannot be entirely ruled out, we helped the client brief the partners and project owners involved. Recommendations: bring project-site storage under head-office governance, run a real restore drill each quarter, and close the alert loop on failed logons and bulk file renaming.

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

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.