NAS suspected of ransomware? A 6-phase incident response playbook: isolate, preserve evidence, recover safely

Files on the NAS are being encrypted en masse, a ransom note has appeared, or the device is behaving strangely — and the common reflex is to "just reinstall it quickly". According to a technical write-up circulating in Vietnam's IT community, that is precisely what you should avoid: responding to ransomware on a NAS is a disciplined 6-phase process — isolate, preserve evidence, determine scope, contain the root cause, recover, and learn — where one wrong move can destroy data permanently or let the malware walk back in.

Quick answer

• The first thing to do when a NAS is suspected of ransomware: disconnect the NAS from the network and block Internet access to it, pause every sync task — and absolutely do not format drives, reset the operating system, or delete encrypted files.
• The response has 6 phases: (1) isolate the incident, (2) preserve evidence, (3) determine the scope of impact, (4) contain and eliminate the root cause, (5) recover from clean backups, (6) lessons learned and defensive hardening.
• Three things to check immediately during scoping: are snapshots still usable, has Hyper Backup been affected, and are there any suspicious admin accounts?
• Recover only when the cause has been isolated and the target environment is clean; prefer backups taken before the intrusion time.
• Do not pay the ransom: payment does not guarantee a working decryption tool, and it creates additional risk for the victim.

Why not just "reinstall it quickly"?

Ransomware incident response pursues three goals at once: stop the damage from spreading, preserve the best possible chance of recovering data, and find the entry path so the malware cannot return. Formatting drives or reinstalling the OS the moment an incident is discovered breaks all three: it destroys the evidence and logs needed for investigation, can wipe out the snapshots or clues recovery depends on, and — if the entry point is another workstation on the network, a very common scenario — the freshly rebuilt system simply gets encrypted again.

In other words, in a ransomware incident, an IT practitioner needs more than the skill to fix a system; they must know how to preserve evidence, control damage and restore business operations — and that order of priorities largely decides the final outcome.

The 6 phases at a glance

Phase	Core objective	Typical actions
1. Isolate the incident	Stop the spread immediately	Unplug the NAS network cable, block Internet access, pause sync, isolate related machines
2. Preserve evidence	Keep the scene intact for investigation	Record the time, save the ransom note, preserve NAS/firewall/VPN logs
3. Determine scope	Know exactly what has been affected	Check shared folders, snapshots, Hyper Backup, admin accounts, SMB-connected machines
4. Contain & eliminate	Close the entry path	Find the entry point in logs, patch DSM/apps, change passwords from a clean device
5. Recover	Bring data and services back safely	Restore pre-intrusion backups, verify, monitor after recovery
6. Lessons learned	Prevent a repeat	Reassess backup design, permissions, patch process, disaster-recovery drills

Phase 1: Isolation — what to do in the first minutes

This phase is a race against time, because the ransomware may still be encrypting and spreading to other machines through shared folders:

• Disconnect the suspected NAS from the network and block all Internet access to the device.
• Pause sync tasks that could propagate encrypted data elsewhere (syncing to the cloud or to a secondary NAS can overwrite the last good copies).
• Isolate any workstation or server showing related signs — the initially infected machine is usually a PC on the network, not the NAS itself.
• Do not rush to format drives, reset DSM or delete encrypted files. Every destructive action waits until evidence is preserved and recovery options are assessed.

Phase 2: Preserve evidence — what must be kept?

With the system isolated, priorities shift to recording the scene before anything changes further:

• Record the time of detection and the sequence of observations.
• Save the ransom note, plus the abnormal filenames and extensions that appeared after encryption — clues that identify the ransomware variant.
• Preserve logs from the NAS, firewall, VPN and related servers before they roll over with age.
• Collect evidence following incident-response procedure, changing the system's state as little as possible during collection.

Phase 3: Determine scope — what must be checked?

Before treating anything, you need a clear damage picture. For NAS systems (especially Synology), the checklist is:

• Which shared folders are affected, and how deep does the encryption go?
• Are snapshots still usable? Intact snapshots are usually the fastest recovery path.
• Has Hyper Backup been affected, and what is the most recent clean backup?
• Are there abnormal admin accounts — unfamiliar accounts, escalated privileges, sessions from strange addresses?
• Do servers and workstations connected over SMB to the NAS show signs of encrypted data?

Phase 4: Containment and root cause — how?

Only with the scope known does eradication begin:

• Identify the entry path from the preserved logs and evidence: a service exposed to the Internet, a leaked account, an unpatched vulnerability, or a workstation infected first.
• Check patch status of DSM, PHP and related applications on the NAS.
• Revoke login sessions, change all passwords and lock risky access — performed from a clean device, never from a machine under suspicion.
• Rebuild the system from a trusted source if you cannot confirm the malware is fully removed; this is safer than a gut-feeling "the scan looks clean".

Phase 5: Recovery — when is it safe to restore?

Recovery is the phase under the most pressure ("the boss needs the data now") and the one needing the most discipline:

• Recover only after the cause has been isolated and the target environment is clean — restoring into a still-infected environment just gets the data encrypted a second time.
• Prefer backups from before the intrusion, even if that means accepting the loss of data created afterwards.
• Verify restored files and application data before reopening access to users.
• Monitor the system after it returns to production to catch any sign of reinfection early.

Phase 6: Lessons learned — how to prevent a repeat

An incident is not over when the data runs again; it is over when the defenses are fixed according to the lesson just paid for:

• Reassess the backup design: is there a copy separated from the network (offline, or immutable so it cannot be modified/deleted), or are all copies within the ransomware's reach?
• Review permissions and Internet exposure: is the NAS directly exposed to the Internet, who holds admin rights, are two-factor authentication and automatic IP blocking for failed logins enabled?
• Complete the patching process for DSM and application packages.
• Drill disaster recovery periodically — a backup that has never been test-restored cannot be considered trustworthy.

Should you pay the ransom?

The original write-up is explicit: do not pay the ransom expecting a guaranteed return of your data. Payment does not guarantee a working decryptor — tools may be broken, decryption partial, or the attackers may simply vanish after being paid — and it can create further risk, as victims get marked as "willing to pay" and targeted again. The reliable recovery path remains snapshots and clean backups prepared in advance.

Frequently asked questions

Files are being encrypted en masse — what is the very first action?

Disconnect the NAS from the network immediately (pull the cable or disable the switch port), block Internet access to it, and stop sync tasks. This halts the running encryption and stops damaged data from spreading to your copies — everything else comes after.

Does formatting the drives and reinstalling DSM remove ransomware?

It might clean that NAS, but it is a risky move: you lose investigation evidence, may lose the snapshot-based recovery chance too, and if the entry point is another workstation or a leaked account, the rebuilt system gets attacked again. Rebuild only after the entry path has been identified and closed.

Can NAS snapshots save the data?

Usually yes — snapshots are one of the fastest recovery paths, provided they are intact and were taken before the encryption began. But snapshots living on the same device can be deleted if the attacker gains admin rights; that is why a separate backup (off-device, offline or immutable) remains mandatory.

Why must passwords be changed from a clean device?

Because if you work from the very machine under suspicion, the new credentials can be captured immediately by leftover malware (keyloggers, session theft). Password changes, session revocation and locking suspicious access must all happen from a machine that is certainly clean.

Should a NAS be directly accessible from the Internet?

Not unless truly necessary. An Internet-exposed NAS is a large attack surface (port scanning, DSM vulnerability probing, login brute force). The safer model is remote access through a VPN, IP allow-listing, two-factor authentication, automatic blocking after a few failed logins, and regular DSM updates.

Conclusion

The 6-phase process — isolate, preserve evidence, determine scope, contain the cause, recover, learn — is a standard response framework that anyone administering a NAS for a home or a business should print out and keep ready, instead of improvising when an incident strikes. The difference between a controlled incident and a data disaster rarely lies in tools; it lies in the order of operations during the first hours: do not destroy the scene, do not rush the reinstall, and do not restore into an environment that is not yet clean.

Source: a technical write-up by Dung Nguyen in the Community of Digitals Arch Facebook group (30 Oct 2026), edited and structured by Wotech Electronics.