Ransomware Response Playbook

Short Incident Response Playbook for Ransomware

1. Quick and Dirty Cheatsheet (Start Here if you need)

This is a very short version of section six. It will help you get started quickly. This is not intended to be used alone as it skips important steps. Please refer to section 6. These instructions assume that the time is within a working day. Do your best to minimize the damage if it occurs after-hours. If possible, call your staff. However, delays can be expected as the University isn’t a 24/7 environment. Attackers will choose times when the response time may be limited.

  1. DO NOT PANIC. Panicking can cause more problems. Take a deep breath and relax. Then, proceed as methodically as you can.
  2. If there are active events, we want the ‘Blast Radius of an attack to be reduced as soon as possible. This will reduce damage and the recovery time.
    1. Usually, the ransomware attack will result in a message appearing on the screen. Take a picture and disconnect the device from any network. Now. It is best to not turn it off, unless necessary. This can cause damage to forensic evidence.
    2. If you suspect or are certain that a device has been infected by ransomware but have not received any message, disconnect it physically or logically from the network. Now. It is best to not turn it off, unless necessary. This can cause damage to forensic evidence.
    3. It may be simpler to turn off all devices infected by the same virus than to deal with each one individually.
    4. All network shares that are used by confirmed or suspected devices should be disconnected until ransomware is removed. Start now. Also include mirrors and disaster recovery versions.

You must ask before you can act. If this is the case, then proceed to step 3. Get that permission and make any necessary changes. The University Chief Information Security Officer expects infected devices to be removed from the network within minutes. If you take immediate action, he will assist you.

  1. Don’t keep other people in the dark about what is going on. Be prepared with a preliminary scope, but don’t waste time compiling a complete list of files and devices. If you have an incident team, tell them. Otherwise, let your boss and your Unit Administrator know. Please let Central Incident Response know by sending an email to security.response@utoronto.ca
  2. Collect and protect information about the infection. You should have a list of infected devices, file locations, network logs, system images, malicious executables, screenshots, and examples of encrypted files.
  3. Refer to section five for the procedure and go through it, verifying that you have followed all steps.

2. Purpose

Information Technologies Services – Information Security (ITSIS) has created this playbook to provide a guideline and workflow for recovering from ransomware attacks.

Ransomware is a type of malware that’s used to carry out a cryptoviral-extortion attack. The malware encrypts victims’ files making them inaccessible. An attacker demands a ransom to unlock them. The attackers could also export the victim’s files before encrypting them and threaten to distribute the data if they don’t pay the ransom. Although there are slight variations to the attack, these are the most common.

In the context of this playbook, a ransomware attack is one in which one or more university-owned devices have been infected by malware that has encrypted files and order for ransom has been made.

3. Scope

Ransomware typically attacks Workstations (desktops or laptops) but can spread to servers. This playbook applies to all individuals who have or manage workstations and servers that are associated with the University of Toronto. These devices can be located physically on campus (on-prem), or remotely (in the cloud or anywhere else a person works). The devices can be physically or virtually removed from any environment.

4. Prerequisites

This document assumes that you have access to infected physical devices. Access to network devices that contain infected devices might also be necessary. Administrator-level access is required to the hypervisor if virtual machines are involved.

It is assumed that you are familiar with the operating system, software, hardware, hypervisor, and network environment of the server.

A Security Incident Response Plan should be developed to clearly define the roles and responsibilities of all parties involved and how communication is expected about the incident.

5. Responsibilities

These actions will be performed primarily by subject matter specialists (SMEs) who have the necessary access and skills. The process will also involve other non-technical people, such as Operational management or administrative staff.

For a complete list of roles and responsibilities, please refer to the Security Incident Response Plan (for your unit/environment). You can find the University’s Security Incident Response Plan that offers guidance for individual plans.

6. Procedure

This procedure is more about organization than it is about a timeline. The following steps can be performed simultaneously and that is fine. It is okay to do one step ahead of the others. As long as all necessary actions are taken. This is illustrated by the fact that initial containment usually occurs before identification is complete.

6.1 Do not panic!

Security incidents can be stressful. It is important to manage the situation calmly and efficiently to avoid making things worse. This isn’t the first time it has happened, and it is unlikely to be the last. If you have any questions or concerns on how to proceed or who to notify, please start by contacting the Security Incident Response (SIR) team at security.response@utoronto.ca.

SIR can help you address these issues, as well as manage the incident and connect with external or internal people and services that may be required for remediation.

Ransomware attacks that are caused by random infections of one machine will usually be timed randomly. The attackers may have compromised networks (known as an Advanced Persistent threat (APT)) and then launched the attack when they are most likely to cause the greatest damage, before anyone notices. This happens most often after hours or on weekends when no one is home. This type of attack can cause outages. It is best to work calmly and methodically to recover and to identify the root cause so that you do not have to repeat it.

6.2 Identification

It is crucial to quickly identify what has been compromised, and get the right people involved in fixing it. Ransomware can spread quickly through a network. It is important to act quickly to reduce the number of affected devices.

  1. You should identify the devices that have been affected and take immediate action. A message will usually appear on the device’s screen when ransomware attacks are complete. If you see this message, take a picture and immediately disconnect the device from any network. It is best to not turn it off unless necessary as this could damage any forensic evidence.
  2. If you suspect or are certain that a device has been infected by ransomware but is not yet sending any messages, disconnect it as quickly as possible. It is best to not turn it off unless necessary as this could damage any forensic evidence.
  3. It may be simpler to turn off all devices infected by the same virus than to deal with each one individually.
  4. Once ransomware has been removed, disconnect any network shares that are used by confirmed or suspected devices. This should be done as soon as possible, and preferably as soon as possible. Include mirrors and disaster recovery versions.
  5. Identify the data type(s), file share(s), or other systems with which it is directly connected.
  6. This information and the number of affected devices will determine the severity of an incident. This information will be used to determine the severity of the incident. You can choose a more severe severity if you are unsure. However, it will be easier to lower it after further review. It may not get the attention it deserves if it is too low at first.
  7. Once you have identified the severity, notify the people affected. You should have your unit’s incident response team already identified. If not, you can let your boss and your Unit Administrator know. Depending on the severity of the incident, a University-wide or local CSIRT team might be activated. They may also engage other services such as forensics or breach coaches, depending on their needs.
  8. Ransomware can be recovered from backups. You must identify the backups that are available for the affected data and verify that they are still usable.
  9. To the highest level, identify the Who, What, and When of the incident. To get as much information about the attack as possible, you can use local operating system logs and application logs as well as network device logs.
  10. If there are public resources available, and if external resources are required, mobilizing resources should be done immediately to find the information.

It is important to document the incident so that everyone involved is aware of what is going on and helps keep everyone calm. If there are ever questions about whether an incident was handled properly, recording your actions helps to protect you and the university. Follow the proper evidence handling procedures if this leads to legal proceedings. The (SIR) team is available for assistance.

6.3 Containment

The containment stage focuses on reducing damage and preventing further damage. Data can also be retained for future review or use in legal proceedings. Ransomware is often used to temporarily contain attackers.

  1. If the network is not complete, disconnect all infected devices or suspect devices physically or logically.
  2. The ideal state is to keep devices connected but powered off. Sometimes, ransomware unlock keys can remain in memory and can be used to easily restore the device.
  3. To understand the root cause of an attack, it may be necessary to take forensic images of the affected devices. These images should be collected BEFORE mitigation efforts are initiated on the affected system(s). However, it may not always be possible so please try to collect them as clean and unaltered as possible.
    1. Take a snapshot of virtual systems and make sure that it is not accidentally deleted. If possible, include the memory state and the data at rest.
    2. A clone is usually required for physical systems. This should be done in a working state using forensics software. However, an offline copy is possible if this is not possible. Keep the original hard drive, and rebuild the device using a new one if possible.
  4. Review evidence from other sources. Remotely collected system logs and network device logs (firewalls or IDS) can be used.