Resources / Ransomware Playbook

Ransomware Playbook

Ransomware Playbook for Managing Infections

The following post demonstrates the writing process of a ransomware playbook for effective incident response and handling ransomware infections.

Ransomware is a variation of malicious software that encrypts the victim’s files without any consent, then demands a ransom in exchange for the decryption keys. This is a lucrative, multi-million-dollar business model, which targets hundreds of thousands of users each day.

In the previous article, we have learned the writing basics of playbooks. We have covered phishing as the incident scenario that is a quite popular method for delivering malicious pieces of code. In the following post, we are going to link the ransomware playbook together with our previous one, because ransomware heavily relies on phishing emails.

So let’s take an imaginary scenario again. You happen to be working for Royal Acacia again and read a lot about the rapid growth of ransomware lately. You recognize that files becoming unavailable leads to the disruption of normal business activities, therefore it costs money. In order to minimize the impact on the business, you decide to write a playbook for handling ransomware infections in a formalized manner.

Ransomware Cyber-kill Chain

As with the phishing playbook earlier, our first step is the construction of the kill chain again. The purpose of this very important part is to collect and identify the steps need to be taken for a successful ransomware attack.

The cyber kill-chain is roughly the following:

The ransomware executable is delivered via:

Attachments or web links in phishing emails

Malvertising on innocuous web pages

Drive-by downloads (e.g. fake antivirus)

The payload is executed on the end user’s device

The ransomware installs itself on the victim’s computer

The ransomware generates a unique encryption/decryption key pair

The ransomware contacts a C2 server on the Internet to deposit the decryption key

The malware starts encrypting the files on the hard disk, mapped network drives and USB devices with the encryption key

Once the process finishes, the files become inaccessible. The malware places a text file on the desktop and/or a splash screen pops-up with the instructions to pay and restore the original files.

As we learned the last time, we can disrupt the operation of the malicious code in case the chain of events is broken at any location. So let’s quickly assess where and how we can disrupt the ransomware with the existing controls of Royal Acacia!

The ransomware executable is delivered via:

Attachments or web links in phishing emailsBlock incoming emails on the SMTP server, removing emails from user inboxes, warn users to not click on certain links and attachments

The payload is executed on the end user’s device and the ransomware installs itselfApplication whitelisting, identify PCs using the HIDS logs that executed certain files

The ransomware generates a unique encryption/decryption key pair

The ransomware contacts a C2 server on the Internet to deposit the decryption keyIdentify and/or block traffic on NIDS and the proxy

The malware starts encrypting the files on the hard disk, mapped network drives and USB devices with the encryption keyMonitor end-user devices and shared folders for certain file extensions, such as .abc, .xxx, .yyy, .zzz

Once the process finishes, the files become inaccessible. The malware places a text file on the desktop and/or a splash screen pops-up with the instructions to pay and restore the original files.Monitor endpoints for ransomware related text or HTML files in the desktop folder

The Ransomware Playbook

The first version of your playbook is going to be reactive rather than proactive. The main execution trigger of the playbook is employees reporting their files have been encrypted. The main goal is to contain, eradicate and recover from the infections as soon as possible.

However, we will not solely rely on the watchful eyes of our end-users. We are going to create a couple of Indicators of Compromise (IoC) to identify other affected PCs in an automated manner. In addition, we are going to the these IoCs to alert on new infection attempts, too.

Furthermore, we also try to find out how the victim’s device was infected in the first place. With this information, we will try to block the threat on the proxies and SMTP gateways. For the latter, we are going to link the instructions together with the Phishing playbook from earlier.

ID

10002-INV-USER-RANSOMWARE

10002-INV-SIEM-RANSOMWARE

Title

Early Detection and Recovery from Disk-Encrypting Ransomware

Date

<document last modification date>

Owner

<your name>

Objective Statement

This playbook provides practical instructions for handling ransomware related security incidents. The main goal is to take the affected devices from the network as soon as possible to prevent the encryption of the mapped network drives. Incidents are expected to be raised by our end-users.

The secondary purpose of this playbook is building IoCs and deploying them on our security controls across the infrastructure. This is intended to identify existing, and block future ransomware infections in an automated manner.

Scope and Applicability

Company PCs of Royal Acacia employees

Methodology and Procedures

If the ransomware incident is reported by the end-user:

The main goal is to triage the incident and take the computer offline as soon as possible.

User reports an incident over the phone or in an email

Open a ticket in JIRA

If the incident was reported through an email, open the company address book and call the user back

Validate with the user whether it is a genuine ransomware case

Did a window pop up with demanding a ransom?

Has a text file with the instructions been placed on the Desktop?

Have the file extensions been changed to .abc, .xxx or similar?

Are the files unavailable?

Ask the user to disconnect the device from the network. If the user connects to the network with a wireless card, he/she must turn it off.

Take the following details from the end-user and register them into the ticket:

Name of employee

Contact details

Computer name

IP address

What happened? How the problem was identified and when?

Is the user aware he/she clicked on a suspicious link or attachment lately?

Let the user know the JIRA ticket number

Assure the user that someone from IT will come soon to replace the device

Go to the Identifying Other Infected Devices to identify other affected devices on our infrastructure

In parallel, go to Identify the Source of the Infection section to prevent further infections

If the alert is raised by the SIEM:

The goal of these steps is to validate the alert, identify the offending device and taking it off from the network to prevent the mapped network drives to be encrypted.

Validate the incident:

If the alert is based on an IoC, which has been manually added, go to ste

If the alert is genuine, open a ticket in JIRA. Otherwise acknowledge the alert in the SIEM and flag it as false positive.

Identify the affected endpoint:

Get the source IP address from the alert, add the IP to the JIRA ticket

Search in the DHCP logs to identify the computer leasing this IP address

Once you have the computer name, write an email to it@royalacacia.com and ask IT which user owns the computer in question

Open the company address book and call the user on the phone

Inform the user what happened to his/her PC

Ask the user to disconnect the device from the network

Take the following details from the end-user and append them to the ticket:

Is the user aware he/she clicked on a suspicious link or attachment lately?

Let the user know the ticket number from JIRA

Tell the user that someone will come soon to replace the device

Resolve the incident

Identifying Other Infected Devices:

If a device is infected with ransomware, we assume that other PCs on the internal network could also be affected. The objective of the following steps is to generate IoCs from the original victim’s traffic and looking for the same pattern across the infrastructure.

Go to the SIEM

Filter on the detailed proxy logs

Filter on the username of the affected user (all users should be authenticated to the proxy)

Filter out URLs that has been categorised, you should only have uncategorized URLs on the list.

Export your list to a CSV file

Sort the list by URLs, remove duplicates

Try to find URLs with 2-3 of the following properties:

Weird URLs

IP address in the URL

Random characters in the hostname of the URL (e.g. http://fbdfsufsuehrtgkf.com)

Search for the host part in the proxy logs to retrospectively identify other PCs visiting the malicious URL

If you find any other PCs affected, open a new JIRA ticket and apply the If the alert is raised by the SIEM process

Add a new rule to the SIEM in order to monitor the proxy logs for new visitors

If the attachment in the email was malicious:

In case a file hash was flagged as suspicious,

Get the SHA256 hash uploaded earlier from JIRA

Go to the SIEM

Search in the proxy logs to check if any of the file downloads has involved the same file with the SHA256 hash

If you identify other computers that downloaded the same file, follow the If the alert is raised by the SIEM process

Final Steps

We use the Mitigation of Phishing Campaigns runbook to block further emails coming in

Open a new JIRA ticket

Add the IoCs to the new ticket

Link the old ticket together with the new ticket

Resolve the old JIRA ticket

Open the Mitigation of Phishing Campaigns (10001-INV-USER-SOCIAL) playbook from the playbook repository

Block emails part of the phishing campaign by following the instructions in the other playbook

Summary

In this article, you have developed the first draft of your playbook for thwarting ransomware infections at Royal Acacia. The playbook’s main priority was to take the infected PCs off the network as soon as possible.

The second objective was to profile the C2 traffic associated with the ransomware infected device for identifying other cases at your organization. In order achieve that, you created IoCs and deployed them onto some of your existing controls. Secondly, you have used these IoCs to identify future infection cases.

The last objective was to identify the delivery method of the ransomware. As the common delivery method is web and emails, you have used the associated logs to find and block the malicious traffic.

We use cookies to understand how you use our site and to improve your experience. This includes personalizing content and resources. By continuing to use our site, you accept our use of cookies. Learn more.