Recovering files after ransomware encrypts live data and backups

Ransomware can make recovery more complicated than the backup administrator’s usual restore procedure suggests. Recovering encrypted files when backup snapshots are also encrypted is not a matter of choosing the newest backup: the copied data may be just as inaccessible as the source, and the same control plane may still be exposed.

The practical goal is to find a trustworthy recovery point, restore it without giving the attacker a fresh foothold, and prove that the business can use the result. This requires coordination among IT, security operations, legal advisers, executives and the owners of critical data.

Australian organisations span very different operating environments, from Sydney and Melbourne offices with cloud applications to essential services and smaller businesses in regional centres. Each may combine on-premises systems, Microsoft 365 tenants, managed service providers and backups administered by the same identity platform. That mix can make a single failed snapshot or shared administrator account the difference between a contained incident and enterprise-wide disruption.

Why encrypted snapshots change the recovery problem

Backup copies are logically separate, but they are not always operationally independent. An attacker who compromises a cloud tenant or privileged service account may reach backup APIs, alter retention settings or disable controls intended to protect copies. Some ransomware families also delete version histories after encryption, so an apparently healthy job history can conceal a compromised backup.

The encryption relationship matters too. Snapshots may rely on the same tenant key, recovery credentials or administrative identity as production data. If that key has been exposed, restoring the snapshot can return encrypted content without providing a safe way to decrypt it. A restore also copies forward any malicious changes made before the snapshot was captured.

Organisations should therefore treat each candidate snapshot according to its exposure and key status, rather than assume that a dated copy equals a clean copy. The first recovery decision is which evidence and data can be trusted, not which console has the quickest restore button.

Containment comes before restoration

Stopping active encryption and closing the attacker’s access takes priority over restoring workloads. Isolate affected hosts, revoke active sessions, reset exposed credentials and restrict cloud administration. Preserve relevant logs and volatile evidence before they disappear, while ensuring the response team uses clean, separately managed systems.

Australian privacy duties add time-sensitive considerations. When personal information is involved, the Office of the Australian Information Commissioner requires notification under the Notifiable Data Breaches scheme if there are reasonable grounds to believe an eligible breach occurred and is likely to result in serious harm. APRA-regulated entities must also meet CPS 230 operational risk requirements, while hospitals and utilities must balance restoration against patient safety, service continuity and regulator expectations.

Getting those decisions wrong can leave a technical recovery as a public relations mess. Australian organisations often rely on managed service providers and distributors alongside internal IT, so task ownership must cover third-party administrators. Nobody should leave the hard parts to “sort it out later”.

Find a clean and trusted recovery point

Build a timeline that links the earliest confirmed malicious activity, administrative changes, encryption events and backup jobs. Review version histories, retention policies, job failures and alerts in the cloud console, endpoint tools and network records. The timeline should distinguish a backup created before compromise from one created after the attacker gained sufficient access.

Test whether candidate copies inherit compromised encryption keys, credentials or management paths. Shared tenants, delegated backup permissions and synchronised administrative agents deserve particular attention. An immutable copy is helpful only if its retention lock and recovery credentials remain outside the attacker’s reach. For an organisation using Microsoft 365, for example, a tenant-wide compromise may affect mailboxes, SharePoint content and Exchange Online backups through the same control relationships.

Retain the original snapshots for forensic examination, even when a clean copy is found. Hashes, timestamps, catalogue records and access logs can demonstrate what was present and when. This evidence supports insurer discussions, legal advice and regulatory reporting; deleting every affected copy may look tidy operationally while destroying a crucial part of the investigation.

Restore through a controlled recovery path

Restore a selected copy into an isolated environment that lacks routine trust relationships with production. Keep it disconnected from user access and business applications, document its configuration and scan the restored files and images before use. An isolation boundary reduces the chance that dormant malware, stolen credentials or tampered content will reach the active network again.

Where a valid pre-compromise copy exists, restore only the required systems and data, then test them under controlled conditions. If the content remains encrypted, investigate the official key-management and recovery options for the platform. A legitimate escrow key or key held by a trusted key custodian may permit decryption when the malware has not altered the data structure. An attacker’s key or a promise from an unknown decryption service does not constitute a sound recovery plan.

If no usable copy or key is available, teams must rebuild from other authoritative sources. Cloud audit trails can recreate many administrative changes, applications can be redeployed from known-good artefacts and business records can sometimes be reconstructed from finance, payroll or supplier systems. Each reconstruction needs an owner who can verify accuracy, because a technically successful rebuild can still deliver incomplete or inconsistent data.

Validate the data before reconnecting it

Validation must cover both technical integrity and business meaning. Compare restored files with trusted hashes or source records, inspect for missing folders and altered metadata, and have system owners test representative workflows. Security controls should check restored content for malware and unexpected executables. Restoring the right volume of data is not enough if its contents are subtly corrupted.

Before reconnection, review the paths that enabled the incident. Remove compromised agents, patch the exploited vulnerability, rotate service accounts and enforce phishing-resistant multifactor authentication for privileged users. Confirm that backup jobs, retention locks and alert rules are configured independently and that monitoring covers destructive changes made through administration APIs.

Bring systems back in stages, with clear rollback points and enhanced observation. Preserve forensic images and relevant records until legal, insurance and regulatory needs are resolved. In a hospital in Melbourne or a water utility in Brisbane, a staged return can let technical teams confirm safe operation while operational managers maintain essential services.

Coordinate technology and human response priorities

CARM Security was developed by Exclusive Networks to support post-breach attack remediation and mitigation. Its ecosystem brings technologies from multiple security vendors into a coordinated model for identifying, containing, responding to and remediating attacks. That breadth can help an Australian team connect endpoint, network, cloud and threat-intelligence findings instead of managing isolated tools during a high-pressure event.

Central coordination does not replace an incident-response plan or qualified forensic judgement. Clear roles, access to authoritative logs and agreed escalation criteria remain essential. An organisation considering external support can contact the CARM team to discuss its architecture and request a demonstration of the coordinated response workflow.

A useful handoff separates checks that must happen before restoration from those that verify the restored environment.

Before restoration begins

During restoration and validation

Shared checklists reduce argument about whose evidence is correct. They also make it easier for a managed service provider in Adelaide, a corporate security team in Sydney and an external incident responder to work from the same assumptions.

Compare recovery routes and choose the next action

The best route is the one with the strongest evidence behind it. Comparing options before acting helps prevent a rushed restore from damaging the clean copies that remain:

Recovery route Required condition Main advantage Principal limitation
Pre-compromise snapshot A trusted pre-intrusion copy and an independent, usable key path exist Restores files, configuration and history together May be stale and can reintroduce unpatched weaknesses
Isolated offline copy A separately controlled copy exists and its integrity can be verified Reduces exposure from compromised backup infrastructure Time-consuming to validate, catalogue and reconnect
Decryption with a legitimate key A valid key or escrow path exists and the file format remains intact Preserves the latest copy when a usable key survives Useless if the key was stolen, destroyed or the data was altered
Reconstruction from authoritative sources Reliable transactions, applications or records remain available Can recover data held outside the backup platform Requires business owners to reconcile completeness and accuracy

Whichever route is chosen, containment and credential repair continue in parallel. Recovering data does not prove the attacker has left, and restored files should remain quarantined until security, privacy and business owners approve their return. Comparing options also prevents a weak decryption promise or an unverified export from displacing a sound snapshot.

By the end of the next working day, appoint one owner to document the earliest known-good backup date, the location of independent encryption keys, the approval needed for an isolated restore and the date those controls were last tested.