Synology NAS still running: C3RB3R/L0CK3D rescue steps

This page does not promise recovery results. Memory acquisition paths for a PVE virtual machine and a physical DSM system differ, so do not mix their commands.

1. Isolate the entry point and keep the management channel

Block the NAS from the internet and from other devices, and check both IPv4 and IPv6. Pause cloud sync and shared-folder sync to keep the damage from spreading further.

For remote operations, keep a trusted console or a restricted SSH channel first. Do not cut the only management entry point just to achieve "complete disconnection", and do not shut down, restart, or pull the power.

2. Verify the process, then pause it

The command below is only for finding clues. deleted and the process name alone cannot prove that a process is the encryption program, so do not pause or terminate processes in bulk by name.

ls -l /proc/*/exe 2>/dev/null | grep deleted

After you confirm the identity of a suspicious process, replace <PID> with the verified numeric process ID. The placeholders below must not be run as-is:

sudo kill -STOP <PID>
grep State /proc/<PID>/status

The main process state should be T. Also check all threads according to the main rescue guide. D means waiting for I/O, so it does not count as a fully paused process.

Stop condition: If you cannot confirm the PID, the state is not as expected, read permission is insufficient, or you cannot keep the management channel, stop. Do not continue, do not switch to kill -9, and hand the task to a trusted administrator.

3. Save memory and program samples first

The target must be independent storage with enough capacity, and it must be a verified mounted device. Do not write large dumps to /tmp, a RAM disk, or the affected data volume, and do not overwrite older collection directories.

The main rescue repository provides collection tools and templates that record process identity, thread state, target device, and verification checks. First read the physical-machine memory acquisition guide (Chinese), and confirm the tool and system conditions before you operate.

Do not run a generic dd directly on /proc/kcore, and do not run swapoff, clear caches, load unverified kernel modules, upgrade, or restart for the purpose of acquisition.

4. Verify a few copies first

Find a few intact originals of the same version on computers, phones, email, or Git clones, and test candidate recovery methods on independent copies. Confirm results with a full SHA-256 or a byte-by-byte comparison, and always keep the original ciphertext.

Recovered data does not mean the original NAS is safe. After business recovery, you still need to rebuild in a clean environment, replace credentials, and deal with the intrusion entry point.

Sources: main rescue repository emergency guide (Chinese), physical-machine supplementary case.