7 Core Rules for Responding to Ransomware and Infrastructure Breaches

In recent months, questions and requests for advice after various incidents have become increasingly common: some organizations find their systems encrypted, others discover that their infrastructure has been damaged or that corporate email accounts and credentials have been stolen.

In mature companies with established information security practices, such situations are already covered by documented incident response procedures, and teams know exactly who does what in the first minutes and hours. However, when an organization encounters an incident for the first time, the situation becomes far more difficult: everything is down, business stakeholders are anxious, information is scarce, and immediate action is required.

At such moments it is easy to act too aggressively—rebooting servers, deleting suspicious files, clearing logs, or starting restoration from backups—and thereby accidentally complicate any subsequent investigation.

1. Isolate affected systems

The first action is to disconnect compromised machines from the network, including LAN, Wi-Fi, and VPN connections. If the boundary of the incident is clear, isolate specific hosts or network segments. When the scope is unknown and the attack may still be spreading, temporarily shutting down the entire network can be preferable to allowing further lateral movement.

Isolation does not mean powering off the server. Systems should be left running whenever possible. The preferred method is to isolate the host externally—through switch ACLs, firewall rules, port shutdowns, or by physically unplugging the network cable. If software controls must be used, both inbound and outbound traffic should be blocked so that a compromised system cannot continue communicating with attacker infrastructure.

2. Do not reboot or power off systems indiscriminately

A common reaction is to reboot an encrypted server or power it off entirely. Rebooting or shutting down erases volatile information that may be critical for forensic analysis: contents of RAM, active connections, running processes, and other traces of activity at the time of discovery. Once the spread has been contained through isolation, leave systems in their current state unless active encryption or destruction is still occurring.

3. Do not delete or clean anything

Another instinctive response is to locate suspicious items and remove them immediately. Avoid running antivirus scans that delete files, clearing the %TEMP% folder, wiping event logs, or terminating processes simply because they appear unusual. Artifacts that seem irrelevant now—malware launch files, logs with timestamps, command-line arguments, or evidence of lateral movement—may later prove essential to reconstructing the attack.

4. Do not begin restoring from backups

When data is encrypted or systems are broken, the immediate impulse is often to restore from backups and resume operations. This step should be postponed until it is confirmed that the backups themselves are intact and that the attacker is no longer present in the environment. Restoring systems into a still-compromised network risks a second round of encryption. Offline backups should also be protected and not connected directly to potentially compromised infrastructure.

5. Close obviously compromised access channels

If the initial entry point is known—whether a specific account, VPN, exposed RDP, SSH, or email credential—that channel must be closed. When dealing with accounts, terminate active sessions and revoke tokens where possible. Perform these actions from the perimeter or a trusted system rather than from a potentially compromised host. Avoid mass password resets or broad infrastructure changes in the first minutes, as such actions create noise and alter the environment that investigators need to examine.

6. Document what happened

During an incident, details are easily forgotten. Spend a few minutes recording the facts: when the problem was first noticed, who observed it and what exactly they saw, which systems are confirmed affected, what was happening immediately before discovery, the exact time and time zone, and what actions administrators have already taken. Screenshots of ransom notes, error messages, and system states should also be captured. These records will be requested by any investigator and help reconstruct the timeline later.

7. Stop and wait for a plan

Once affected systems are isolated, obvious access channels are closed, the current state is documented, and further spread has been halted, further experimentation should cease. Installing multiple antivirus products, deleting files, rebuilding domain controllers, or returning servers to production without a coordinated plan can destroy evidence and complicate recovery. From this point, structured activities—artifact collection, entry-point identification, timeline reconstruction, and scope assessment—should begin according to a deliberate plan.

In summary, the seven rules are: isolate infected systems, avoid unnecessary reboots or shutdowns, do not delete or clean files, do not start backup restoration prematurely, close known compromised access paths, record observed facts and actions, and stop once containment is achieved so that subsequent work follows a structured plan. These steps are not a complete incident response framework, but they provide a solid starting point when an organization faces its first ransomware or infrastructure incident.