Ransomware Demands and the First 60 Minutes
A ransom note has just popped up on a screen. Files are locked, staff are confused, and leadership wants clear answers fast. In that moment, your cloud backup solutions are either your safety net or one more thing to worry about.
Those first 60 minutes matter. Done well, they limit damage, stop attackers from going further, and keep your options open. Done badly, they can tip off the attacker, trigger more data destruction, and weaken your position with regulators, customers, and insurers.
In this guide, we walk through a practical, post-demand decision framework you can follow when your data is in the cloud. The focus is simple: how to quietly check backup integrity, immutability, and restore paths without waving a flag to the attacker. At Aera, we see these challenges across organisations in Australia and New Zealand, especially around the end of financial year when changes, projects, and staff leave collide.
Stabilise the Situation Before You Touch Backups
Before anyone logs in to a backup console or starts talking about restores, you need to stabilise the situation. The goal is to keep the blast radius from growing while you get organised.
In the first hour, focus on three aims: contain, coordinate, and collect. That typically means establishing clear decision authority, moving communications onto trusted channels, and creating a reliable record of what happens when.
A fast war-room checklist usually includes:
- Confirm who has decision authority for technical, legal, and business calls
- Activate your incident response plan and notify core teams only on trusted channels
- Set up secure out-of-band communications such as separate chat, phones, or video
- Nominate a single recorder to track timelines, actions, and observations
- Confirm which systems are definitely affected and which are still clean
Just as important is what you do not do yet. Avoid discussing restore plans or passwords on systems that might be compromised, and do not log into cloud backup portals from endpoints that could be infected. It's also wise not to rush to shut down everything without understanding what services support logging or evidence, and not to rapidly change large amounts of infrastructure in visible ways.
Maintain chain-of-custody for evidence. That means screenshots of the ransom note, timestamps of when it appeared, copies of key logs, and names of staff who touched systems. This often aligns with cyber insurance and legal expectations later.
This is also the moment when good preparation pays off: tested runbooks, clear RACI roles, and current SLAs with cloud backup and incident response partners. If those are in place, the first hour feels controlled instead of chaotic.
Quietly Assess Your Cloud Backup Blast Radius
Once your war-room is stable, you can start assessing the backup blast radius. This is the set of backup repositories, tenants, or regions that might be at risk based on how far the attacker has reached.
Start by considering the pathways an attacker might have used to reach backups, and how tightly your backup environment is coupled to production identity, domain membership, and remote access tooling. Key questions to think about include:
- What accounts or admin roles the attacker could have accessed
- Whether your backup platform shares identity with production systems
- Whether any on-prem backup gateways or proxies are joined to compromised domains
- Any remote access tools or scripts that might have backup permissions
Next, use safe verification practices so your checks don't become a new infection vector and don't accidentally alert the attacker. Good hygiene here usually looks like:
- Use a known-clean device, such as a freshly built laptop or a device held for emergencies
- Log in with a hardened admin account that is not used for day-to-day tasks
- Enforce MFA and use secure networks, separate from possibly infected environments
- Keep the group small to reduce chances of leaks or accidental signals
Then, run quiet checks that create minimal noise and focus on whether something changed suddenly around the time of compromise. For example:
- Status of recent backup jobs, looking for sudden failures, cancellations, or gaps
- Newly created admin accounts or unusual permission changes
- Recent policy changes that shorten retention or change encryption settings
- Sudden drops in backup catalog size or missing restore points
In the logs, you're looking for indicators of tampering or cover-up activity. Watch for:
- Large deletion or encryption events on backup storage
- Unexpected changes to repository or bucket configurations
- Disabling of alerts or audit trails around the time of compromise
Avoid anything that looks like a full recovery operation to an attacker. No big restores, no sweeping password resets from potentially watched systems, and no visible changes that could trigger their monitoring tools.
Validate Immutability and Isolation Without Raising Flags
With an idea of the blast radius, the next step is to confirm which backups are truly safe. Here, immutability and isolation are your best friends.
In practice, immutability means write-once, read-many storage that cannot be altered or deleted during a fixed retention window, even by admin or root accounts. You want to verify that those settings are actually in place, not just assumed. Quiet checks include:
- Reviewing retention policies for key workloads, making sure the lock periods match expectations
- Confirming that immutable or locked flags are still active on backup repositories
- Checking storage tiers and object lock configurations for recent changes
- Verifying that deletion protection is turned on for core backup buckets or volumes
Then assess isolation. The aim is to understand whether an attacker who has production access could realistically pivot into backup control planes, identities, or management interfaces. Ask:
- Are backup accounts or tenants separate from production, with different credentials?
- Is there a separate identity store or at least clearly segmented admin roles?
- Are backup management interfaces reachable only from specific networks or jump hosts?
- Are service accounts tightly scoped, or do they have broad admin access?
You can score each backup set as high, medium, or low risk based on a combination of identity separation, the strength of authentication controls, and how much privileged access exists in practice. In particular, consider:
- Identity separation and use of MFA
- History of privileged access and number of admins
- Recent configuration changes before or during the incident
- Whether backup servers are joined to production domains
Common weak spots we see, especially in winter attack waves when teams are stretched, include shared admin accounts, MFA turned off for backup consoles, over-privileged service accounts, and backup servers treated like just another app server.
Test Restore Paths Safely and Shape Your Recovery Strategy
Once you know which backup data looks safe and how protected it is, the next question is how you could restore if you needed to. This does not mean pulling the trigger yet; it means understanding your options and validating that the path to recovery is real, not theoretical.
Typical restore paths include:
- Full environment rebuild in the cloud or on-prem
- Tiered restore of core services first, such as identity, communications, and key business apps
- Targeted file or database recoveries for priority data sets
Safe testing methods are all about isolation, so you can validate integrity without reintroducing malware or contaminating clean environments. Practical approaches include:
- Restore small, representative workloads into an isolated cloud network or sandbox tenancy
- Keep that network off production routing and internet access until checked
- Scan restored systems with modern EDR tools before any user access
- Validate that applications start correctly and data is intact
To avoid tipping off attackers, keep testing low-profile and limit signals that look like an organisation gearing up for a major recovery cutover. For example:
- Start with small restores that look like normal maintenance
- Avoid sudden DNS updates or routing changes that would be easy to spot
- Limit who knows about the tests and keep chatter off compromised systems
Your ransom versus restore decision will rest on a mix of operational reality, risk tolerance, and external constraints. The main factors typically include:
- Estimated time to recovery for key services
- Impact on customers, partners, and internal operations
- Regulatory disclosure obligations and advice from legal and privacy experts
- Conditions in your cyber insurance policy
- Board and executive appetite for risk and downtime
This is where external partners can help quickly shape a plan around architecture, DR runbooks, and secure paths into your cloud backup environments, especially across Australian and New Zealand regions.
Turn Lessons Into a Hardened Cloud Backup Playbook
Whether this is a real incident or a rehearsal, the work should not stop once systems are stable. The lessons from those first 60 minutes are gold for building a stronger playbook.
Short-term improvements are often about making the "first hour" more repeatable and less dependent on tribal knowledge. These might include:
- Refining the first-hour checklist based on what actually happened
- Updating contact trees and escalation paths for business, IT, and legal
- Clarifying who owns each triage step across security, infrastructure, and cloud teams
- Documenting which cloud backup solutions held up well and where gaps appeared
Longer-term upgrades can make the next incident far less painful by reducing the chance that backups are reachable, mutable, or quietly degraded before you need them. Common upgrades include:
- Enforcing immutability by default for key workloads
- Removing shared admin accounts and enforcing named identities with MFA
- Adopting just-in-time privileged access instead of standing admin rights
- Separating identity and network planes between production and backup environments
We also recommend building a steady rhythm of ransomware war games, not only tabletop conversations but technical restore drills measured against your recovery time and recovery point targets. Governance can back this up with clear reporting, such as:
- Board-ready cyber resilience dashboards
- Regular backup health and integrity summaries
- Alerts when immutability, retention, or key security settings change unexpectedly
At Aera, our focus on managed cloud, cybersecurity, connectivity, voice, video conferencing, and IT support across Australia and New Zealand has shown us one thing very clearly: when a ransom demand lands, the difference between panic and a controlled response often comes down to how well your cloud backup playbook is prepared and practised before the note appears.
Protect Your Business Data With Reliable Cloud Backups
If you are ready to safeguard your files and systems, our tailored cloud backup solutions make it simple to keep everything secure and accessible. At Aera, we work closely with your team to design a backup strategy that fits how your business actually operates. Reach out to contact us today and we will help you put a robust, future-ready backup plan in place.
