Backups & Storage

Ransomware hit your NAS: what to do

A calm, ordered ransomware-recovery runbook for a home NAS or server — isolate before you restore, check whether your backups are clean, recover to wiped hardware from an immutable/offline copy, rotate credentials, and report to IC3.

Problem summary

Files renamed with a new extension and a ransom note mean the instinct to reboot, reconnect, and restore over the live data is exactly wrong — it can trigger destructive payloads, destroy evidence, re-spread, and overwrite your only clean copy. Modern ransomware also dwells for weeks and targets backups and snapshots first, so recent backups may already be poisoned. Work an ordered response instead: isolate, assess scope, recover from a known-clean immutable or offline backup onto wiped hardware, close the entry point, rotate every credential, then report. CISA and the FBI recommend reporting (IC3) and not paying.

Operator snapshotEvidence first

First proof

Isolate the affected device from the network immediately.

Screen to open

Unplug Ethernet and disable Wi-Fi/Bluetooth on the affected NAS/PC; detach backup drives.

Expected signal

The NAS/PC is disconnected (Ethernet unplugged, Wi-Fi off) so it can't spread or phone home.

Stop boundary

Stop here and get professional help if business/regulated data is involved.

Layer path

1Ransomware recovery is an ordered incident response, not an ad-hoc fix: the wrong instinct (reboot, reconnect, restore over the live data) can trigger destructive payloads, destroy evidence, re-spread, and overwrite the only clean copy.

2Modern strains dwell — gaining access weeks before triggering — and target backups, snapshots, and shadow copies first, so the most recent restore points may already be poisoned.

3CISA frames the order as contain and eradicate before you recover, and to report (IC3) rather than pay; NIST SP 800-184 splits recovery into a tactical phase (restore from a clean point) and a strategic phase (harden so it can't recur).

4The recoverable case depends entirely on having a restore point the attacker couldn't reach — an immutable (object-locked) copy still in its retention window, or a drive that was physically offline.

Runbook

Step-by-step runbook

Start here. Do each check in order, compare it to the expected result, and stop when the evidence explains the failure or the safe stop point applies.

Contain

Check: Isolate the affected device from the network and detach backups/sync.

Expected result: The infection can't spread or reach more copies.

If not: If multiple devices are hit, isolate each before proceeding.

Safe stop: Stop here and get professional help if business/regulated data is involved.

Assess + identify

Check: Map what's affected and identify the strain and likely entry vector.

Expected result: You know the scope and how it got in.

If not: Restoring before this risks missing an infected host or open door.

Find a clean restore point

Check: Locate an immutable/object-locked or offline copy predating the infection.

Expected result: A trustworthy restore point exists.

If not: If none exists, check No More Ransom; otherwise accept the loss.

Verify it clean

Check: Mount read-only on a clean machine; integrity-check and malware-scan it.

Expected result: The copy is proven clean and openable.

If not: Step back to an older copy if it fails.

Recover to clean hardware

Check: Close the entry vector, rebuild/wipe the target, then restore the verified copy.

Expected result: Service is restored on a clean system that can't be re-encrypted.

If not: Don't reconnect until the vector is closed.

Rotate credentials + report

Check: Reset all passwords/keys/2FA across affected systems and accounts; report to IC3.

Expected result: Stolen credentials no longer grant re-entry; the incident is reported.

If not: Attackers retain credentials — skipping this invites re-entry.

Harden (strategic recovery)

Check: Add an immutable/offline backup tier, separate backup credentials, and document lessons.

Expected result: The same attack can't wipe every copy next time.

If not: If you had no offline/immutable copy, that's the top fix.

Decision tree

If: Every backup copy was online and writable

Then: All copies may be encrypted; recovery options are narrow.

Action: Check for any offline/immutable copy or a free decryptor (No More Ransom); else accept the loss and rebuild.

Safe stop: Stop overwriting anything; preserve the encrypted data in case a decryptor appears.

If: An immutable/offline copy predates the infection

Then: You have a trustworthy restore point.

Action: Verify it clean, then restore to wiped hardware after closing the entry point.

If: You don't know how the attacker got in

Then: Restoring now risks immediate re-infection.

Action: Identify and close the entry vector (exposed service, stolen credential) before reconnecting.

Safe stop: Don't reconnect the restored system to the network until the vector is closed.

If: Tempted to pay the ransom

Then: Payment doesn't guarantee recovery and funds more attacks.

Action: Report to IC3 (ic3.gov); check No More Ransom; engage professional help for serious cases.

If: Recovery succeeded

Then: Tactical recovery is done; the system is still as weak as before.

Action: Do the strategic phase: rotate all credentials, harden, add an immutable/offline backup, document lessons.

Evidence

Evidence table

Symptom	Evidence to collect	Likely layer	Next action
Files renamed with a new extension + ransom note	The strain name from the note / file extension	Active ransomware encryption	Isolate; look up the strain (No More Ransom) for a possible decryptor.
Snapshots/backups missing or also encrypted	Which copies were online/writable vs immutable/offline	Attacker reached the backups first	Use an immutable/offline copy; treat online copies as suspect.
Encryption reappears after restoring	Whether the entry vector was closed and the target was clean	Restored onto a compromised system / open vector	Recover to wiped hardware; close the entry point first.
Unsure which restore point is safe	Backup timestamps vs suspected infection date	Dwell-window uncertainty	Pick a copy predating the dwell window; verify it clean.
Same incident recurs later	Whether credentials were rotated and a vector closed	Incomplete eradication / unchanged credentials	Rotate all credentials; close the vector; add immutable/offline backup.

Reference

Commands and settings paths

Isolate the device

Unplug Ethernet and disable Wi-Fi/Bluetooth on the affected NAS/PC; detach backup drives.

Where: At the affected device

Expected: The device is fully off the network with backups detached.

Failure means: Staying connected lets it spread and reach backups.

Safe next step: Don't wipe or restore over it yet — assess first.

Verify a candidate backup is clean

Mount the immutable/offline copy read-only on a clean machine; run an integrity check (e.g. restic check) and a malware scan.

Where: On a separate, known-clean machine

Expected: The copy passes integrity + malware scan and sample files open.

Failure means: A failing scan/integrity check means that copy is poisoned.

Safe next step: Choose an older, verified-clean restore point instead.

Look up the strain / report

Check nomoreransom.org for a free decryptor; report to the FBI IC3 at ic3.gov.

Where: From a clean device

Expected: You know whether a decryptor exists and have filed a report.

Failure means: No decryptor means restore-from-clean-backup is the path.

Safe next step: Do not pay; reporting is recommended by CISA/FBI.

Hardware boundary

Hardware and platform boundary

Change only when

Add an immutable (object-locked) cloud copy and/or an offline rotated drive now — before an incident — so a future attack can't reach every backup; it's the single change that most determines whether you recover.

Evidence that matters

At least one immutable or offline backup predating any infection, separate backup credentials, a closed entry vector, and rotated credentials after recovery.

Evidence that does not matter

Which antivirus you run — recovery hinges on a clean, unreachable backup, not on detection after the fact.

Avoid

Restoring over the live system, reconnecting before closing the entry vector, trusting an online/writable backup unverified, or paying the ransom.

Related tool/checklist

Use the linked tool when you need a guided plan from your exact symptoms instead of a static checklist.

Backup plan builder

Last reviewed

2026-06-03 · Reviewed by HomeTechOps. Built from 2026-06 research verified against CISA #StopRansomware (contain/eradicate before recovery; report to IC3, don't pay), NIST SP 800-184 (tactical + strategic recovery), and restic's integrity-check docs. Scoped to home-operator recovery — explicitly defers business/regulated cases to professionals. The operator differentiators are isolate-before-restore, verify-the-backup-is-clean, recover-to-clean-hardware, and the immutable/offline copy being the deciding factor.

Sources/assumptions

General home-operator guidance for recovering a personal NAS/home server, not enterprise incident response, legal advice, or a ransom-negotiation service — engage professionals if business, regulated, or third-party data is involved.
Recovery order follows CISA #StopRansomware (contain/eradicate before recovery; report, don't pay) and NIST SP 800-184 (tactical then strategic recovery); restore points are assumed to include an immutable or offline copy.
Assumes you have at least one backup outside the affected system; if every copy was online and writable, recovery options narrow sharply — that gap is the lesson for next time.

Source-backed checks

HomeTechOps turns official docs and conservative safety rules into a shorter runbook. These links are the source trail for the page direction.

CISA: I've Been Hit By Ransomware!Used for the home/SMB response flow — work through detection → containment → eradication before restoring, and report rather than pay.CISA: #StopRansomware Guide and resourcesUsed for the response checklist (detection/analysis, reporting, containment/eradication, recovery) and reporting to IC3 (ic3.gov).NIST SP 800-184: Guide for Cybersecurity Event RecoveryUsed as the canonical framework behind safe-troubleshooting: tactical/strategic planning, playbook development, testing, continuous improvement — recovery starts with preparation, not the incident.restic docs: Checking integrity and consistencyUsed for restic check / --read-data / --read-data-subset as the repository-integrity and corruption-detection mechanism.

Diagnostic rule

1. Check the simplest signal first.
2. Change one thing at a time.
3. Avoid unsafe electrical or data-loss steps.
4. Stop when the evidence says the risk moved.

FAQ

Should I just restore my backup over the encrypted files?

No — not yet, and not over the live system. First isolate the affected machine from the network so it can't spread or phone home, then work out the scope and find a restore point you can trust. Restoring onto the still-compromised box (or before you've closed the way in) often just gets re-encrypted. Recover to wiped or new hardware from a known-clean copy. CISA's guidance is to move through containment and eradication before recovery — see CISA's 'I've Been Hit' flow.

How do I know my backup isn't also encrypted?

Assume the most recent backups might be inside the attacker's dwell window — 2025-2026 ransomware commonly compromises sources weeks before triggering and deletes or encrypts snapshots and backups first. Check an immutable (object-locked) or offline copy whose retention window predates the infection, mount it read-only on a clean machine, scan it, and verify a few real files open before trusting it. An immutable snapshot still inside its protection period, or a drive that was unplugged, is your best candidate. Run your backup tool's integrity check (e.g. restic check) on the copy you intend to use.

Should I pay the ransom?

CISA and the FBI recommend not paying — payment doesn't guarantee you get your data back and it funds more attacks — and instead reporting the incident to the FBI's IC3 (ic3.gov). Check the No More Ransom project for a free decryptor for the identified strain before assuming the data is lost. This is general guidance, not legal advice; if business, regulated, or other people's data is involved, get professional incident-response help.