Ransomware on mounted network drives: a practical response

When ransomware encrypts files on mounted network drives, a mapped drive such as Z:\ can represent an SMB share on a Windows file server, NAS, or another workstation. A ransom note may be only the first sign: shared files can also have been copied or staged for exfiltration. Stop further damage while keeping recovery options open.

In Australian workplaces, hybrid teams in Sydney, Melbourne and Brisbane often rely on shared project folders while some staff work remotely. Small businesses commonly combine Microsoft 365 with an on-premises file server or NAS, so one compromised account can expose data beyond its own PC. Treat the mounted drive as part of the incident until the server, identities, backups and logs have been checked.

Contain the spread before touching files

Disconnect affected workstations from the network by removing their network cable and disabling Wi-Fi; if the file server itself is compromised, isolate its switch ports or network segment. Do not repeatedly open shared folders to see what is encrypted, and avoid logging into the server from the affected PC.

From a clean, trusted administrator device, suspend affected shares or terminate suspicious SMB sessions where appropriate. Do not delete encrypted files, ransom notes or suspicious executables. Keep backup systems and replication targets disconnected from the compromised network until their integrity is known.

After containment, revoke active sessions and tokens from a clean device, then enable MFA for remote and privileged access. Reset exposed passwords with unique administrator credentials, sequencing changes with the incident lead so responders are not locked out or malware is triggered.

Establish the true extent of encryption

Record which drive letters and UNC paths were mounted, which servers and NAS devices they pointed to, and which users had access. Check the ransom note’s file extension, server audit logs, endpoint alerts and file-change timestamps. This reveals whether encryption happened locally or on the host serving the share.

Test the encryption on a disposable copy, never on the only original. Look for renamed files, altered permissions and possible staging archives, but do not copy suspect data to ordinary cloud storage. Ask whether the same credentials work across multiple servers; shared administrator passwords make lateral movement much easier.

Prioritise HR, finance, clinical, legal and operational repositories by business impact. Australian SMEs may hold sensitive tax, payroll and customer records in shared folders. Record which services stopped, and for how long, to support containment and reporting. Detailed malware removal guidance can help identify persistence before rebuilding.

Preserve evidence and meet Australian duties

Photograph ransom notes and affected folders, export logs, and preserve a forensic image when server compromise is serious or insurance requires it. If encryption remains active, prioritise isolation over perfect evidence collection. A qualified incident responder can determine whether imaging is justified.

The Privacy Act 1988 and Notifiable Data Breaches scheme may apply if access to personal information was lost, copied or otherwise affected. Assess likely harm and notification duties with legal counsel and the Office of the Australian Information Commissioner. Encryption alone does not automatically establish a notifiable breach; evidence and likely consequences matter.

Report significant incidents through ReportCyber and consider state police or the Australian Federal Police. Critical infrastructure operators may have duties under the Security of Critical Assets Act 2018 and sector arrangements. Preserve records of decisions and remediation. Current malware security updates can help identify family-specific indicators before recovery.

Rebuild shares from trusted backups

Treat every connected backup as potentially exposed. Review backup jobs, retention, snapshots and replication logs, then test a backup in an isolated recovery environment. Prefer immutable or offline copies created before the intrusion. Do not restore over damaged servers, as this can overwrite evidence or reintroduce persistence.

Build a clean recovery network with patched systems, updated security tools and no production trust. Reimage endpoint accounts, review Active Directory or identity-provider changes, and restore data by business priority. Validate file counts, application dependencies, ownership and access controls before users reconnect.

If no usable backup exists, investigate family-specific recovery options cautiously. A decryptor must match the exact ransomware family and version, and it should be downloaded and executed only after its provenance is checked. Use reputable threat reporting to narrow the family. Never pay simply because a vendor promises recovery.

Compare practical recovery routes

No single route suits every network-share incident. Compare the cost of downtime, integrity of each copy, sensitivity of the data and likelihood that attackers retained access. Restore only after the related accounts, endpoints and management plane are clean; otherwise the encryption can return.

Recovery route	Best fit	Essential check	Main limitation
Immutable backup	Full server recovery	Independent copy and clean target	May omit recent changes
Versioned snapshot	Selective file recovery	Valid session and malware scan	Synced malware may be present
Clean server rebuild	Compromised host	Reimage identity and storage	Longer outage
Family decryptor	Confirmed ransomware variant	Exact version and trusted source	Partial or unavailable
Specialist recovery	No usable copy	Legal and forensic review	Cost and uncertain results

Use a combination where appropriate: recover the server from a known-good image, restore selected data from an earlier snapshot, and use a trusted decryptor only for a confirmed variant. Record which source supplied each restored file and test business workflows before full production use.

Prevent recurrence across Australian workplaces

Treat network shares as controlled data paths, not extensions of every desktop. Separate administration networks from user devices and file servers, apply least privilege, remove direct internet exposure and use modern SMB settings. Monitor unusual archive creation, mass file changes, new admin activity and odd logins.

Protect backups independently of the file server: keep immutable or offline copies, monitor failed jobs and practise restoration. An incident plan should identify who can isolate shares, notify customers, engage counsel and contact the Australian Signals Directorate or sector authorities. Clear ownership matters when small Australian teams manage cloud and on-premises systems.

• Replace shared local administrator credentials with unique, MFA-protected identities; rotate exposed secrets and remove dormant accounts.
• Segment file servers and NAS appliances from user networks; block unnecessary SMB and management access.
• Patch Windows, NAS firmware and VPN software, removing unsupported internet-facing systems.
• Retain immutable or offline backups, alert on failed jobs and test restoration rather than trusting backup success.
• Alert on mass renames, rapid file changes, privileged logons and unusual archive creation.
• Exercise recovery for mapped drives, cloud sync and hybrid staff, with clear ownership of each system.