Immediate Response Priorities and Pitfalls to Avoid during a Ransomware Attack

If your network experiences a ransomware attack, it is likely that your IT staff will want to immediately begin researching and working to stop the attack before they get guidance and assistance from an outside incident response firm. This guide is to help aid your first responders in identifying the most important ransomware attack priorities for containment and avoiding common pitfalls that can hinder later investigation and recovery activities.

Immediate Response Priorities to a Ransomware Attack

1. Notify your incident response partner and cyber insurance agent (if you have these relationships in place).
2. Stop any malicious encryption software that may still be running.
   1. If you suspect servers and workstations are still encrypting data, power down as quickly as possible to reliably stop further encryption.
   2. If continued encryption is not a concern on a system, leave the system powered on but disconnect it from the network (as RAM may contain forensic data).
   3. Disconnect network attached storage (NAS) systems from the network immediately and until you can validate that all systems are free of ransomware.
3. Isolate critical systems to prevent further spread of the malware.
   1. Isolate backups and backup servers.
   2. Shut down servers or disconnect them from networks.
   3. Shut down wide area network tunnels.
4. Disable any employee remote access services that do not use multi-factor authentication (MFA).
   1. Disable VPNs or whitelist source IPs to known employees.
   2. Disable Remote Desktop Protocol (RDP) services or whitelist source IPs to known employees.
5. Disable existing domain administrator accounts.
   1. Create new domain administrator accounts for critical IT staff.
   2. Disable all other domain administrator accounts (to prevent logins and use of issued Kerberos tickets).
6. Disable malware command-and-control channels.
   1. Disable outbound web traffic.
   2. Disable all other outbound services/protocols through the firewall.
7. Collect and retain logs that are not already in a centralized archive.
   1. As Windows security event logs can by default be overwritten within days, copy the folder c:windowssystem32winevtlogs from any domain controllers, RDP servers and other key impacted servers to a safe place.
   2. Since many firewall logs and VPN are also overwritten quickly, work to export VPN access logs and firewall traffic logs to a safe place.

Develop a recovery strategy

At this point you can stop, take a breath, and begin to evaluate the situation and develop an investigation and recovery strategy. Examples of key next steps include:

• If needed, completing contracting with a legal firm and/or incident response firm
• Determining the state of storage systems and status of online and offline backups
• Creating an inventory of impacted systems
• Prioritizing applications for recovery
• Creating an inventory of sensitive or high-risk data that could have been stolen
• Evaluating potential risk to cloud email accounts or other cloud services

Pitfalls to Avoid

In the case of an incident, your organization will want to avoid the following.

Destroying critical data

Many times, IT staff may delete encrypted files or impacted virtual machines to free space for recovery, only to learn that the associated backups are missing or corrupt. Be sure to retain copies of all encrypted or impacted files and systems until after backups are validated and restores are complete, even if it means you have to slow down recovery to add temporary storage and copy potentially unneeded data.

Destroying evidence

Deleting files or virtual machines, or performing other recovery activities before taking steps to preserve disk images, logs and other evidence, can destroy artifacts that could be used later to help tell the story of how the attacker got in and what data they stole.

Making overly optimistic assumptions

There is often a tendency to underestimate an attacker early on and determine it unlikely that the attacker accessed some critical system or set of sensitive data, perhaps because of a belief that the data would have been too hard to find or too difficult to extract. The organization then bases its decisions about investigation and notification activities on these optimistic assumptions, only to learn that the assumptions were wrong.

Leaking information to the attacker

Be aware that the attacker may be monitoring your communications during and after the attack. For example, one community organization disclosed their insurance policy’s ransom coverage limit in a public board meeting discussing the community’s response options, which led to the attacker increasing their demand to match the policy limit.

If you would like assistance in creating your response plan for ransomware attacks, please contact our cybersecurity team at any time!