Discovering encrypted files or a ransom note on your network triggers immediate panic. In the first 24 hours of a ransomware outbreak, uncoordinated reactions often cause more permanent data loss than the malware itself. Well-meaning staff might reboot servers, delete suspicious files, or inadvertently accelerate the encryption routine.

A successful defense requires a structured, calm approach grounded in established incident response frameworks, such as NIST SP 800-61. This guide covers the operational steps you must take during the first 24 hours to contain the damage, preserve forensic evidence, assess your backup viability, and begin safe remediation.

Phase 1: Immediate Containment (Hours 0–2)

The first objective is halting the spread of the ransomware without destroying volatile evidence stored in system memory. Modern human-operated ransomware rarely hits a single machine; adversaries move laterally through administrative protocols such as Server Message Block (SMB), Remote Desktop Protocol (RDP), and remote management tools.

Take the following actions immediately on affected endpoints and servers:

  1. Isolate network interfaces: Unplug physical Ethernet cables and disable Wi-Fi adapters. If the machine is a virtual machine (VM), disconnect its virtual network adapter in the hypervisor management console.
  2. Do not power off or reboot: Powering down a machine destroys RAM artifacts, such as running injection processes, network connections, and sometimes the decryption keys temporarily kept in memory by poorly implemented encryption routines. Furthermore, rebooting can trigger scheduled persistence mechanisms that restart or accelerate encryption.
  3. Hibernate if supported: If you must freeze a system state immediately to stop an ongoing encryption loop, force system hibernation or take a hypervisor snapshot with RAM included. Hibernation writes the current memory state to disk (hiberfil.sys), preserving valuable evidence.
  4. Sever shared storage paths: Disconnect any Network Attached Storage (NAS), Storage Area Network (SAN) shares, and mapped cloud synchronizers (e.g., OneDrive, Dropbox agents) from the network to keep shadow copies and backups out of reach.

Phase 2: Communication and Triage (Hours 2–4)

Assume the adversary has compromised administrative accounts and has visibility into standard corporate communications. If attackers see security staff discussing containment plans over internal chat or email, they may immediately deploy secondary lockers or wipe disks.

Establish Out-of-Band Channels

Shift all incident command communications to out-of-band platforms. Use external cellular networks, secure mobile messaging applications, or pre-configured secondary communication tools completely detached from your corporate Active Directory or Google Workspace domain.

Form the Incident Response Command

Assign clear roles immediately. You need a technical lead to direct system actions, an operations lead to manage business impact, legal counsel to review regulatory reporting requirements, and a primary coordinator to log every event and decision chronologically.

Your technical team should run a preliminary sweep across network infrastructure to locate the blast radius:

  • Inspect domain controllers, core switches, and perimeter firewalls for anomalous outbound connections.
  • Disable compromised service accounts and global administrative credentials across directory services.
  • Review authentication logs for sudden spikes in privileged logins or lateral movement tools like PsExec and PowerShell remoting.

Phase 3: Evidence Preservation and Scoping (Hours 4–8)

Before wiping drives or attempting rebuilds, you must preserve critical forensic data. This data is essential for determining how the attackers gained access (the initial vector), whether data was exfiltrated (double extortion), and what regulatory reporting obligations you face.

Capturing Volatile and Disk Evidence

For systems of high forensic value—such as the suspected patient zero or domain controllers—capture physical memory and complete disk images using write-blocking hardware or hypervisor-level cloning.

# Example: Capture an immediate triage package on Linux using standard tools
mkdir /tmp/triage
ss -tunap > /tmp/triage/network_connections.txt
ps auxwww > /tmp/triage/process_tree.txt
dmesg > /tmp/triage/kernel_log.txt
last -x > /tmp/triage/login_history.txt

On Windows hosts, collect Windows Event Logs (specifically Security.evtx, System.evtx, and Microsoft-Windows-Sysmon/Operational.evtx), master file tables (MFT), and Prefetch directories. These records help establish a precise timeline of adversary activity.

Identifying the Strain

Locate a copy of the ransom note and identify the file extension appended to encrypted assets. Cross-reference these indicators with documented ransomware profiles on platforms like MITRE ATT&CK. Knowing the specific family helps determine:

  • Common Initial Access Brokers associated with the group (e.g., exposed RDP, vulnerable VPN appliances, phishing).
  • Known data exfiltration tooling used prior to encryption (e.g., Rclone, MEGA).
  • Whether public decryptors exist for the identified strain.

Phase 4: Evaluating Backups (Hours 8–12)

Ransomware operators routinely spend days or weeks inside a target network before executing the locker. During this dwell time, their primary objective is finding and destroying backups. Never connect backup repositories directly to an infected environment.

Follow a strict protocol to inspect your recovery data:

  1. Keep the backup infrastructure segmented: Ensure backup management consoles and storage arrays reside on an isolated management VLAN with independent, non-domain credentials and multi-factor authentication (MFA).
  2. Verify immutability: If your organization uses write-once-read-many (WORM) storage or cloud-based immutable backups, verify via the storage console that the lock policies were not modified.
  3. Inspect snapshot integrity: Check backup catalogs for mass deletion events, modified retention policies, or truncated log files. Attackers often issue administrative commands to purge snapshots shortly before dropping the payload.
  4. Scan backup contents: Before restoring any virtual machine disk or database, mount the backup image in an isolated sandbox network. Scan the filesystem for dormant web shells, malicious scheduled tasks, and persistence scripts placed by the attackers prior to the encryption date.

Phase 5: Eradication and Remediation Planning (Hours 12–24)

Restoring systems without closing the entry vector creates a loop where adversaries simply re-deploy their payload. The final stretch of the first 24 hours focuses on closing the initial breach point and hardening the core environment.

Close the Initial Vector

If the infection originated from an exposed edge device—such as a remote access gateway or unpatched firewall—take that appliance offline, patch it according to the vendor's emergency advisory, or replace its configuration entirely. If the entry was a phishing payload, revoke the compromised user's session tokens, reset their credentials, and block associated external command-and-control (C2) domains at the perimeter DNS level.

Enforce Enterprise-Wide Credential Resets

Assume all credentials cached on compromised systems are stolen. In Windows environments, this requires a structured reset strategy:

  • Reset all Domain Admin and privileged service account passwords twice (to invalidate the Kerberos Ticket Granting Service history).
  • Reset the KRBTGT account password twice with sufficient interval between resets to allow replication, invalidating all forged Golden Tickets.
  • Terminate all active VPN, SSH, and cloud portal sessions to prevent persistence over existing authorization cookies.

Common Mistakes to Avoid

Incident responders frequently encounter self-inflicted roadblocks caused by rushed decisions during the early hours of an attack:

  • Negotiating or paying immediately: Paying a ransom does not guarantee a working decryption tool, nor does it guarantee the attacker will delete stolen data. Any negotiation decision must involve executive leadership and legal counsel.
  • Cleaning infected machines in place: Attempting to run antivirus scans to "clean" a system that suffered ransomware execution is unsafe. Backdoors, custom persistence mechanisms, and hidden accounts often remain. Rebuilding systems from validated, clean base images is the only dependable method.
  • Communicating over compromised email: Sending incident reports over corporate exchange accounts alerts the threat actor to your operational progress, prompting them to destroy more infrastructure.
  • Restoring to production too early: Restoring backups onto a network where the attacker still maintains active C2 connectivity results in the fresh backups being encrypted immediately.

First 24-Hour Incident Response Checklist

Use this concise checklist to track operational priorities during the critical initial window:

  • [ ] Isolate affected network switches, VLANs, and endpoints; disconnect physical cables and wireless adapters.
  • [ ] Preserve RAM on high-value systems by taking memory dumps or VM snapshots before touching power states.
  • [ ] Establish secure, out-of-band communication channels for all incident responders and stakeholders.
  • [ ] Identify the ransomware family, inspect the ransom note, and document all file extension indicators.
  • [ ] Verify that backup repositories are physically or logically disconnected from the compromised network.
  • [ ] Check immutable backup retention policies and validate the integrity of the latest clean recovery points.
  • [ ] Identify and seal the initial point of entry (patch perimeter devices, revoke compromised access tokens).
  • [ ] Reset all privileged administrative credentials, service accounts, and directory service identity keys.
  • [ ] Begin building an isolated, sanitized network segment for staged machine recovery and testing.