Ransomware Incident Response Guide

1. Prepare before the incident

Incident response is significantly harder when the first decisions are made during the attack. Define the technical and organisational response before it is needed.

Prepare the technical controls

• Maintain current contact details for technical, management, legal, insurance and specialist incident-response resources.
• Ensure administrators can isolate endpoints and disable compromised accounts quickly.
• Maintain documented firewall and network containment procedures.
• Ensure identity, endpoint, firewall, DNS, VPN and backup logs are available centrally.
• Maintain protected backup copies and regularly test restoration.
• Document critical systems and their recovery dependencies.
• Maintain secure emergency administrator access that does not depend entirely on the potentially compromised production identity system.

Define authority

Decide who can authorise emergency network isolation, account disablement, system shutdown and restoration. Ambiguity over authority can waste valuable time during a fast-moving incident.

2. Identify and declare the incident

Ransomware may first appear as an endpoint alert, inaccessible files, unusual file extensions, a ransom note, a backup failure or reports from users. Treat multiple related indicators as one potential incident rather than investigating every symptom independently.

Initial questions

• What systems are affected?
• When was suspicious activity first observed?
• Which users and accounts were involved?
• Is encryption or destructive activity still occurring?
• Can the attacker still access the environment?
• Are identity systems, backups or management systems affected?
• Is there evidence of data theft as well as encryption?

Record the incident start time, the time of each major observation and the timezone used. Build a timeline immediately rather than relying on memory.

3. Immediate priorities

1. Stop active spread: isolate confirmed compromised endpoints and restrict dangerous lateral paths.
2. Protect identity: contain compromised privileged accounts and protect domain controllers and authentication infrastructure.
3. Protect recovery: verify that backup systems and recovery copies remain available.
4. Preserve evidence: retain relevant logs and avoid unnecessary destructive actions.
5. Establish trusted communications: assume compromised email or collaboration accounts may not be reliable for sensitive incident coordination.
6. Establish scope: identify affected systems, accounts, network zones and likely attacker access.

4. Containment

Containment should prevent the attacker from gaining additional access while avoiding unnecessary destruction of evidence.

Endpoint containment

• Use EDR isolation where available.
• Disconnect systems that are actively encrypting data when immediate isolation is necessary.
• Record the hostname, user, IP address and time of isolation.
• Avoid rebuilding every affected system before understanding the attack path.

Identity containment

• Disable or restrict confirmed compromised accounts.
• Prioritise privileged and service accounts that could enable further movement.
• Invalidate sessions or tokens where the identity platform supports it and compromise warrants it.
• Review recent privileged authentication before assuming the account is clean.

Network containment

• Isolate affected VLANs or security zones where necessary.
• Restrict SMB, RDP and other lateral-management protocols during active containment.
• Block known malicious destinations where appropriate.
• Protect identity, management and backup networks with tighter emergency policy.
• Document every emergency firewall or switching change so it can later be reviewed and reversed safely.

Containment principle: Prefer targeted controls that remove the attacker's paths while preserving essential services. A complete network shutdown may be necessary in exceptional circumstances, but it should not be the default response.

5. Preserve evidence

Evidence is needed to establish initial access, attacker activity, affected systems and whether eradication was successful. Evidence handling should be proportionate to the organisation's legal and forensic requirements.

High-value sources

Evidence handling principles

• Record exact timestamps and timezone.
• Record who collected evidence and when.
• Preserve original logs where possible rather than relying only on screenshots.
• Do not overwrite or unnecessarily reboot systems containing potentially important volatile evidence unless operational requirements demand it.
• Do not place passwords, private keys, tokens or other reusable secrets into incident notes.
• Coordinate formal forensic acquisition with an appropriate specialist when required.

6. Establish the attack timeline

Build a timeline from the earliest credible event to the current incident. Useful milestones include the first suspicious authentication, initial endpoint compromise, privilege escalation, lateral movement, security-tool tampering, backup changes and encryption activity.

Correlate events by account, hostname, source IP, destination, process and timestamp. The goal is to distinguish the original compromise from later attacker activity.

7. Determine initial access

Do not begin eradication until there is a reasonable understanding of how the attacker entered, otherwise the same entry point may remain open.

Investigate potential routes including exposed remote access, compromised credentials, phishing, vulnerable Internet-facing systems, third-party access and compromised applications or services.

Questions to answer

• Which account or system was compromised first?
• Was MFA used, bypassed or absent?
• Was there an Internet-facing vulnerability or exposed service?
• Was malicious email or a user action involved?
• Was a supplier or trusted management connection involved?
• Is the original access path still available?

8. Scope the compromise

Determine which systems are actually compromised rather than assuming only encrypted systems are affected. Attackers may establish persistence or steal credentials days before encryption.

• Identify all systems associated with compromised accounts.
• Review privileged authentication and remote administration.
• Look for common processes, tools, persistence mechanisms and destinations.
• Review lateral movement between servers and workstations.
• Investigate identity and backup infrastructure separately.
• Identify potentially accessed or exfiltrated data.

9. Eradication

Eradication removes the attacker's ability to return. Reimaging a visibly encrypted workstation is not sufficient if compromised credentials, persistence or a vulnerable perimeter system remain.

Typical eradication actions

• Remove malicious persistence.
• Rebuild systems where trust cannot be established.
• Patch or remove the exploited vulnerability.
• Reset compromised credentials according to an ordered plan.
• Rotate exposed service-account secrets and keys where necessary.
• Remove unauthorised accounts, services and scheduled tasks.
• Review firewall, VPN and remote-management configuration.
• Verify endpoint protection is installed and healthy.

Identity caution: If domain-level credentials may have been compromised, password resets must be planned as part of a broader identity recovery process rather than treated as a simple workstation task.

10. Recovery

Recovery should restore a known-trusted environment, not simply bring encrypted systems back online as quickly as possible.

Recommended recovery order

1. Establish trusted administrative access.
2. Recover core identity and authentication services.
3. Recover DNS, DHCP and other foundational network services.
4. Recover critical infrastructure and management systems.
5. Recover core applications and storage.
6. Recover ordinary user endpoints and lower-priority services.

The exact sequence depends on the environment. The important principle is to restore dependencies before dependent applications.

11. Validate before reconnecting systems

A restored system should not automatically return to production. Validate that it is patched, protected, correctly configured and no longer exposes the original attack path.

• Confirm security tooling is healthy.
• Verify required patches and configuration changes.
• Check privileged accounts and local administrator membership.
• Verify firewall and segmentation policy.
• Review authentication and endpoint telemetry after restoration.
• Confirm backups are operating again and protected copies remain available.
• Monitor the recovered environment closely for unexpected activity.

12. Communications and decision-making

Technical containment is only part of incident response. Define how technical findings are communicated to leadership and relevant external parties.

• Maintain a single incident record.
• Separate confirmed facts from assumptions and hypotheses.
• Record major decisions and who authorised them.
• Coordinate with legal, insurance and specialist responders where appropriate.
• Follow applicable reporting and notification requirements based on the organisation and incident.
• Do not assume that internal email remains trustworthy if identity compromise is suspected.

13. After the incident

The incident should produce measurable improvements rather than simply a restored service.

• Determine and document initial access.
• Identify why lateral movement was possible.
• Review privileged identity design.
• Review Internet-facing exposure and patching.
• Validate backup isolation and restoration performance.
• Review detection gaps and alerting latency.
• Review segmentation and firewall exceptions.
• Update incident-response procedures based on what actually happened.
• Retest the controls that failed or were missing.

14. Incident response checklist