Skip to main content

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

SheMo Noransom舍末无勒

Scenario solution

Synology NAS Encrypted by Ransomware

  • Synology DSM
  • Btrfs 存储池
  • Snapshot Replication
  • Hyper Backup
  • Synology Drive
  • QuickConnect
  • SMB / AFP 共享

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.

Typical symptoms

  • Files across shared folders carry appended extensions with ransom notes at each directory level, yet DSM itself still logs in normally — typically LAN-side SMB spread
  • The DSM login page has been replaced or shows unusual messages, the SSH port is unexpectedly open, or administrator accounts have been created or renamed — the NAS itself is compromised
  • The snapshot list has been emptied or has far fewer entries than expected, and Snapshot Replication tasks are disabled
  • Hyper Backup jobs fail, the backup destination is unreachable, or backup versions have been deleted
  • DSM Log Center shows large volumes of failed logons from overseas IPs, or successful logons outside working hours
  • Storage utilisation spikes abnormally as encrypted copies are written, and disk IO is saturated for long periods

Business risk & common mistakes

Synology is widely deployed in Chinese SMEs and in design, media and medical-imaging teams, often filling four roles at once: file sharing, VM storage, surveillance recording and backup target. One encrypted NAS can therefore take production data and backup data out at the same moment.

Distinguish the two shapes first, because risk and handling differ entirely:

Shape 1: LAN-side SMB spread. The most common. An infected Windows endpoint or server has the NAS share mounted, and the encryptor works outward along its write permissions, file by file. The NAS operating system itself is not compromised, so DSM, snapshots and Hyper Backup configuration are usually intact — in these cases Btrfs snapshots frequently restore the data directly, making this the most tractable variant.

Shape 2: the NAS itself is compromised. This typically follows DSM or SSH being exposed to the internet with weak credentials. Synology publicly stated in August 2021 that its devices were under large-scale brute-force attack from a botnet driven chiefly by the StealthWorker malware family, and that once administrative credentials were guessed, attackers installed malicious payloads which could include ransomware; the same statement noted no indication that any software vulnerability was exploited. Historically, NAS-focused families such as eCh0raix have also affected Synology alongside QNAP devices. Once an attacker holds administrator rights they delete snapshots and stop backup jobs before encrypting, and recovery becomes markedly harder.

One misconception is worth correcting: public sources show DeadBolt ransomware targeted QNAP, ASUSTOR and TerraMaster devices, with no documented large-scale campaign against Synology. If your Synology shows DeadBolt-style login-page hijacking, verify the device model and family attribution carefully rather than hunting for a decryptor under the wrong name.

Common mistakes:

  • Resetting the NAS, rebuilding the storage pool, or reinitialising disks. One action erases every recovery option — the most fatal error in this scenario.
  • Pulling drives, changing their order, rebuilding the RAID, or scanning Synology disks with PC recovery software and writing to them. Synology layers Linux mdadm, LVM and Btrfs/ext4; careless handling destroys array metadata.
  • Deleting encrypted files or emptying the recycle bin to free space.
  • Restoring shares and letting endpoints reconnect before the source is eradicated.
  • "Fixing" it by upgrading DSM or updating packages, which generates heavy writes and can overwrite evidence.

We do not recommend paying, and we do not negotiate on your behalf.

Our response plan

  1. Cut access and determine which shape it is

    Cut both external and internal access to the NAS — unplugging the network cable is preferable to powering off — and do not reset, do not upgrade DSM, do not touch the disks. Then determine the shape: review the DSM administrator account list and creation times, whether SSH or Telnet has been enabled, external access and port-forwarding configuration, and Log Center logon records plus QuickConnect usage. If DSM accounts and logs look normal and only files inside shared folders are encrypted, it is almost certainly LAN-side SMB spread — at which point attention shifts immediately to hunting the infected endpoint.

  2. Inventory snapshots and backup resources

    This is the decisive step in Synology cases. Confirm item by item: whether Btrfs snapshots exist (snapshots created by Snapshot Replication are read-only, and from DSM 7.2 immutable snapshots are supported, which even an administrator cannot delete within the retention period); whether Hyper Backup versions are usable; whether snapshots replicated to a second Synology off-site survived; and whether external drives or cloud backups are intact. Distinguish "snapshots deleted" from "the snapshot UI will not open" — the latter does not necessarily mean the underlying data is gone.

  3. Identify the family and assess recoverability

    Identify the family from extensions and ransom notes. In LAN-spread cases the family is usually a Windows one — Phobos, Makop, LockBit and the Crysis/Dharma lineage are common — with the same encryption characteristics as a file-server incident, so large files may be only partly encrypted. Where the NAS itself was compromised, check whether a Linux family historically aimed at NAS devices is involved. On that basis, assess three paths — snapshot rollback, backup restore, and repair or carving of encrypted and deleted files — and set expectations per shared folder.

  4. Recover: snapshots first, then backups, then repair

    Work from lowest cost upward. Where usable snapshots exist, rolling back is the fastest path — but confirm the snapshot predates the start of encryption, and image the current state before rolling back. Without snapshots, restore from Hyper Backup or an off-site copy. Where neither is available, take a read-only block-level image of the storage pool and perform encrypted-file repair and carving on the image — never directly on the NAS disks. Afterwards, open samples to verify the files are genuinely usable.

  5. Eradicate on the LAN, harden the NAS, rebuild backups

    In LAN-spread cases, recovering without eradicating the source achieves nothing: sweep the estate for infected hosts, remove payloads and persistence, and reset every credential. On the NAS side: remove DSM exposure to the internet and unnecessary port forwards, disable the default admin account, enforce strong passwords with two-factor authentication, enable auto-block and account protection, minimise share permissions, and keep DSM and packages updated. Rebuild backups: enable read-only or immutable snapshots with a sensible retention period, keep the Hyper Backup destination off the NAS itself, and retain one offline copy.

Recovery paths

The good news with Synology: if snapshots or Hyper Backup survived, recovery is usually fast and complete. The bad news: once NAS administrative access is compromised, those are the first things an attacker removes.

Path 1: Btrfs snapshot rollback. The first choice. Synology's Snapshot Replication builds on Btrfs copy-on-write, and its snapshots are read-only — ordinary SMB-based encryption cannot modify or delete them, which is exactly why snapshots save LAN-spread cases. From DSM 7.2 Synology also offers immutable snapshots with WORM retention, which cannot be deleted within the retention period even by a compromised administrator account, alongside WriteOnce shared folders. Where these are enabled, recovery is usually a matter of picking a pre-encryption point and rolling back.

Path 2: Hyper Backup and off-site copies. Hyper Backup keeps multiple versions and can restore a chosen one. What matters is where the destination sits: a destination on another share of the same NAS, or on any writable network location, carries real risk; a destination on a second Synology, an external drive that is detached after use, or cloud storage is worth far more. Snapshots replicated to an off-site Synology serve equally well as a recovery source.

Path 3: encrypted-file and deleted-file recovery. Where snapshots and backups are both unavailable, take a block-level image of the storage pool and analyse the copy. Possible gains include partial-encryption repair on large files, unoverwritten fragments of originals left by the encryptor's write-new-then-delete-old pattern, and Btrfs data extents not yet reclaimed. This path depends on there having been no heavy writing after the incident, which is why taking the NAS out of service immediately matters so much.

Path 4: distributed copies. Check Synology Drive client sync folders and version history on staff computers, caches on machines with mapped drives, and any other backup chain such as a second backup product's jobs.

On public decryptors: identify the family accurately first. Note that public sources show DeadBolt targeted QNAP, ASUSTOR and TerraMaster rather than Synology — with the wrong family attribution, any tool you find is irrelevant.

Stated plainly: deleted snapshots, an encrypted backup destination, and a NAS left running and writing for a long time after the incident together leave very little room. We do not promise "100% recovery", we do not pay ransoms, and we do not negotiate.

Common ransomware families

Hardening recommendations

  • Do not expose the DSM interface to the internet. Remove router port forwards and UPnP auto-opening, and use a VPN for remote access; where external access is unavoidable, at minimum change default ports, enforce HTTPS, restrict sources and enable auto-block.
  • Account governance is the first gate. Disable the default admin account, give every administrator a strong password with two-factor authentication, enable account protection and adaptive MFA, and review the user list and logon records regularly. Synology has publicly described large-scale botnet brute forcing of its devices that worked by guessing administrative credentials.
  • Enable snapshots, and prefer immutable ones. Configure Snapshot Replication on Btrfs volumes with a retention policy matched to the business; from DSM 7.2 enable immutable snapshots with WORM retention so that even a compromised administrator account cannot delete them, and consider WriteOnce shared folders for archive directories.
  • Keep the Hyper Backup destination off the NAS. Back up to a second Synology (off-site is better), an external drive that is detached afterwards, or cloud storage, retaining multiple versions. Do not write backups to another share on the same NAS.
  • Minimise share permissions. Assign by department and project, keep archive directories read-only, and break up large everyone-writable shares — this directly shrinks the reach of any single encryption run.
  • Turn off services you do not need. Enable SSH, Telnet, FTP and AFP only on demand, and disable QuickConnect and external access when unused.
  • Keep DSM and packages updated, and let Security Advisor scan configuration and weak passwords on a schedule.
  • Manage LAN endpoints too. Most Synology encryption originates from one infected Windows host inside the network, so endpoint EDR, patching and least privilege are part of the NAS's defences.

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.

+86 15639272850See contact details

Related industries

FAQ

Frequently asked questions

  • Our Synology snapshots survived — can we just roll back?

    Usually yes, subject to two checks. First, the snapshot must predate the start of encryption, or you will roll back to already-encrypted files; establish the start time from logs and file modification times first. Second, preserve the current state before rolling back with an image or an additional snapshot, so you are not left without options if the snapshot turns out to be incomplete. Also confirm the infected LAN endpoint is isolated — otherwise the restored files will simply be encrypted again.

  • How do we tell whether the NAS was hacked or a PC encrypted the share?

    Look at three things. DSM itself: does it log in normally, have administrator accounts been added or renamed, has SSH or Telnet been unexpectedly enabled, has configuration been altered. Encryption scope: if only user files inside shared folders are encrypted while the system partition, packages and DSM configuration are intact, it is almost certainly LAN-side SMB spread; if the DSM interface itself is replaced or system-layer files are encrypted, the NAS was compromised directly. Logs: DSM Log Center logon and file-operation records show which account and which host's SMB session performed the encrypting writes.

  • Was our Hyper Backup backup encrypted too?

    It depends where the destination is. A destination on another share of the same NAS, or any network location writable from a production host, has a meaningful chance of being encrypted too; a destination on a second Synology, an external drive detached after each run, or cloud storage is very likely intact. Check by inspecting the job's destination path and the backup files' modification times and entropy. This is also the key remediation point: the backup destination must not be freely writable from production.

  • Can we pull the drives and recover them on a PC?

    Not on your own. Synology layers Linux mdadm software RAID, LVM and Btrfs or ext4, which Windows cannot read directly. Pulling drives, changing slot order, or scanning and writing to them with generic recovery software on a PC easily destroys array metadata and turns a recoverable case into an unrecoverable one. Where low-level work is genuinely needed, the correct approach is to record the original slot order and take read-only block-level images, then reassemble the array and analyse on the copies. This is work for a team with NAS internals experience.

  • I read that Synology was hit by DeadBolt — is that true?

    Treat such claims carefully. Public sources show DeadBolt targeted QNAP, ASUSTOR and TerraMaster devices, with its signature behaviour of hijacking the device login page to display the ransom message; there is no public evidence of a large-scale DeadBolt campaign against Synology. What has genuinely affected Synology includes SynoLocker in 2014 and eCh0raix, which hit both Synology and QNAP devices. Misattributing the family leads directly to the wrong decryptor and the wrong recovery path, so we always establish attribution from samples, extensions and ransom notes rather than repeating what circulates online.

Updated