At 8.15am on a Monday, a Canberra architecture practice found that its shared project folders would not open. File names had changed, a ransom note appeared on several desktops, and the NAS that held current drawings was inaccessible. This ransomware recovery example shows why the first few hours matter more than any single recovery tool.
The business had twelve staff, a mix of Windows workstations, laptops used on site, and a NAS containing active jobs, archived plans, photographs and client correspondence. It also had backups, but no-one yet knew whether they were clean, complete or reachable. The immediate objective was not to get every file back before lunch. It was to stop the encryption spreading, preserve the best recovery options, and restore operations without reintroducing the threat.
The first response: contain, do not experiment
One staff member had already restarted their computer twice, hoping the warning would disappear. That is a common reaction, but it can complicate an investigation and may allow malware to continue running. In this case, the office manager stopped further restarts and disconnected affected devices from the network.
The team’s first actions were straightforward:
- disconnect affected computers, servers and network storage from Wi-Fi and Ethernet where safe to do so
- prevent staff from signing in to shared systems or plugging in external drives
- photograph ransom notes and record the time, affected devices and visible file extensions
- retain the original devices and avoid deleting files, running cleaners or attempting random decryptors
- contact an experienced cyber incident response provider and notify the organisation’s insurer, where relevant.
Containment is not the same as recovery. Its purpose is to reduce further damage while qualified responders identify the ransomware family, likely entry point, affected accounts and systems that may still be at risk. If a server is actively encrypting files, the advice can vary depending on the environment. A business should follow its incident response specialist’s direction rather than taking blanket action that may destroy useful evidence.
The practice also changed passwords from a known-clean device, starting with administrator, email, remote access and cloud accounts. Multi-factor authentication was enabled or reviewed wherever possible. Ransomware operators often steal credentials before they encrypt files, so restoring data without securing identity systems can leave the door open for a second incident.
Ransomware recovery example: assessing what can be restored
By midday, the incident response team had confirmed that the NAS shares and six workstations had been encrypted. The cloud email platform had not been affected, but several staff laptops had synchronised encrypted documents into cloud storage. That did not mean the files were necessarily lost. It meant the team had to identify earlier, unencrypted versions before restoring anything.
A proper recovery assessment separates data into three groups: data that remains clean and available, data that can be restored from a verified copy, and data that may need specialised technical assessment. This prevents the business from wasting time restoring the wrong version or overwriting a better source.
The architecture practice had three potential sources. First, it had an off-site backup that was not continuously connected to the office network. Second, it had cloud version history for some project folders. Third, it had several external drives used by staff for field work and photography. Each source needed checking before use.
The off-site backup was promising because it had not been accessible from the compromised administrator account. However, its most recent successful backup was from Friday evening. That created a trade-off: restoring it would return the majority of the business’s files, but staff would need to recreate changes made on Monday morning.
Cloud version history recovered several documents updated after Friday. The external drives were more complicated. Two had been connected to infected laptops and contained encrypted copies. One drive had not been connected for several weeks and held original site photographs. It was set aside for a careful read-only assessment rather than plugged into a rebuilt workstation immediately.
For organisations without usable backups, the path can be less certain. Some ransomware strains have known decryption options, while others do not. Deleted original files may occasionally be recoverable from storage media, depending on how the ransomware operated and whether the device has continued to be used. On SSDs, modern features such as TRIM can reduce the chance of recovering deleted data. Encryption of the original files rather than simple deletion also changes the technical picture.
This is where professional assessment matters. A data recovery specialist can examine affected hard drives, SSDs, NAS units and RAID systems without making avoidable changes to the source media. RecoveryGeeks can assess storage devices where data may be inaccessible, damaged or affected by a security incident, while cyber incident responders manage containment, investigation and system remediation. These are complementary tasks, not interchangeable ones.
Restoring data safely, not quickly at any cost
The practice did not restore its Friday backup directly onto the original NAS. The NAS was treated as part of the incident until its configuration, accounts and firmware could be reviewed. Instead, the business rebuilt its core environment on clean, patched hardware and used new administrator credentials.
Before restoration, the backup was scanned and its files were sampled. The team checked that drawings opened correctly, client folders had expected contents, and databases were internally consistent. A backup job marked as successful is useful evidence, but it is not proof that the data can be restored and used.
Restoration happened in stages. The most urgent live projects came first, followed by finance and administration files, then older archives. Staff received access only after their computers had been rebuilt, patched and protected. This reduced the risk of an infected endpoint reconnecting and encrypting restored material.
The business also kept a record of every decision: which backup set was used, what folders were restored, what data was missing, and which accounts had been reset. That record helped with insurance reporting, client communication and post-incident review. It also gave staff a clear answer when they needed to know whether a particular project file had been recovered or still needed reconstruction.
Paying a ransom was discussed but not treated as a recovery plan. Payment does not guarantee a working decryption key, complete restoration or removal of stolen data. It may also create legal, financial and regulatory concerns. Decisions of this kind should involve incident response, legal and insurance advisers, particularly if sensitive client or employee information may have been accessed.
What this business changed after recovery
The practice returned to work over two days, with most active project data restored from the off-site backup and cloud version history. A small number of Monday-morning changes had to be recreated from email attachments, printed notes and staff recollection. That was inconvenient, but far less damaging than losing years of project records.
The larger lesson was that backup frequency alone was not enough. The business introduced separate backup credentials, immutable or offline backup copies, regular restore testing and clearer ownership of backup monitoring. It also tightened remote access, removed unused accounts and trained staff to report unusual login prompts and unexpected attachments immediately.
For NAS and RAID environments, documentation became part of the recovery plan. The team recorded drive order, RAID configuration, device credentials, encryption settings and key contacts. If a multi-drive system fails during or after an attack, guessing at drive order or rebuilding an array without assessment can make a difficult recovery substantially harder.
A ransomware event is stressful because it combines operational downtime, uncertainty and pressure to act fast. The most useful response is controlled rather than frantic: isolate affected systems, protect clean copies, bring in the right technical help, and restore only into an environment that has been checked and rebuilt. The files matter, but so does the system they will return to.
