Lessons from a ransomware attack: containment and recovery

A ransomware incident is measured in more than encrypted files and ransom demands. It tests whether an organisation can establish facts quickly, limit the attacker’s movement, preserve evidence, restore essential services and make sound decisions while normal operations are under pressure. The most valuable lessons often emerge after the crisis, when teams can examine which controls worked, where communication failed and how long recovery really took.

For Australian organisations, the operating environment adds practical considerations. A business in Sydney may depend on cloud services hosted across several regions, while a manufacturer near Melbourne or a council in Brisbane may rely on suppliers with very different security capabilities. Notification obligations, the Australian Cyber Security Centre’s guidance, the Essential Eight and the expectations of customers and insurers all shape the response. Containment and recovery therefore need to be treated as a coordinated business process, rather than a purely technical exercise.

Establish facts before making irreversible moves

The first lesson from a ransomware attack is the value of a reliable incident picture. Teams need to identify affected identities, endpoints, servers, cloud workloads, backups and third parties. This means collecting endpoint alerts, firewall records, identity logs, email telemetry and relevant information from managed service providers. A ransom note is evidence, but it is rarely a complete account of what happened.

Early assumptions can cause further damage. An organisation might isolate a single laptop while an attacker still has access through a compromised administrator account, or begin rebuilding servers before understanding whether the initial access remains open. A short, documented timeline helps incident leaders distinguish confirmed facts from working hypotheses and gives legal, executive and technical teams a common reference point.

The investigation should also establish whether data was accessed or exfiltrated before encryption. That distinction affects regulatory assessment, customer communications, negotiation strategy and the scope of remediation. In Australia, the Notifiable Data Breaches scheme may become relevant when personal information is involved and the breach is likely to result in serious harm.

Make containment a decision with clear authority

Containment is more than disconnecting devices. It is a sequence of decisions designed to stop unauthorised access while preserving the business services needed for safety, communication and recovery. Common actions include disabling compromised accounts, revoking tokens, blocking known command-and-control infrastructure, isolating segments and restricting remote administration.

These actions need an agreed owner. A security operations team may detect the intrusion, but a business executive may need to approve the shutdown of a warehouse system, hospital service or customer portal. If authority is unclear, teams can lose valuable hours seeking approval or take contradictory measures. An incident commander should maintain a decision log that records the action, reason, time, owner and expected consequence.

Containment also needs to account for the attacker’s likely objectives. If privileged credentials were stolen, changing passwords alone may be insufficient. Sessions, application tokens, service accounts, certificates and remote access tools may all require review. Identity controls such as multifactor authentication, conditional access and privileged access management should be applied with care so that emergency access remains available to authorised responders.

Preserve evidence while restoring control

A rushed recovery can destroy the evidence needed to understand the intrusion. Before wiping or rebuilding systems, responders should preserve forensic images, relevant logs, memory captures where appropriate and copies of attacker communications. Evidence handling should be documented so that internal investigations, insurance reviews, legal proceedings or law enforcement engagement are not weakened by uncertainty.

Log retention is a recurring weakness. Many organisations discover after an attack that identity or endpoint data was retained for too short a period, or that critical logs were available only through a cloud console that the attacker also accessed. Centralised, tamper-resistant collection can provide a more dependable record. The Australian Cyber Security Centre’s incident guidance is a useful reference for structuring response activities and escalation.

Recovery teams should work from clean management infrastructure. If the identity provider, remote monitoring platform or software deployment tool is compromised, using it to rebuild the environment can reintroduce the attacker. Credential resets, administrator workstation checks, clean installation media and verified configuration baselines are essential safeguards before large-scale restoration begins.

Restore services in a deliberate order

The fastest route to full recovery is rarely restoring everything at once. A better approach is to rank services by safety, legal significance, operational dependency, customer impact and revenue effect. Core identity services, network controls, communications and backup management may need to be recovered before applications that depend on them.

Backups are valuable only when they are usable and clean. Teams should verify recovery points, test restoration in an isolated environment and confirm that backup credentials were not compromised. Immutable or offline copies can limit the attacker’s ability to destroy recovery options, but they still require regular testing. A backup that has never been restored under pressure is an assumption, not a recovery capability.

Recovery objectives should be realistic. A system described as having a four-hour recovery time objective may take much longer if vendor support, data validation, application dependencies or manual workarounds have not been rehearsed. Australian businesses with distributed operations should include telecommunications outages, regional staffing constraints and public holiday availability in those exercises.

Coordinate internal teams and external partners

Ransomware response often involves an ecosystem of security vendors, cloud providers, incident response specialists, insurers, legal advisers, communications teams and law enforcement. Fragmented action can create gaps: one provider may isolate a device while another restores it, or an outsourced help desk may reset accounts without knowing that the identity platform is under investigation.

A coordinated model provides a shared operating picture and a clear escalation path. Platforms such as CARM Security are designed around this type of coordinated response, bringing together technologies and capabilities that help organisations identify, contain, respond to and remediate attacks. The practical benefit is less about having more tools and more about reducing the time spent moving between disconnected consoles and teams.

Checks that support coordinated response

During containment:

Before restoration:

The Australian market includes many organisations that outsource parts of their technology stack to managed service providers. Contracts should state who owns incident decisions, how quickly logs must be supplied, where data is stored and how a provider will support forensic work. These details matter during an attack, when informal assumptions quickly become operational delays.

Learn from the business impact, not just the malware

A post-incident review should examine how the organisation functioned under pressure. Which service became the first bottleneck? Were executives given timely information? Did staff know how to report suspicious activity? Could customers obtain accurate updates? Did the contact list include an available specialist on a weekend or during an Australian public holiday?

Technical findings remain important, including the initial access vector, exploited vulnerabilities, persistence mechanisms and control failures. Yet business findings often reveal the changes with the greatest practical value. A company may learn that its network segmentation was reasonable but its supplier access was poorly governed, or that backups were sound but no one had authority to prioritise which sites would be restored first.

The review should produce owners and deadlines rather than a long list of abstract recommendations. Actions may include tightening privileged access, increasing log retention, separating backup administration, revising supplier contracts, implementing application allowlisting or aligning endpoint and identity monitoring. Each item needs a way to verify completion and a test that demonstrates whether the control works.

Compare response paths and set the next step

Different response approaches suit different stages of an incident. Internal teams know the environment and business context, while specialist responders bring experience, forensic capability and surge capacity. A coordinated platform can help connect both groups, provided its integrations, permissions and operating procedures have been prepared before the crisis.

Response approach Useful when Main risk Control that improves the outcome
Internal response team The organisation has trained staff, strong telemetry and decision authority Limited capacity during a prolonged incident Maintain an exercised playbook and an on-call structure
External incident response specialist Forensics, negotiation support or rapid surge capability is needed Delayed access to systems, evidence or decision-makers Pre-agree engagement terms, access methods and escalation contacts
Managed detection and response provider Continuous monitoring and outsourced investigation are required Provider may lack business context or authority to act Define response thresholds, service levels and executive escalation
Coordinated security ecosystem Multiple vendors, sites and response functions must work together Tool integration may be incomplete or poorly governed Test integrations, shared workflows, permissions and reporting before an incident

Recovery is complete only when the organisation can explain what happened, demonstrate that unauthorised access has been removed and operate with a measured level of residual risk. That may involve extended monitoring, targeted threat hunting and staged removal of emergency controls. Closing an incident because systems are online can leave the original compromise unresolved.

The clearest next step is to run a timed ransomware recovery exercise that begins with a compromised privileged account, includes a backup restoration and ends with an executive review of the incident timeline, decisions and outstanding risks.