Data Recovery Case File · NAS & Network Storage · Look for What It Missed
Hostile Encryption Targets Shares, and What Survives Is What It Could Not Reach
This business enquiry names its problem precisely, which is rare and useful. A network storage unit infected by a known ransomware family, with a quote sought for recovery. The encrypted files themselves cannot be reversed — that is the honest starting point — but such attacks reach what is mounted and visible, and a unit of this kind holds several things that frequently are not.
| Media | Multi-bay network storage unit compromised by ransomware — share content encrypted; unit otherwise operational |
| Reported situation | Business network storage unit infected by a known ransomware family · share content encrypted · unit remaining operational · recovery quotation sought · scope of surviving content not yet established |
| Fault class | Hostile encryption of accessible shares — encrypted content irreversible without the key; snapshots, versioning and unmounted volumes to be assessed as surviving sources |
| Equipment used | Surviving sources enumerated before any recovery scope was quoted · unit isolated from the network and no update or repair permitted · member drives removed and imaged individually write-blocked · array assembled offline and snapshot volumes examined for pre-incident state · deleted originals carved from unallocated space where encryption wrote to new locations |
The decode: what such an attack reaches, and the four places to look
What the encrypted files themselves are worth pursuing: nothing, and it should be said first. Content encrypted with a key held by the attacker cannot be returned by any technical means, and anyone suggesting otherwise is describing something that does not exist.
Why that is not the end of the case: the attack reaches what it can address. It encrypts the shares it finds mounted and writable, and a network unit holds material outside that.
The first place to look — snapshots. Units of this kind can retain point-in-time copies of shares, stored outside the share's own filesystem. Snapshots taken before the incident hold the original files and are frequently untouched, because reaching them requires unit-level access rather than share access.
Why they are so often overlooked: people do not know they are enabled. Snapshot retention is commonly on by default and never examined until something like this, so the first question is whether any exist.
The second — the unit's own recycling or version retention. Shares configured to retain deleted items hold copies elsewhere. Encryption that writes new files and deletes originals may have deposited those originals exactly there.
The third, and it is where recovery work genuinely helps: unallocated space. Where the attack wrote encrypted copies to new locations and deleted the originals, the originals persist unreferenced until overwritten — recoverable by carving from an offline assembly of the array.
Why that route is time-critical: the unit is still running. Every hour of continued operation risks writing over exactly that space, which makes isolating and powering down the most valuable immediate action.
The fourth — anything that was not mounted. Volumes offline at the time, drives not attached, and backups on media disconnected from the network are all outside the attack's reach. An offline copy is the one thing this class of attack cannot touch.
Why the unit must not be updated or repaired: firmware updates and repair routines write extensively. Both consume the unallocated space that holds the surviving originals, and updating is a common first instinct.
Why paying should be discussed with someone other than a recovery laboratory: it is a business and legal decision rather than a technical one. What is technical is that the surviving-copy routes cost nothing to investigate and should be exhausted first.
On the bench
Surviving sources were enumerated before any recovery scope was quoted — content encrypted with an attacker-held key being irreversible, while such attacks reach only shares that are mounted and writable. Snapshots stored outside the share filesystem, share-level retention of deleted items, unreferenced originals in unallocated space, and volumes offline at the time all sit beyond that reach. The unit was isolated and no update or repair permitted; the array was assembled offline from individually imaged members.
The outcome
Surviving sources enumerated before any scope was quoted, the unit isolated and powered down, and originals carved from unallocated space in an offline assembly. Free assessment, one fixed written figure including VAT, charged per drive, with 50% of parts and labour upfront where a drive has to be opened. The decode: the encrypted files cannot be reversed and that is not the whole picture. Such attacks reach what is mounted — so snapshots, retained deletions, unallocated space and anything offline are where the case actually is.
A network unit hit by ransomware
Isolate it from the network and power it down now, and do not update the firmware or run any repair — both write extensively and consume the unallocated space holding recoverable originals. Then check four places the attack probably didn't reach: snapshots, which are stored outside the share's filesystem and are often enabled without anyone knowing; share-level retention of deleted items; unallocated space, where originals persist if the attack wrote new files and deleted the old; and anything that was offline at the time.
Isolate it and power it down — call Cambridge Data Recovery on 01223 655015; surviving sources enumerated before any scope is quoted, members imaged individually, originals carved from an offline assembly.
Request a quote online →
Our case files are drawn from genuine enquiries received by our laboratory over the past ten years, anonymised to protect client confidentiality. Each one describes the diagnostic and recovery procedure our engineers apply to that fault, using the equipment listed.