Fast Response, Quality Service, Professional Technical Support

Remote Support

Get Help Now

1300 655 121

Get Help Now

1300 655 121

Fast Response, Quality Service, Professional Technical Support

Remote Support

First 0–24 Hours: Ransomware Incident Response Checklist for Australia

The moment ransomware is confirmed, isolate the affected systems, preserve volatile evidence, and activate your incident response team before touching anything else. Follow a structured checklist like CISA’s StopRansomware guidance: detect and scope first, contain and eradicate second, recover last. Do not pay the ransom as a first move, and get law enforcement and leadership looped in early. Every hour spent guessing is an hour the attacker still has the advantage.

TL;DR:

  • Confirm ransomware infection early by verifying signs such as ransom notes and unusual file activity, and avoid shutting down affected systems to preserve volatile evidence.
  • Use logs and threat detection tools to scope the attack, focusing on entry vectors like phishing, exposed RDP ports, or compromised credentials, especially if data exfiltration is suspected.
  • Contain the threat by segmenting the network and blocking command and control servers, then proceed to eradicate by removing persistence mechanisms and patching vulnerabilities before recovery.
  • Capture memory dumps, disk images, and network logs immediately to preserve evidence for forensic analysis, ensuring documentation is secure and tamper-proof for law enforcement or legal review.
  • Engage your cyber insurer and reporting channels promptly, keep communication clear across teams, and rely on tested, immutable backups to restore systems without reinfection risks.

Table of Contents

Ransomware incident response: your first 0 to 24 hours

Speed matters here, but not at the cost of accuracy. Rushing containment without confirming scope often means you disconnect the wrong systems while the attacker still has a foothold somewhere else.

Start by validating that what you’re looking at is actually ransomware, not a false alarm triggered by a misconfigured backup job or a legitimate encryption tool. Signs to check include ransom notes appearing in multiple directories, file extensions changing, unusual spikes in disk activity, and endpoint alerts referencing known ransomware families. If multiple signs line up, treat it as confirmed and move fast.

  1. Isolate, don’t necessarily power down. Disconnect affected hosts from the network (pull the network cable or disable Wi‑Fi) rather than shutting them off. Powering down wipes volatile memory that forensic teams need, and some ransomware strains trigger further damage on reboot.
  2. Capture volatile evidence if it’s safe to do so. Memory dumps and live log exports can reveal encryption keys, loader processes, or credentials in use, according to CISA’s ransomware response checklist. Skip this step only if capturing evidence would meaningfully delay containment of an active, spreading threat.
  3. Segment the wider network. Isolate the affected VLAN or subnet, disable lateral movement paths, and pause any automated scripts or scheduled tasks that could propagate the payload.
  4. Activate out-of-band communications. Assume your email and chat platforms may be compromised or monitored. Set up a phone tree, a separate messaging app, or a pre-agreed physical meeting point, and pull together your incident response team, including IT, legal, communications, and an executive sponsor.
  5. Start the incident log immediately. Record every system name, timestamp, ransom note wording, and user report as it comes in. This timeline becomes the backbone of your forensic investigation and your regulator notification later.

The Canadian Centre for Cyber Security’s ransomware playbook recommends treating every ransomware event as a major incident from the outset, rather than waiting to see how bad it gets. That mindset shift, from “let’s assess” to “let’s activate”, is what separates a contained incident from a week-long shutdown.

Pro Tip: Print your incident response plan and key contact numbers on paper and store them offsite. If your network and cloud-based documentation are both encrypted, a digital-only playbook is useless exactly when you need it most.

How do you scope the damage and find the entry point?

Containment without scoping is guesswork. Before you lock everything down, you need a working theory of how big the compromise is and how the attacker got in.

Pull logs from your EDR platform, SIEM, firewalls, and VPN concentrator to build a timeline of unusual activity. Dwell time, the gap between initial compromise and the ransomware detonating, often stretches into days or weeks, so don’t assume the attacker only just arrived. Microsoft’s incident response playbook stresses that daily monitoring of these signals is what keeps dwell time short in the first place, and its absence is usually why an incident escalates.

Focus your investigation on the usual entry vectors:

  • Phishing emails with malicious attachments or credential-harvesting links
  • Exposed Remote Desktop Protocol (RDP) ports with weak or reused passwords
  • Compromised credentials, often bought on dark web marketplaces from an earlier, unrelated breach
  • Third-party or supply chain access, including managed service provider tools and vendor VPN connections

Check whether data was exfiltrated before encryption. Many modern ransomware groups run a “double extortion” model, stealing data first and encrypting second, and evidence of outbound transfers to unfamiliar IP addresses changes your legal obligations significantly. It means you’re not just dealing with a recovery problem; you’re potentially dealing with a data breach that triggers notification duties.

Once you have a rough scope, prioritise containment and recovery around business-critical systems: the ones that keep revenue flowing, payroll running, or customer data safe. Everything else can wait.

Containing and eradicating the threat without destroying evidence

Containment buys you time. Eradication removes the attacker’s ability to come back. Confuse the order of these two and you risk reinfecting a system you just spent hours cleaning.

Your first containment moves should include:

  • Segmenting the network further, isolating entire VLANs if lateral movement is confirmed
  • Blocking known command and control (C2) IP addresses and domains at the firewall
  • Disabling internet-facing services that show signs of compromise, such as exposed RDP or VPN gateways
  • Considering a full network shutdown only if containment at the segment level has failed to stop spread

Identity is usually the next weak point. Force a password reset across all affected accounts, revoke active sessions and tokens, and require multi-factor authentication everywhere it isn’t already mandatory. Attackers frequently maintain access through stolen credentials long after the initial malware is found and removed.

Eradication itself means finding and removing every persistence mechanism: scheduled tasks, registry run keys, malicious services, and any backdoor accounts the attacker created. Patch the vulnerabilities that got them in, whether that’s an unpatched VPN appliance or an exposed management port, and harden endpoints before you consider the environment clean.

You know eradication is sufficient to start recovery when a fresh scan across affected systems returns no indicators of compromise, credential resets are confirmed complete, and the entry vector has been closed off. Rushing past this checkpoint is the single most common cause of reinfection.

Pro Tip: Don’t declare “all clear” based on one clean scan. Run a second scan 24 to 48 hours later. Some persistence mechanisms are designed to lie dormant and reappear once monitoring relaxes.

Forensics and evidence collection: what to capture and why

Evidence you don’t capture in the first hours is evidence you’ll never get back. Once systems are wiped or rebuilt, the forensic trail disappears with them.

Priority artefacts include memory dumps, full disk images of affected hosts, firewall and endpoint logs, the ransom note itself, and any network packet captures from around the time of detonation. Indicators of compromise, file hashes, malicious IP addresses, and unusual process names, all help identify the specific ransomware family and whether a known decryptor exists.

Capturing memory before shutdown matters more than most IT teams realise. CISA’s guidance notes that memory capture and system imaging, done before teardown, can reveal in-memory encryption keys or loader processes that later help identify a working decryptor, something that’s impossible to recover once a machine is powered off.

Practical steps for evidence handling:

  • Use forensically sound imaging tools that don’t alter the source data (a common approach is a write blocker plus a validated imaging tool)
  • Label and hash every image and log export the moment it’s captured, so you can prove it hasn’t been tampered with
  • Store evidence on encrypted, access-controlled storage separate from your production network
  • Bring in an external forensic lab or specialist responder if the incident is large, ambiguous, or likely to involve regulators or law enforcement

Balance is the hard part here. Every hour spent imaging a server is an hour that server stays offline. For genuinely critical systems, work with your responder to agree on a minimum viable evidence set so recovery isn’t held hostage to a forensic process that could run for days.

How do you safely recover systems without reinfecting them?

Restoring from backup before you’ve removed the attacker is the fastest way to get encrypted twice in one week. This is the step organisations get wrong most often, because the pressure to get systems back online outpaces the discipline needed to confirm the network is actually clean.

Microsoft’s DART playbook calls this “compromise recovery”: a distinct phase focused entirely on removing backdoors, rotating credentials, and confirming persistence is gone, before any restore begins. Skip it, and you’re rebuilding a house on a foundation that’s still on fire.

  1. Confirm compromise recovery is complete. Every credential the attacker may have touched should be rotated, every backdoor closed, and every suspicious scheduled task or service removed.
  2. Verify your backups are actually usable. Check backup integrity, confirm the most recent clean restore point, and rule out backups that were themselves encrypted or tampered with during the attack.
  3. Restore from immutable or air-gapped backups wherever possible. Microsoft’s ransomware protection guidance treats backup immutability and offline copies as the single most reliable safeguard against paying a ransom, because they can’t be altered even if an attacker has full network access.
  4. Test the restore in an isolated environment first. Don’t restore straight into production. Spin up an isolated segment, confirm the restored system boots clean, and scan it again before reconnecting.
  5. Reimage rather than patch where there’s any doubt. A full rebuild from a known-good image, followed by hardening (updated patches, tightened firewall rules, enforced MFA), is safer than trying to clean an infected system in place.
  6. Run a validation checklist before returning anything to production. Confirm antivirus and EDR agents are active and reporting, check that logging is fully restored, verify backup jobs have resumed, and confirm business-critical applications function correctly under normal load.

A well-designed air-gapped backup strategy removes most of the guesswork from step three, because the backup was never reachable by the attacker in the first place. If your current backup retention policy doesn’t specify how many immutable restore points you keep and for how long, that’s a gap worth closing before your next incident, not during it.

Pro Tip: Test a full restore regularly in an isolated environment, not just a file-level recovery. A backup that nobody has actually restored from is a theory, not a plan.

Who needs to know, and what should you tell them?

Communication failures during a ransomware incident tend to cause more reputational damage than the technical outage itself. Silence gets read as either incompetence or cover-up, and both are worse than a clear, early statement that says “we know, we’re on it, here’s what we know so far.”

Internally, loop in executive leadership, legal counsel, HR (particularly if staff data or systems are affected), and your cyber insurer immediately, all before any public statement goes out. Practitioner analysis from TechTarget makes the point clearly: treating incident response as a purely technical exercise, without legal and communications at the table from hour one, is how organisations end up with inconsistent messaging and missed compliance deadlines.

Externally, your obligations depend on what data was affected:

  • If personal information was likely accessed or exposed, you may need to notify affected individuals and the Office of the Australian Information Commissioner under the Notifiable Data Breaches scheme.
  • Cyber provides the national reporting channel and recovery resources specific to Australian organisations.
  • Customers, partners, and suppliers who rely on your systems deserve a timely, honest update, even if it’s brief.
  • Law enforcement engagement should happen early, not as an afterthought. It affects both the ransom decision and what investigative resources become available to you.

Prepare holding statements in advance, before an incident, and route all external communication through a single, secure channel your team controls.

Turning the incident into a stronger playbook

Every ransomware incident, however painful, is a live-fire test of your incident response plan. Treating the aftermath as just “getting back to normal” wastes the one thing you paid dearly for: a real-world stress test of your defences.

Run a blameless post-incident review within days of recovery, while details are still fresh. The goal is root cause, not blame; a review that turns into a hunt for someone to fire will just teach staff to hide the next warning sign instead of reporting it.

  • Update your playbook and remediation plan based on what actually happened, not what the plan assumed would happen
  • Schedule a tabletop exercise within the next quarter to test the updated plan against a similar scenario
  • Run a technical restore test to confirm the backup and recovery fixes you made actually work
  • Tighten technical controls: privileged access management, network segmentation, MFA coverage, and patching cadence
  • Report on measurable improvement to leadership, not just “we fixed it”
Metric Why it matters What good looks like
Mean time to respond (MTTR) Shows how quickly detection turns into action Shrinking with each exercise
Number of affected systems Reveals how well segmentation contained spread Fewer systems affected per incident
Recovery point objective (RPO) performance Measures how much data was actually lost Data loss close to zero with tested backups
Time to full restore Tests whether recovery plans work under pressure Restore completed within your planned SLA

If your organisation doesn’t have a working IT disaster recovery plan that’s actually been tested against a scenario like this, the post-incident review is the moment to build one, not defer it again.

What a coordinated response actually looks like in practice

A vendor-agnostic responder brings proactive monitoring, ransomware-safe backups, and an emergency response team that can move within hours, not days. In a typical first 72 hours, that looks like rapid assessment and containment in the first six hours, forensic evidence capture and scope confirmation through day one, and a staged restore from clean, verified backups starting day two, once compromise recovery is confirmed complete.

Clients working with an engaged incident responder should expect clear deliverables: a written scope assessment, a containment status update, a restore timeline, and a post-incident report with concrete remediation steps, not just a verbal “you’re sorted now.”

[Author bio and specific credentials for Ru to be added]

[Client case studies and testimonials for TechBug’s ransomware response services to be added]

Should you use a ransomware negotiation service?

Negotiation services exist because paying a ransom (or deciding not to) is rarely a clean decision, and specialist negotiators can sometimes reduce the demanded amount or buy time for recovery efforts to catch up. CISA’s guidance is explicit that paying is not recommended as policy, partly because it funds further attacks and partly because there’s no guarantee the decryption key works.

If your organisation is weighing a negotiation service, treat the decision with the same rigour as any other major operational call. A few things worth checking before you engage one:

  • Sanctions exposure. Some ransomware groups operate under jurisdictions covered by sanctions regimes. Paying them, even through a third-party negotiator, can carry legal risk depending on the destination of funds, so this needs legal sign-off, not just a technical decision.
  • Track record with the specific ransomware family. Reputable negotiation firms will have handled the same strain before and can tell you honestly whether decryption after payment has historically worked.
  • Independence from the decryption outcome. Ask how the firm is paid, and whether their fee depends on a successful negotiation. That shapes their incentive to recommend paying versus recommending you rely on backups instead.
  • Coordination with law enforcement and your insurer. A negotiation service should work alongside these parties, not instead of them.

In most cases, the strongest negotiating position is simply not needing to negotiate: solid, tested, immutable backups mean recovery doesn’t hinge on a criminal group’s goodwill.

When and how should you engage your cyber insurance provider?

Call your cyber insurer as soon as the incident is confirmed, before you make major recovery decisions. Most policies have specific notification windows, and delaying that call can jeopardise cover for costs you incur in the meantime.

Insurers typically maintain panels of approved forensic firms, negotiators, and legal counsel, and using a provider outside that panel can mean the cost isn’t reimbursed. Ask your insurer directly, early, which vendors are pre-approved so you’re not paying out of pocket for a forensic team that falls outside your policy’s terms.

Understand what your policy actually covers before you need it, not during the incident. Business interruption losses, ransom payments (where legally permissible), forensic investigation costs, legal fees, and regulatory fines are often covered separately, with different sub-limits and exclusions. A policy that covers ransom payment but excludes the business interruption loss from a week of downtime leaves a significant gap.

Document everything with a paper trail insurers will ask for: timestamps, decisions made, costs incurred, and communications sent. Insurers generally want to see that you followed a documented incident response process, which is one more reason a written, tested playbook matters well beyond the technical response itself.

Keep your insurer in the loop on major decisions, particularly around ransom negotiation or public disclosure, since acting unilaterally on either can affect your claim.

A practitioner’s view on what actually breaks organisations

The technical response usually holds up. What fails is leadership clarity: nobody delegated decision authority in advance, so the first few hours get burned on “who’s allowed to authorise this?” instead of action. Tested backups and a rehearsed plan beat improvisation every time. Follow the plan you built when you were calm, not the one you’re inventing under pressure. If you don’t have that plan tested yet, Techbug can help you build one before you need it.

— Ru

How Techbug supports your ransomware response

A practical alternative to scrambling for help mid-incident is to have a responder already on call instead of hunting for one while systems are still encrypted. Some services may include managed IT support that keeps monitoring running day to day, an emergency response team ready to mobilise on containment and forensics, ransomware-safe backups built for immutable, tested restores, and tabletop exercises that stress-test your plan before a real attacker does.

Techbug

Some providers focus on one piece, backups, or monitoring, or cleanup, but a vendor-agnostic approach can mean an integrated response instead of multiple vendors pointing fingers at each other during critical incidents. Support may include compliance aspects such as notification obligations, documentation, and maintaining audit trails that insurers and regulators require afterwards.

If your organisation doesn’t have a tested incident response plan, or you’re not confident your current backups would survive contact with real ransomware, start with a conversation. Visit Techbug’s managed IT services page to see how ongoing monitoring and emergency response fit together, or head to our IT security page to scope a readiness assessment before you’re forced into one. For independent readiness testing and capability benchmarking, VORTX Group is a specialist partner worth engaging alongside your internal exercises.

Sources