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:

  1. The ransomware executable is delivered via:
    1. Attachments or web links in phishing emails
    2. Malvertising on innocuous web pages
    3. Drive-by downloads (e.g. fake antivirus)
  2. The payload is executed on the end user’s device
  3. The ransomware installs itself on the victim’s computer
  4. The ransomware generates a unique encryption/decryption key pair
  5. The ransomware contacts a C2 server on the Internet to deposit the decryption key
  6. The malware starts encrypting the files on the hard disk, mapped network drives and USB devices with the encryption key
  7. 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!

  1. The ransomware executable is delivered via:
    1. Attachments or web links in phishing emails
      Block incoming emails on the SMTP server, removing emails from user inboxes, warn users to not click on certain links and attachments
    2. Malvertising on innocuous web pages
      Block malicious URLs on the web proxy, identify computers that visited malicious websites on certain URLs using the proxy logs
    3. Drive-by downloads (e.g. fake antivirus)
      Block malicious URLs on the web proxy, identify computers that visited malicious websites using the proxy logs, deploy custom AV signatures to block certain files to be downloaded, identify PCs with ETDR that downloaded files with certain IoCs

 

  1. The payload is executed on the end user’s device and the ransomware installs itself
    Application whitelisting, identify PCs using the HIDS logs that executed certain files
  2. The ransomware generates a unique encryption/decryption key pair
  3. The ransomware contacts a C2 server on the Internet to deposit the decryption key
    Identify and/or block traffic on NIDS and the proxy
  4. The malware starts encrypting the files on the hard disk, mapped network drives and USB devices with the encryption key
    Monitor end-user devices and shared folders for certain file extensions, such as .abc, .xxx, .yyy, .zzz
  5. 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.

  1. User reports an incident over the phone or in an email
  2. Open a ticket in JIRA
  3. If the incident was reported through an email, open the company address book and call the user back
  4. Validate with the user whether it is a genuine ransomware case
    1. Did a window pop up with demanding a ransom?
    2. Has a text file with the instructions been placed on the Desktop?
    3. Have the file extensions been changed to .abc, .xxx or similar?
    4. Are the files unavailable?
  5. 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.
  6. Take the following details from the end-user and register them into the ticket:
    1. Name of employee
    2. Contact details
    3. Computer name
    4. IP address
    5. What happened? How the problem was identified and when?
    6. Is the user aware he/she clicked on a suspicious link or attachment lately?
  7. Let the user know the JIRA ticket number
  8. Assure the user that someone from IT will come soon to replace the device
  9. Go to the Identifying Other Infected Devices to identify other affected devices on our infrastructure
  10. 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.

  1. Validate the incident:
    1. If the alert is based on an IoC, which has been manually added, go to ste
    2.  If a URL was flagged from the proxy logs, check why:
      1. Go to https://otx.alienvault.com and search for the hostname
      2. Check reputation with any of the tools on https://zeltser.com/lookup-malicious-websites/
    3. If the URL was flagged from the IDS logs, verify why the file hash was flagged
      1. Go to https://www.virustotal.com and search for the file hash
      2. Go to https://otx.alienvault.com and search for the file hash
  2. If the alert is genuine, open a ticket in JIRA. Otherwise acknowledge the alert in the SIEM and flag it as false positive.
  3. Identify the affected endpoint:
    1. Get the source IP address from the alert, add the IP to the JIRA ticket
    2. Search in the DHCP logs to identify the computer leasing this IP address
    3. Once you have the computer name, write an email to it@royalacacia.com and ask IT which user owns the computer in question
  4. Open the company address book and call the user on the phone
  5. Inform the user what happened to his/her PC
  6. Ask the user to disconnect the device from the network
  7. Take the following details from the end-user and append them to the ticket:
    1. Is the user aware he/she clicked on a suspicious link or attachment lately?
  8. Let the user know the ticket number from JIRA
  9. Tell the user that someone will come soon to replace the device
  10. 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.

  1. Go to the SIEM
  2. Filter on the detailed proxy logs
  3. Filter on the username of the affected user (all users should be authenticated to the proxy)
  4. Filter out URLs that has been categorised, you should only have uncategorized URLs on the list.
  5. Export your list to a CSV file
  6. Sort the list by URLs, remove duplicates
  7. Try to find URLs with 2-3 of the following properties:
    1. Weird URLs
      1. IP address in the URL
      2. Random characters in the hostname of the URL (e.g. http://fbdfsufsuehrtgkf.com)
      3. URL contains lots of random letters and/or numbers (e.g. http://ezglobalmarketing.com/wp-content/themes/r.php?D0B1745184D4B19325F8CA239D78E804FD704B43166264942AB4248A83B5E7984901B8CB83E4B038)
    2. Requests to Tor2Web (e.g. https://3fdzgtam4qk625n6.fi/)
    3. POST requests
    4. Weird User-Agent strings, such as
      1. IE6 (e.g. Mozilla/5.0 (compatible; MSIE 6.0; Windows NT 5.1))
      2. Programmatic libraries (e.g. python-requests/1.2.0)
      3. dJava (e.g. Java/1.6.0_13)
    5. Missing User-Agent
  8. If you find suspicious C2 server URLs, try to validate them on http://otx.alienvault.com
  9. Compile a final list of suspicious URLs
  10. Upload the list to the JIRA ticket
  11. Continue with the Generating IoCs from URLs and Hashes section below

Generating IoCs from URLs and Hashes:

This process is for generating IoCs from the flagged URLs. These patterns will be used to block the URLs on the proxy and identify other affected machines.

  1. Get the list of flagged URLs/hashes from the JIRA ticket
  2. Subscribe to Threat Intelligence (TI) feed:
    1. Go to http://otx.alienvault.com and search for URL
    2. Click on Subscribe in order to subscribe to the feed. This will install the relevant IoCs from OTX into our SIEM automatically.
  3. If none of the IoCs are on the TI feed, you need to generate IoCs manually:
    1. Go to the proxy logs again
    2. Find 2-3 properties associated with the flagged URL, such as:
      1. The request is POST
      2. The User-Agent field is dodgy (Java, Python, IE6 etc.)
      3. URL contains more than 128 random characters
      4. URL contains .php
      5. URL contains lots of slashes (/)
      6. URL contains WordPress related things (wp-content)
      7. URL contains dodgy TLDs (for instance .tk, .ru)
    3. Test your assumption on the proxy logs in the SIEM. Use your pattern and check how many false positives and true positives it produces.
  4. If the pattern is good enough, append your results to the JIRA ticket
  5. Continue with the Deploying the IoCs section below

Deploying the IoCs:

  1. Deploy a new rule to the SIEM, this will alert new infection attempts in the future
  2. Search for the pattern in the proxy logs in order to identify other computers already affected. If you identify other affected PCs
    1. Open a new JIRA ticket
    2. Execute the steps in the If the alert is raised by the SIEM section
  3. Send the patterns to it@royalacacia.com and ask IT to block these URLs on the proxy
  4. Resolve the incident

 

Identify the Source of the Infection:

The purpose of the following instructions is to assess how the end-user device got infected in the first place. We are going to use this information to block the malicious emails or URLs as necessary.

Investigate whether the malware has been delivered by email to the victim:

  1. Go to the SIEM
  2. Filter on the email logs associated with the user from the last 3 days
  3. Filter again on emails where the recipient was the victim
  4. Remove email logs where the sender was from the company (*@royalacacia.com)
  5. Export the list of emails into a CSV file. It should only contain emails sent to the victim from the Internet within the last 3 days.
  6. Send the CSV file to it@royalacacia.com and ask them to retrieve the full emails from the user’s inbox. Upload the CSV to the ticket, too.
  7. Once you get the emails in a zip file, go through them to identify suspicious links or attachments.
    1. Look for links that does not point to the same URL displayed on the screen (e.g. <a href=”http://malware.com”>http://www.bbc.co.uk</a>)
    2. Check the domain in the ‘From:’ field correspond to the topic of the email (e.g. package delivery notification emails from UPS will not come from john@mypersonalblog.com)
    3. Scan suspicious URLs as necessary on:
      1. http://www.virustotal.com
      2. http://www.phishtank.com
      3. or any other tool from https://zeltser.com/lookup-malicious-websites/
  1. If you identify a suspicious URL
    1. Download the malicious file with ‘curl’
    2. Upload the file to http://www.virustotal.com and/or to the sandbox on http://malwr.com
    3. If you suspect the file is malicious (e.g. it was flagged by VirusTotal or opens a lot of network connections), generate an SHA256 hash
    4. Checking the email attachments>
    5. Upload the file to the following services. Be careful, do not upload files if they might contain sensitive data!
      1. http://www.virustotal.com
      2. http://malwr.com
    6. If you suspect the file is malicious (e.g. it was flagged by VirusTotal or opens a lot of network connections)
      1. Rename the file as: virus_<filename>.<extension>_invalid
      2. Generate SHA256 hash
      3. Attach the file and hash to JIRA
  1. Go to the Generating IoCs from Phishing Emails Otherwise continue below to check on the proxy logs.

Investigate whether the victim’s PC has been infected by an exploit kit/drive-by download:

  1. Go to the SIEM
  2. Filter on the proxy logs from the last 3 days
  3. Filter on the username of the affected user (all users should be authenticated to the proxy)
  4. Filter out URLs that has been categorised, you should only have uncategorized URLs on your list.
  5. Export list to CSV
  6. Sort the list by URLs, remove duplicates
  7. Search for suspicious URLs, such as:
    1. IP address in the URL
    2. Random characters in the hostname of the URL (e.g. http://asdheguhadaasd.com)
    3. URL contains lots of random letters and/or numbers
    4. WordPress sites are involved (wp-content …)
  8. Get the hash from the log if a file download was involved
  9. If you found some suspicious URLs/hashes, and try to validate them on:
    1. http://otx.alienvault.com
    2. http://www.virustotal.com
    3. Visit the suspected URL in the sandbox on http://anubis.iseclab.org
  10. In case you have high confidence in some of the URLs, compile a list and upload it to JIRA.
  11. Go to the Generating IoCs from URLs and Hashes for blocking them

Generating IoCs from Phishing Emails:

This process is for generating IoCs from the identified phishing emails to block further emails.

If the URL in the email was malicious:

In case a single URL was flagged as suspicious

  1. Generate IoC from the host part of the URL (http://malware.com/index.php?key=3werw234234fsdfsdf ècom)
  2. Ask IT on it@royalacacia.com to block the host part of the URL on the proxy
  3. Search for the host part in the proxy logs to retrospectively identify other PCs visiting the malicious URL
  4. If you find any other PCs affected, open a new JIRA ticket and apply the If the alert is raised by the SIEM process
  5. 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,

  1. Get the SHA256 hash uploaded earlier from JIRA
  2. Go to the SIEM
  3. Search in the proxy logs to check if any of the file downloads has involved the same file with the SHA256 hash
  4. 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

  1. Open a new JIRA ticket
  2. Add the IoCs to the new ticket
  3. Link the old ticket together with the new ticket
  4. Resolve the old JIRA ticket
  5. Open the Mitigation of Phishing Campaigns (10001-INV-USER-SOCIAL) playbook from the playbook repository
  6. 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.

Contributed Article by Gabor Szathmari