Ransomware Recovery: How a Good Backup Strategy Saves Your Perth Business

Ransomware is not a question of if for most Perth businesses — it is a question of when. The Australian Cyber Security Centre (ACSC) recorded a ransomware incident every seven minutes during its 2024–25 reporting period, with the average financial impact per cybercrime report exceeding $95,000 for small businesses. For medium-sized organisations, the figure climbs to over $100,000 per incident. But the real cost is not the ransom itself — it is the downtime, the lost data, the reputational damage, and the weeks of recovery.

The difference between a ransomware attack that destroys your business and one that becomes a manageable interruption comes down to one thing: your backup strategy. Not whether you have backups — nearly every business has some form of backup — but whether those backups are actually capable of surviving the attack and delivering clean data fast when you need it most.

This guide is about ransomware recovery specifically: what makes a backup strategy ransomware-proof, how to recover when you are already encrypted, and what Perth businesses can do today to ensure they can restore operations without paying a cent to attackers.

Why Most Backups Fail Against Ransomware

The common assumption is that a regular backup is enough protection. If you have a daily backup running, you can just restore from yesterday's copy and move on, right? Unfortunately, modern ransomware is specifically designed to defeat this assumption. Here is how attackers systematically neutralise standard backups:

Credential Harvesting from the Primary Environment

Most ransomware attacks start with a compromised credential — a stolen password, a phishing link that captured a session token, or an MFA fatigue attack. Once the attacker has access to a single user account, they do not immediately deploy ransomware. They spend days or weeks quietly mapping the network, escalating privileges, and — critically — identifying where the backups are stored and how they are accessed. If the backup system uses the same Active Directory domain and the same credentials as the rest of the environment, the attacker already has everything they need to delete or encrypt the backups before triggering the main payload.

Backup Repository Discovery and Destruction

Modern ransomware strains include dedicated modules for finding and destroying backup systems. They scan for common backup software processes, mount points, and network shares. They delete Volume Shadow Copies (VSS) on Windows systems. They attempt to connect to NAS devices, network shares labelled "backup," and cloud backup repositories using cached credentials. A backup connected to the network and accessible with domain credentials is not a safety net — it is a secondary target. Many businesses discover too late that their "backups" were encrypted alongside their production data.

Encryption Pacing and Silent Exfiltration

Attackers no longer trigger encryption immediately after gaining access. Many modern ransomware operations pace the encryption over hours or days, encrypting files gradually so that backup software, which runs on a daily or hourly schedule, dutifully backs up the encrypted versions, overwriting clean copies in the backup repository. By the time the business detects the attack, the backups themselves contain encrypted data. This technique — sometimes called "backup poisoning" — makes simple incremental backups worse than useless, because they actively replace your known-good restore points with corrupted data.

These three failure modes explain why the ACSC's Essential 8 framework specifically mandates not just regular backups (Mitigation 5), but immutable or offline backups that survive an active attack. The standard "backup to a network drive" approach that worked a decade ago is now actively dangerous — it provides false confidence while being trivially bypassable by modern ransomware. Our backup and disaster recovery services at Stride IT are built to address all three of these attack vectors.

The Three Pillars of Ransomware-Proof Backup Strategy

A backup strategy that can survive a ransomware attack rests on three non-negotiable pillars: immutability, separation, and testability. If your backup strategy is missing any of these three, you have a gap that attackers can and will exploit.

1. Immutable Backups — Cannot Be Altered, Cannot Be Encrypted

Immutability means that once a backup is written, it cannot be modified, encrypted, or deleted by anyone — including an administrator with full system privileges — for a defined retention period. This is achieved through technologies like Object Lock (Amazon S3), WORM (Write Once Read Many) storage, or dedicated immutable backup appliances. Even if an attacker gains complete control of your backup infrastructure, the immutable copies remain untouched. The ACSC explicitly recommends immutable backups as a critical control for ransomware resilience. For Perth businesses, cloud backup providers offering immutable storage in Australian data centres — such as Wasabi, Backblaze B2, or AWS S3 with Object Lock enabled — provide the most practical path to immutability. The retention period should be long enough to cover the typical ransomware dwell time: at minimum 14 days, though 30 days is the industry standard.

2. Separation — Not on the Same Network, Not with the Same Credentials

Separation is about ensuring that even if your primary environment is completely compromised, the backup system remains inaccessible to the attacker. This means:

• Different credentials — Backup administration accounts must be completely separate from your primary domain. Use dedicated service accounts in a separate Microsoft tenant or a completely different identity provider. An attacker who compromises your domain admin account should still have no access to the backup system.
• Different network segment — Backup repositories should sit on a separate network segment with strict firewall rules preventing inbound connections from the production network. The backup system should be able to reach production to collect data, but production should not be able to reach the backup system on any port that could be exploited.
• Multi-factor authentication on backup access — Every administrative action on the backup platform should require MFA. If your backup system supports it, require phishing-resistant MFA methods (passkeys, FIDO2) rather than SMS or authenticator app codes.
• Air-gapped or offline copy — At least one backup copy should not be continuously connected to the network. This could be a removable drive stored in a secure off-site location, rotated weekly, or a cloud backup repository that requires a separate authentication step to access. During a ransomware incident, the air-gapped copy becomes your last-resort recovery source if the primary backups are compromised.

3. Tested Backups — Verified, Not Assumed

The most common backup failure is not technology — it is assumption. Businesses assume the backup is working because the software says it is, only to discover during an actual recovery that the data is corrupt, the restore process takes days instead of hours, or the application does not function after restoration. The ACSC recommends quarterly restore testing as a minimum for Australian businesses. A proper restore test verifies:

• Data integrity — After restore, are the files readable, complete, and uncorrupted? A backup job that completes with "success" status can still produce corrupt data.
• Restore speed — How long does it actually take to restore a single file, a folder, and a full server? Document these times against your Recovery Time Objective (RTO). If restoring your file server takes 48 hours and your business cannot survive that long without it, you need a faster restore path.
• Application functionality — After restoring a line-of-business application database, does the application actually work? Are permissions intact? Do all integrations function correctly?
• Full disaster simulation — At least annually, simulate a real ransomware scenario: take the primary systems offline and attempt to restore operations from backups alone, following your documented disaster recovery plan.

Step-by-Step: How to Recover from a Ransomware Attack

If ransomware encrypts your systems today, here is the recovery process you should follow — but only if you have the backup infrastructure in place to execute it. Without proper backups, your options shrink to negotiating with attackers or accepting permanent data loss.

Phase 1: Containment (First 60 Minutes)

The moment ransomware is detected, the priority is stopping the spread. Disconnect all affected systems from the network immediately. Do not shut them down — forensic analysis needs the memory and running state. Disconnect the internet connection at the router if necessary to prevent the attack from spreading to off-site systems. Contact your IT provider or incident response team. Do not delete files or run antivirus scans on affected systems — this destroys evidence that investigators need to determine the attack vector. Notify the ACSC via cyber.gov.au/report and consider whether the incident meets the threshold for notifying the OAIC under the Notifiable Data Breaches scheme.

Phase 2: Verification (Hours 1–4)

Before rushing to restore, verify that your backup infrastructure is intact. Check that your immutable backups are still accessible and have not been tampered with. Confirm that the attacker did not have access to the backup credentials or network segment. Identify the last known-clean backup — the most recent backup taken before the attacker gained access to your environment. This is critical because if the attacker was in your network for days before triggering encryption, your backup system may have been backing up compromised data for multiple cycles. The "clean" restore point is the backup taken before the earliest evidence of compromise. Determine the scope: which systems are encrypted, which are clean, and which need to be rebuilt rather than restored (for example, a domain controller that was the attacker's entry point should be rebuilt from scratch, not restored from a backup that may also be compromised).

Phase 3: Restoration (Hours 4–48)

Restore in order of business priority. Start with the systems that generate revenue or serve customers — email, customer databases, e-commerce platforms, accounting systems. Use a clean, isolated restore environment if possible. Do not connect restored systems to the production network until you have verified they are clean and the original infection vector has been addressed. After restoring each system, verify data integrity and application functionality before moving to the next. Document every restore step, including start time, completion time, and any issues encountered, for post-incident review and insurance reporting.

Restoring from immutable backups should be straightforward if the separation and credential controls were properly configured. The cloud backup platform should present a clean restore point, and the restore process should deliver usable data. If you are restoring from an air-gapped offline copy, the process will be slower — you need to physically connect the backup media to a clean system, verify its integrity, and then restore. This is why the recommended strategy is a hybrid of cloud-based immutable backups for fast recovery and offline copies for last-resort protection.

Phase 4: Post-Incident (Days 1–30)

Once operations are restored, the work is not over. Conduct a post-incident review to determine exactly how the attacker gained access — was it a phishing email, a vulnerable remote desktop port, a compromised vendor account? Fix the root cause before considering the incident closed. Update your incident response plan based on lessons learned. Re-test your backups after the fix to confirm they still work. Report the incident to relevant authorities: the ACSC, the OAIC if personal data was involved, and your cyber insurer. A ransomware incident that is properly handled — with immutable backups that delivered clean data — becomes a case study in resilience rather than a business-ending event.

The Cost Comparison: Backup Investment vs Ransom Payment

Many Perth small business owners make a quick calculation: "A backup solution costs me money every month — I will take my chances." This calculation is wrong, and here is why. The cost of a proper backup strategy — immutable cloud storage with Australian data centres, backup software licensing, and professional monitoring — is a predictable monthly expense. The cost of a ransomware attack is unpredictable and potentially catastrophic.

The ACSC advises against paying ransoms. Paying does not guarantee data recovery — studies consistently show that a significant percentage of businesses who pay never receive working decryption keys, and those who do are frequently targeted again because they are known to pay. Paying also funds the criminal ecosystem and may have legal implications under sanctions regimes or anti-money laundering laws. A business that can restore from clean, immutable backups does not need to negotiate. They can decline the ransom demand, restore operations from their own data, and report the incident without the shadow of having financed criminal activity.

The choice is not "backup cost vs ransom cost." The choice is "predictable monthly investment in data resilience vs the total cost of business interruption, reputational damage, client notification, regulatory reporting, and the possibility of never getting your data back." For Perth businesses, the math is clear. A comprehensive backup and disaster recovery strategy aligned with the ACSC Essential 8 is not an optional IT expense — it is a fundamental business continuity requirement.

Microsoft 365 and Ransomware: The Shared Responsibility Trap

A growing number of Perth businesses operate almost entirely in Microsoft 365 — email in Exchange Online, files in SharePoint and OneDrive, meetings in Teams, line-of-business data in Dynamics or custom apps. Many assume that because their data lives in Microsoft's cloud, it is protected against ransomware. This is dangerously incorrect.

Microsoft operates under a shared responsibility model. Microsoft ensures the platform itself is available, resilient, and redundant. But protecting your data within the platform — against accidental deletion, malicious insider threats, and ransomware — is your responsibility. A ransomware attack that compromises a user's workstation can sync encrypted files through OneDrive, replacing clean versions across all connected devices. SharePoint version history provides some protection, but it is limited in retention duration and does not cover all data types. Exchange Online's recycle bin retains deleted emails for 30 to 93 days depending on licence tier, but it does not protect against a mass deletion or encryption scenario.

The correct approach is third-party backup for Microsoft 365 — a dedicated solution that captures point-in-time snapshots of mailboxes, SharePoint sites, Teams, and OneDrive data, stores them in immutable cloud storage, and provides granular restore capabilities independent of Microsoft's built-in retention. This backup should be part of your broader backup and disaster recovery strategy, using the same immutable storage platform as your on-premises backups. A unified backup strategy that covers both on-premises and cloud data is simpler to manage, easier to test, and more reliable during a crisis.

Building Your Ransomware Recovery Runbook

The difference between a business that recovers from ransomware in hours and one that stays down for weeks is preparation. A ransomware recovery runbook — a step-by-step document that everyone in the business can follow — is the single most effective preparation tool you can create. Here is what your runbook should contain:

• Emergency contact list — Phone numbers for your IT provider, backup software support, cyber insurer, the ACSC (1300 292 371), and key internal decision-makers. Store this outside your network — a printed copy in a safe or a document on a personal device.
• Containment procedures — Exactly who does what in the first 60 minutes. Who disconnects the network? Who contacts the IT provider? Who communicates with staff and clients? Who decides whether to engage external incident response?
• Backup access instructions — How to access the backup system, which credentials to use, where to find the immutable restore points. Test these instructions quarterly — if the person who set up the backups is on holiday when the attack happens, someone else needs to be able to follow the steps.
• System restore priority list — Ranked from most critical (restore first) to least critical (restore last). This should be based on business impact, not technical convenience. Your accounting system might be harder to restore than your file server, but if you cannot invoice clients without it, it goes to the top of the list.
• Communication templates — Draft emails and messages for different stakeholders: staff (what has happened, what they should do), clients (if their data may be affected), suppliers, and regulators. Having pre-written templates saves precious time during a crisis when clear thinking is hardest.
• Post-recovery checklist — Steps to confirm that every restored system is clean, every credential has been rotated, every compromised account has been secured, and the root cause of the attack has been addressed.

For Perth businesses that rely on their IT systems to operate daily — which is almost every modern business — a ransomware recovery runbook is not an optional exercise. It is the document that turns a potentially business-ending event into a contained, manageable incident. The time to write it is now, not after the ransom note appears on your screen.

Key Takeaways

• Modern ransomware specifically targets backup systems — standard backups that share network and credentials with production are vulnerable to attack
• Immutable backups (WORM/Object Lock storage) are the single most effective defence: once written, they cannot be altered or deleted by anyone, including an attacker with administrative access
• Backup separation is critical — different credentials, different network segment, MFA-protected access, and at least one air-gapped offline copy
• Test your backups quarterly — a backup that has never been restored is a risk, not a safety net
• Microsoft 365 data is not automatically protected against ransomware — third-party backup with immutability is essential for Exchange Online, SharePoint, Teams, and OneDrive
• A ransomware recovery runbook, stored outside the network, is the most important preparation tool you can create
• The ACSC advises against paying ransoms — businesses with clean, immutable backups can restore from their own data without negotiating with criminals
• Ransomware recovery follows a four-phase process: contain, verify, restore, post-incident — each phase requires preparation done before the attack

Ransomware is the most significant cyber threat facing Perth small businesses today, but it is also the most survivable — provided you have the right backup strategy in place. Immutable backups, proper separation, regular testing, and a documented recovery plan turn a potentially catastrophic attack into a controlled recovery operation. The investment in ransomware-proof backup infrastructure is a fraction of the cost of a single incident, and unlike a ransom payment, it delivers guaranteed results every time you need it. If you are unsure whether your current backup strategy meets these standards, a professional backup and disaster recovery assessment can identify gaps and provide a clear path to ransomware resilience.

Stride IT is a Perth-based managed IT and cyber security provider helping local businesses implement resilient, ACSC-aligned backup and disaster recovery strategies. Our backup and recovery services are designed for Australian small and medium businesses, with immutable cloud storage, Australian data centres, and regular restore testing. Get in touch for a no-obligation ransomware recovery readiness assessment.