Playbook – Ransomware

<Insert Corporate Logo>

Document Version1.1 Date

Change Log

Date Version Author Change

3/12/2016 1.0 Josh Geno Complete rebuild from prior “top-down” format. Re-written into flowchart
format with detailed instructions in playbook doc
8/14/2018 1.1 Josh Geno Changed to generic tool/process/department references; updated resources
that have changed versions or have been superseded
Table of Contents
Introduction..................................................................................................................................................................... 4
License ......................................................................................................................................................................... 4
Incident Lifecycle ............................................................................................................................................................. 5
Prepare ............................................................................................................................................................................ 6
A1 ............................................................................................................................................................................ 6
A2 ............................................................................................................................................................................ 7
A3 ............................................................................................................................................................................ 8
A4 ............................................................................................................................................................................ 8
A5 ............................................................................................................................................................................ 9
A6 .......................................................................................................................................................................... 10
Detect ............................................................................................................................................................................ 11
B1 – B10 ................................................................................................................................................................. 11
B11 ........................................................................................................................................................................ 12
B12 & B14 .............................................................................................................................................................. 12
B13 ........................................................................................................................................................................ 13
Triage / Prioritize ........................................................................................................................................................... 14
Note Regarding Rapid Assessment Methodologies ................................................................................................. 14
Checkbox Assessment ............................................................................................................................................ 14
Weighted Assessment ............................................................................................................................................ 15
C1 – C8 ................................................................................................................................................................... 16
C9 – C15 ................................................................................................................................................................. 17
C16 - C18 ................................................................................................................................................................ 18
C19 ........................................................................................................................................................................ 19
Analyze .......................................................................................................................................................................... 20
D1 .......................................................................................................................................................................... 20
D2 .......................................................................................................................................................................... 20
D3 .......................................................................................................................................................................... 21
D4 .......................................................................................................................................................................... 21
D5 .......................................................................................................................................................................... 22
D6 .......................................................................................................................................................................... 23
D7 .......................................................................................................................................................................... 23
D8 .......................................................................................................................................................................... 24
Contain/ Eradicate/ Recover .......................................................................................................................................... 25
E1 & E2 .................................................................................................................................................................. 25
Page 2 of 38
 E3........................................................................................................................................................................... 26
E4........................................................................................................................................................................... 27
E5........................................................................................................................................................................... 28
E6........................................................................................................................................................................... 29
E7........................................................................................................................................................................... 29
E8........................................................................................................................................................................... 30
E9........................................................................................................................................................................... 30
E10......................................................................................................................................................................... 31
E11 & E12............................................................................................................................................................... 31
E13 & E14............................................................................................................................................................... 32
E15......................................................................................................................................................................... 32
E16 & E17............................................................................................................................................................... 33
E18......................................................................................................................................................................... 33
E19......................................................................................................................................................................... 34
E20......................................................................................................................................................................... 34
Post-Incident ................................................................................................................................................................. 35
F1 ........................................................................................................................................................................... 35
F2 ........................................................................................................................................................................... 36
F3 ........................................................................................................................................................................... 36
F4 ........................................................................................................................................................................... 37
F5 ........................................................................................................................................................................... 37
F6 ........................................................................................................................................................................... 38

Page 3 of 38
Introduction

This playbook is the text compendium to the ransomware response flowchart.

It provides needed details, explanations, and external resource linksfor the various components called out in the
flowchart. This guideand flowchart are not intended to serve as a full Security Incident Framework or response process,
it contains components specific to ransomware response.

To maximize the value of the response flowchart and this guide, it must be modified to reflect your organization’s
incident response process/framework, the roles and responsibilities of individuals in your organizational structure,
security tools, and TTPs (Tactics, Techniques, and Procedures) present in your environment.

While ransomware has received a lot of attention lately, it is not new. The first recorded attack goes back to 1989.
(https://www.beckershospitalreview.com/healthcare-information-technology/first-known-ransomware-attack-in-1989-also-targeted-
healthcare.html)Ransomware authors have the advantage of decades of prior art to drive innovations today. Be prepared.

The author is assumes no liability for the content, quality, relevance, fitness for purpose, or accuracy of any materials
used in this document and assumes no liability for any real or potential harms associated with use of the document or
flowchart.

License
This work is licensed under Creative Commons Attribution-ShareAlike 4.0

https://creativecommons.org/licenses/by-sa/4.0/

Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable
manner, but not in any way that suggests the licensor endorses you or your use.

ShareAlike — If you remix, transform, or build upon the material, you must distribute your contributions under the same license as the original.

No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license
permits.

Copyright 2016Joshua C Geno

Page 4 of 38
Incident Lifecycle

This ransomware response guide uses a standard incident lifecycle including preparations to prevent, detect, and
respond to a ransomware threat. Post-incident lessons learned are fed back into the lifecycle as continuous
improvement measures.

Again, the flowchart and guide are not meant to capture the entire incident response function, only those components
specific to detection and response for a ransomware incident. For a full IR framework, reference SANS Incident Handlers
Handbook, Carnegie Mellon’s Handbook for Computer Security Incident Response Teams, or ENISA’s Good Practice
Guide for Incident Management.

Incident Lifecycle

Prepare

Contain,
Triage &
Detect Analyze Eradicate, Post Incident
Prioritize
Recover

Page 5 of 38
Prepare

From Post- Prepare Start

Incident

The prepare phase includes activities and protective measures that should be put in place prior to an incident. It also
includes activities and protective measures incorporated from post-incident activities following an incident.

The more time analysts and engineers spend in prepare, the less time they’ll spend in response when an actual
ransomware incident happens.

A1 - Identify and
Document Defensive
Measures Against
Ransomware and the
Alerts They Produce

A1- In this step the organization should take a close look at their inventory of security and infrastructure tools that can
detect ransomware or aid the investigation of a ransomware incident. Look at the threat carefully from a defenders
point of view. (blue team) Document these tools and a few samples of the type of alert or notification that can be
expected. Document sample investigation queries/reports/etc. that engineers can run for each tool with ‘how to’
instructions so there is a quick reference during an incident. Collect any supporting information (network diagrams,
crown jewel assessments, asset inventory, etc.) that will help with decisions during an incident and regularly update
them.

This information can then be called out inmultiple phases:

 Later in the prepare phase to fill gaps and bolster response capabilities
 The detect phase as a feed-in for threat indicators/alerts
 The analyze phase as tools to help positively ID the ransomware
 The contain/eradicate/recover phase as tools to help isolate bad code or infected systems;remove malicious
code, or blocking malicious network traffic.

In all phases the output of one tool, such as a hash of the ransomware executable, can be used to enrich or correlate
information in other tools. This will be highly dependent on the tools your organization has implemented and the level
of automation between the tools.

Don’t forget to include non-technical alerts, such as user reports or external notifications from business partners or law
enforcement.

Resources:

https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf (page 36)

https://www.nasa.gov/pdf/589502main_ITS-HBK-2810.09-02%20%5BNASA%20Information%20Security%20Incident%20Management%5D.pdf (page 44)

https://www.owasp.org/images/6/64/Anti-RansomwareGuidev1-7.pdf

https://github.com/certsocietegenerale/IRM/blob/master/EN/IRM_English_Pack.zip (IRM 17 - Ransomware)

Page 6 of 38
 A2 - Identify and
Document Ransomware
Adversarial Playbook/
TTPs/IOCs

A2- This step is about looking at the ransomware threat from the attacker’s point of view. (red team)

The more responders understand how the organization can be attacked the better they can fill gaps, tune security tools
and procedures, and the better they can respond to an attack. Collect and share adversarial playbooks from actual
attacks. Research TTPs related to ransomware. Collect IOCs (Indicators of Compromise) and search for them in the
environment.

Verizon releases an annual data breach report that contains details of actual attacks. It is an excellent source of
adversarial playbooks, which they call attack patterns. There are many other security researchers that release similar
reports.

There are also many public sources of IOCs such as “IOCs”, FireEye’s publicly shared IOC repository. Free/Open source
tools to scan the environment include Redline and Loki.

Resources:

https://www.sans.org/reading-room/whitepapers/incident/enterprise-survival-guide-ransomware-attacks-36962 (page 7)

http://www.ten-inc.com/presentations/invincea1.pdf

https://www.owasp.org/images/6/64/Anti-RansomwareGuidev1-7.pdf

https://github.com/certsocietegenerale/IRM/blob/master/EN/IRM_English_Pack.zip (IRM 17 - Ransomware)

https://news.sophos.com/en-us/2015/03/03/anatomy-of-a-ransomware-attack-cryptolocker-cryptowall-and-how-to-stay-safe-infographic/

https://ransomwarewatch.com/ransomware-info/how-ransomware-works/

https://ransomwaretracker.abuse.ch/tracker/

https://www.cyber45.com/ransomware-tracker

https://goo.gl/b9R8DE

Page 7 of 38
 A3 - Train Employees to
Identify Ransomware
Indicators and How to
Report an Infection as
Part of an Awareness
Program

A3 - If your organization has not already done so, implement an awareness program and include ransomware training as
part of that awareness program.At minimum, every person in the company should be aware of basic indicators of
ransomware/malware infection and know how to report it to IT security. The program should also stress the avoidance
of clicking unknown links or opening email attachments that they were not previously expecting.

Resources:

https://www.pcisecuritystandards.org/documents/PCI_DSS_V1.0_Best_Practices_for_Implementing_Security_Awareness_Program.pdf

https://insights.sei.cmu.edu/insider-threat/2017/06/security-awareness-and-training-part-9-of-20-cert-best-practices-to-mitigate-insider-threats-series.html

https://www.csoonline.com/article/2133408/data-protection/network-security-the-7-elements-of-a-successful-security-awareness-program.html

https://www.wombatsecurity.com/blog/security-awareness-training-best-practices-to-consider

A4 - Build, Maintain, and

Test Ransomware
Prevention, Detection,
Mitigation, and Response
Capabilities – Fill Any
Identified Gaps

A4 - In this stage, run tests against the previously identified security tools and TTPs to gauge detection and response
capability. Make sure analysts and responders are getting expecteddetections and alerts. There are several sources for
fake malware, such as KnowBe4’s ransomware simulator or Stackhackr. To test response capabilities, run tabletop
exercises. Identify gaps in detection, alerting, and response and make plans to fill them.

Resources:

https://www.knowbe4.com/ransomware-simulator

https://stackhackr.barkly.com/builder

https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf (page 61)

https://www.mitre.org/sites/default/files/publications/pr_14-3929-cyber-exercise-playbook.pdf

Page 8 of 38
 A5 - Prepare Internal
Stakeholders and External
Resources (legal council,
law enforcement, etc.)
Prior to an Actual Event

A5 - The first time incident responders contact internal teams or external resources shouldn’t be during an actual
incident. Stakeholders, such as management, other corporate teams, internal privacy/compliance, internal or external
legal resources,SecaaS/incident response vendors, etc. should be regularly engaged to discuss the role they play in
incident response, and regularly briefed about the Security Operations Center activities. Ideally, they should also be
included in response tests or tabletop exercises.

External resources, such as local, state, or federal law enforcement are likely not able to be part of your internal
response testing, but should still be considered as part of the process and called out in appropriate steps. It is beneficial
to reach out to them every couple of years to maintain general awareness.They can help you understand who can help
with various problems and what resources are available.

Sometimes law enforcement shows up to local security conferences or have their own security events. Make use of
these opportunities.

Document stakeholders and what role they may be called to play. Communicate incident response expectations and find
out what expectations they have of the SOC when requesting resources during an incident. Keep stakeholders informed
as to the activities and capabilities of the SOC. See page 11 of the agoria.be document below for an example of a Skills /
Responsibilities / Roles chart.

Resources:

https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf (page 18)

https://www.americanbar.org/groups/professional_responsibility/publications/professional_lawyer/2016/volume-24-number-3/preventiand-response-twopronged-
approach-cyber-security-and-incident-response-planning.html

https://www.sans.org/reading-room/whitepapers/legal/legal-considerations-creating-incident-response-plan-37487

https://www.agoria.be/upload/agoriav3/Cyber-Security-Incident-Management-Guide-2015.pdf (pages 11 and 13)

https://www.halkynconsulting.co.uk/a/2015/12/incident-response-key-stakeholders/

Page 9 of 38
 A6 - Maintain Superior
Security Hygiene
(Patching, Backups,
Access Control, etc.)

A6–The ability to repel or recover from a ransomware attack hinges on your organization’s ability to maintain superior
security practices.

At a high level, organization’s need to be able to:

 Protect computing resources and data through technical (anti-malware, IPS) and non-technical (awareness
program, rule of least privilege) means.
 Have the ability to restore encrypted or corrupted data to avoid being pressured to pay the ransom.
 Continuously reduce your organization’s attack surface. (patching, penetration testing)

Many security compliance frameworks will have these security hygiene measures documented, keep this information
available and updated. If your organization does not have this documentation available, document it here for future
reference.

Resources:

https://www.fbi.gov/file-repository/ransomware-prevention-and-response-for-cisos.pdf/view

https://blog.malwarebytes.com/101/2016/03/how-to-beat-ransomware-prevent-dont-react/

https://www.csoonline.com/article/3257704/ransomware/5-tips-to-help-you-block-ransomware.html

https://www.csoonline.com/article/3251827/ransomware/ransomware-prevention-is-insider-threat-mitigation.html

https://us.norton.com/internetsecurity-malware-7-tips-to-prevent-ransomware.html

https://www.tripwire.com/state-of-security/security-data-protection/cyber-security/22-ransomware-prevention-tips/

https://spinbackup.com/blog/wannacry-ransomware-enhanced-cyber-hygiene/

https://www.csoonline.com/article/3287099/ransomware/10-ways-to-prevent-detect-and-recover-from-ransomware-and-zeroday-threats.html

https://duo.com/decipher/security-hygiene-tips-to-prevent-malware-infection-and-stop-lateral-movement

https://digitalguardian.com/blog/ransomware-protection-attacks

Page 10 of 38
Detect

The detect phase covers receipt of an alert or notification and the initial data gathering to validate that an actual
ransomware incident has occurred.

B6 - Network
Security Solution
Alert; Ransomware B7 - User Reports
B5 - Unusual CPU/ Detection Rule, Unusual Activity
Memory Utilization Unusual Web After Running An
Alerts from Browsing Activity Executable File (VBS,
Enterprise (TOR, I2P, Bitcoin Doc With Macro,
B4 - Unusual Monitoring Tools Payment), Traffic On JAR, PPT With B8 - User Reports
Quantity of Files Known C2 Ports or Macro, etc.) Files Not Available,
Being Modified on To Known C2 Replaced With
Network Share(s) or Internet Hosts Known Ransomware
Local Drives File Extensions

B9 - User Reports
B3 - User Reported
Unusual Email With
Ransom Message
Attachment

B2 - Endpoint B10 - Alert From 3rd

Security Solution Party (Business
Alert Partner, Law
Enforcement,
Vendor, or SecaaS)

B1 - Threat Indicators/
Alerts

Incident Start /
Threat Detected

B1 – B10 – The threat indicators, technical alerts, and manual notifications identified in A1 are inputs to B1. Many of
these are common among organizations and should appear in every ransomware playbook. Some are specific to the
tools, 3rd parties, and organizational structure of a single organization. Take time to periodically review these inputs to
prune or add entries as your available tools and TTPs change and make sure they all work as expected.

If the source or content of one or more of the inputs (B2 – B10) is not crystal clear to everyone on the security team, use
the information identified in A1 to individually document the source and alert in this part of this document to aid
responders.

Once an indicator is observed, alert is triggered, or notification is received, incident response is initiated.

Resource:

https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf(page 34)

Page 11 of 38
 B11 - Gather Initial
Suspect Files/Registry
Entries/
Attachments,etc.

B11 – Utilize the information and context available in the indicator/alert/notification to guide the initial data gathering
activities. For instance, if you received an alert from a network tool that an endpoint is beaconing to a C2 internet host,
use the source IP address to identify the affected endpoint. From there, use available tools to evaluate the executables
running and network traffic being generated. If remote tools are not available in your environment, send someone with
appropriate skills to put hands on the keyboard to gather suspect registry entries, files/hashes, email attachments, web
history entries, packet captures, screenshots of ransom notes, etc.

If the cause of the indicator/alert/notification is not immediately obvious, utilize automated scripts to rapidly collect
indicators, such as Bambiraptor.

https://www.brimorlabsblog.com/2016/12/live-response-collection-bambiraptor.html

Gather as much information as is necessary to make a determination as to whether the indicator/alert/notification is a

false-positive or an actual incident. Being familiar with ransomware infection and operation (A2 above) methods will
help responders zero in on relevant facts quickly.

Your organization may have tools and TTPs related to gathering initial data, if so document them here.

Resource:

https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf(page 34)

B12 – Does the Initial

B14 -Document as a
No Data Gathered Indicate
False Positive an Actual Incident?

To Post
Incident

B12& B14– If there is no evidence of a ransomware infectionafter the initial data gathering and the
indicator/alert/notification can be attributed to a false-positive (user observed strange behavior and called ‘just in case’,
new rule from a network tool vendor, etc.), document the incident as a false positive and move to F4 in Post-Incident.

Post-Incident is still required for false-positives as documentation may need to be updated, tools may need to be tuned
or rules adjusted, and stakeholders (system owners, end users) will certainly need to be told that there is no security
problem.
Page 12 of 38
B13 – If enough evidence has been gathered to make a determination that one or more endpoints may have a
ransomware infection.Isolate the suspect hosts, either via remediation VLAN so that you can use automated remote
tools to investigate and remediate the infection, or from all wireless and wired networks, and remove/unplug directly
attached devices.(USB storage, IoT, PLC, printers, etc.)Any external device that was attached should also be considered
to be infected until the capabilities of the ransomware are known.

At this stage it is likely not known exactly what family/variant of ransomware has infected the host(s) so the spreading
mechanisms, encryption mechanism (specific file types, hard drive file table, etc) and data stealing capabilities are not
yet known.

Ideally the devices physically removed from the network should be pulled and acquired by responders to prevent
‘proactive’ users from plugging them back in. A good stakeholder communication plan as part of your incident response
function and a sticky note on the device or monitor (where possible) will go a long way toward keeping potentially
infected devices out of the production network until the device can be acquired or remediated.

Your organization may have tools and TTPs available to remotely help with isolation to a remediation VLAN, if so
document them here.

Resource:

https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf(page44)

Page 13 of 38
Triage / Prioritize

The Triage/Prioritize phase covers the assessments that need to be quickly performed in order to prioritize the
new/current incident in relation to other incidents already in the security incident queue.

This is also the phase where it is determined whether or not internal or external teams need to be notified of an
incident. This playbook doesn’t cover the specifics of who should be contacted and what information to share with
them; that is for your larger Incident Response Program to decide. This is the place we call out as appropriate to make
the determination as to whether the notification portions of the Incident Response Program require action.

Note Regarding Rapid Assessment Methodologies

The two rapid assessments below, C1 and C9, can be effectively performed two ways. Which way your organization uses
will be determined by organizational needs for the level of granularity required and rate of incidents your organization
handles at atime.

Checkbox Assessment
For organizations that handle few incidents at a time, an express assessment method can be used as a ‘tie-breaker’ for
those few occasions where there is more than one incident in process, but there aren’t enough resources to service all
of them. Each of the inputs is turned into a question and given a checkbox where it is checked if the condition is true. At
the end you simply add up all the checked boxes for a score.The higher the score, the higher the priority.

Estimated number of endpoints isn’t easy to capture in a checkbox, so you have to reframe the question to “Are more
than X endpoints involved?” Obviously this isn’t a one size fits all situation; you will have to come up with a number for
your organization where more than that number signifies a critical situation.

The others are easy to turn into questions, such as:

 Could this incident trigger fines or judgements against the organization?

 Could this incident lead to data compromise or breach?
 Is sensitive data potentially involved?

A simple spreadsheet is enough to capture responses and final score. Alternately, many case management systems allow
you to setup data capture steps as part of an IR workflow.

Page 14 of 38
Weighted Assessment
For larger organizations that handle many incidents at a time and are able to run multiple responses at a time, weighted
assessment provides a better level of granularity for assigning priority and the order in which incidents will be taken
from the queue.

This methodology can also spark holy wars as to what weight should be given to each input. To get started stakeholders
have to come together and agree on the weight of each question posed by each input. I recommend a weight of 1 -10.
Invariably, one stakeholder will feel that one of the inputs, say Loss of Productivity, should be a 1 whereas a different
stakeholder feels it should be a 10. However your organization gains consensus for these situations, the end goal is the
same; weight each of the inputs so that when it’s question is checked, that weight is added to the total. Incidents can
then be listed highest to lowest score where highest score is highest priority and will be taken by the next available
responders from the queue.

Page 15 of 38
 C8 - Loss of
Competitive
Advantage

C7 - Loss Due to
Legal Response

C6 - Loss of
Productivity

C5 - Loss to
Replace or Repair

C4 - Fines/
Judgements

C3 -
Reputation
Damage
C2 - Probable
Loss Magnitude
Assessment

C1 - Evaluate Loss
Expectation

C1 – C8–The first rapid assessment concerns the organization’s expectation of potential loss due to the incident. In case
the meanings of each input are not clear, here is a brief explanation of each:

 Reputation Damage – Potential for loss to repair the organization’s reputation (PR firm, advertising, etc.) May
include indirect losses of lost business due to reputation damage.
 Fines/Judgements – Potential losses incurred by violating contractual agreements where there is a financial
penalty, or regulatory fines.
 Loss to Replace or Repair – Potential losses incurred when systems are not available while being replaced,
remediated, etc.
 Loss of Productivity – Potential loss of man-hour productivity while systems or hardware are not available for
use.
 Loss Due to Legal Response – Potential loss incurred to hire lawyers, pay court fees, or potential punitive
judgements.
 Loss of Competitive Advantage – Potential losses due to intellectual property or corporate secrets being leaked.

Tally the loss expectation score using the chosen assessment method above, it will be needed in C16.

Resource:

https://www.fairinstitute.org/blog/a-crash-course-on-capturing-loss-magnitude-with-the-fair-model

Page 16 of 38
 C11 – Possibility of
Data Compromise/
Breach

C12 – Estimated
number of
Endpoints Involved

C13 -
Customer Impact

C14 - Sensitive
Data Involved

C15 -
Recoverability

C10 - Severity
Assessment

C9 - Determine Severity
Classification and
Notification
Requirements

C9 – C15–The second rapid assessment covers a severity assessment that will later be added to the loss assessment to
determine priority. The severity assessment covers attributes of the incident itself rather than the business impact of the
incident.

Additionally, it is time for responders to decide if external notifications are required or external/3rd party resources
should be engaged since questions are already being asked about data compromise/breach and whether or not sensitive
data is involved.

In case the meanings of each input are not clear, here is a brief explanation of each:

 Possibility of Data Compromise / Breach – Possibility that corporate data could be stolen, tampered with, or
deleted (or not recoverable due to ransomware encryption). The systems involved and what function they serve
should be taken into account.
 Estimated Number of Endpoints Involved – An order of magnitude assessment that is relative to the size of your
business. 1 infected workstation in an organization of 10 total workstations is a much larger percent of infected
hosts than 1 in a 50,000 workstation organization.
 Customer Impact – The possibility that the incident will impact your customers in some way. This could be direct
financial impact or indirect impacts, such as a service being unavailable.
 Sensitive Data Involved – The possibility that protected classes of data (health, education, govt ID) or sensitive
internal data (corporate secrets, intellectual property) could be affected by the incident.
 Recoverability – The relative possibility that damage caused by the incident can be reversed, rebuilt, or halted.
Check the box on the checklist if recoverability is difficult, time consuming, resource consuming, or impossible.

Page 17 of 38
Tally the severity assessment score using the chosen assessment method above, it will be needed in the next step. If the
decision has been made that notifications are required or additional resources need to be pulled in, follow the
procedures in your organization’s larger Incident Response Program to engage them.

C16 – Determine
Priority; Document
Assessments and
Priority

To C17 - Is this incident

Analyze Yes higher priority than items
in queue?

No

C18 - Add to
Incident Queue

C16 - C18–Add the two scores calculated in C1 and C9. This is the incident’s priority score. Document this score and the
two component spreadsheets from C1 and C9 in the incident documentation (Your Incident Response Program should
have procedures and templates for this) and in your ticketing / case management system.

If this incident rates higher than the other items already in the queue (ransomware usually rates extremely high) then it
takes precedence over other incidents and progresses to the Analyze phase. If it rates lower than other incidents in the
queue, is added to the queue for later investigation and remediation. Any incident artifacts (data gathered, alerts, etc.)
should be documented for later retrieval per your Incident Response Program’s requirements.

Page 18 of 38
 C19 - Incident
Queue

To
Analyze

C19 – For incidents in the queue where responder resources have become newly available to investigate the next
incident, this is the place in the playbook where the queue feeds in. Any incident in the queue will have already been
through the playbook up to this point.

Responders take the incident with the highest priority score in the queue and advance it to Analyze.

Page 19 of 38
Analyze

In the Analyze phase responders will utilize internal and external resources to identify the ransomware, associated
indicators of compromise, and its capabilities. At times it will not be possible to get a positive ID of a previously known
variant of ransomware.In this case behavioral analysis and/or reverse engineering techniques will be employed to gather
information. This information will be used in the next phase to find additional infections, close vulnerabilities, and clean
infected systems.

D1 - Positive ID
from Indicators/
Alerts?

D1–If your security tools were able to positively ID the specific variant of ransomware at detection or during the initial
data gathering then additional analysis to identify the infection is not necessary. Responders can move to D7. Otherwise,
move to D2.

D2 - Gather Forensic Data

(if needed)

D2 – To identify the specific variant of ransomware, indicators of compromise must be collected and compared against
known variants. If the initial data gathering didn’t collect enough indicators, additional forensic data gathering may be
required.

If additional systems are discovered to be infected, forensic data should be gathered from these systems as well and
analyzed to make sure you are only dealing with one ransomware variant/infection.

Be sure to gather forensic data related to the Operating System/Software Environment (browser history, persistence
mechanisms, etc.), Network (packet captures, security tool alerts/logs, etc.), and file system. (hashes of suspect
executables, ransom notes, encrypted file samples, etc.)

Document your organization’s tools and TTPs related to D2 here.

Resource:

https://countuponsecurity.com/2014/08/06/computer-forensics-and-investigation-methodology-8-steps/

Page 20 of 38
 D3 - Generate
Hash From
Suspect File &
Send To Sandbox,
AV Vendor,
VirusTotal, etc.
For ID

D3 – Send captured files, hashes, or download URLs to your Anti-Virus/Malware and security tool (where possible)
vendors for identification. You may also be able to get a positive ID from freely available web tools, such as VirusTotal.

Document tools and TTPs related to ransomware ID through vendors and 3rd parties here.

Any results from these tools should be stored with incident artifacts per your Incident Response Program requirements.

Resources:

https://www.virustotal.com/#/home/upload

https://www.hybrid-analysis.com/

https://virusscan.jotti.org/en

https://ransomwaretracker.abuse.ch/tracker/

https://id-ransomware.malwarehunterteam.com/

https://www.threatminer.org/

https://valkyrie.comodo.com/

https://metadefender.opswat.com/#!/scan-file

https://n0where.net/incident-response-malware-analysis-irma

http://www.herdprotect.com/knowledgebase.aspx

D4 - Lookup Other
Gathered Indicators to
Identify Ransomware
Variant

D4 – In tandem with D3, search the internet for any unique artifacts or indicators. A windows registry entry or oddly
named android APK can sometimes lead to a write-up by a security vendor that identifies one specific ransomware
variant.

Any findings should be documented per your Incident Response Program requirements.

Resource:

www.google.com

Page 21 of 38
 D5 – Prior Known Variant ID is
Not Possible; Perform Behavioral
Analysis and Reverse
Engineering. Skip if You Have an
ID

D5 – If you’ve leveraged all of your organization’s TTPs, your security tool vendor’s resources, and exhausted relevant
public resources, you may be up against a new or rare variant of ransomware that has not been identified yet. If you
have an ID, skip this step.

To find out how it initially infects/utilizes a dropper, operates, persists within a system, spreads to other systems, and
communicates with its creator, you are going to have to employ behavioral analysis and/or reverse engineering. Without
this information you will not be able to effectively contain, eradicate, and recover in the next step.

Not every organization has someone on staff who possesses these capabilities. If this is the case in your organization,
you should escalate this need to management and recommend contracting with a 3rd party or security tool vendor who
can offer a service level agreement appropriate to the criticality of an unidentifiable ransomware infection in your
organization.

Some security tool vendors offer behavioral analysis/reverse engineering as part of your service contract for the tool,
though, there typically isn’t a service level agreement when this is the case and cannot be relied upon for a quick turn-
around during a security incident.

There are automated behavioral analysis and reverse engineering products on the market, this may make the most
sense for your organization. Keep in mind, however, that these products can only identify operations that their
programmers built into them. They may not be able to identify truly new/unique ransomware capabilities.

Document your organization’s tools and TTPs related to ransomware behavioral analysis and reverse engineering here.

Any findings should be formatted as a write-up and be documented as part of your incident artifacts.

Resource:

https://www.reverse.it/

Page 22 of 38
 D6 - Encryption
Capabilities?

D6 – By this step we should have either reached a positive ID of the ransomware, or know enough about its operation
from behavioral analysis/reverse engineering to know whether or not the ransomware sample actually encrypts files.

If it does not have the capability, it is malware/scareware and the incident should be converted to the Malicious Code
Playbook. Run it from the start to make sure you don’t miss anything. Knowing it cannot encrypt should make its priority
lower when you get to that phase. The incident is done with the Ransomware playbook.

If it does have the capability, whether or not it has actually encrypted anything yet, it is true ransomware and the
incident should continue with the Ransomware playbook.

D7 - Check Ransomware Census

(goo.gl/b9R8DE) and Other
Sources for Decryptor and
Additional Indicators

D7 – If the ransomware variant is positively identified (did not have to resort to reverse engineering or behavioral
analysis) check the Ransomware Census and other projects online to see if a decryptor is available.

Some ransomware authors use buggy algorithms, static keys, or leave the key behind. In these instances, a security
researcher may have created a file decryptor. Your responders can use the decryptor later in the playbook to recover
files that are not easily restored from backup/shadow copy, etc.

If there is a decryptor available, store it with your incident artifacts per your Incident Response Program requirements.

The sites may also give you additional indicators to use later in the playbook.

Resources:

https://goo.gl/b9R8DE

https://www.nomoreransom.org/en/index.html

Page 23 of 38
 D8 - Download an Authoritative
Write-Up (if available) for the
Specific Ransomware Variant(s)
Encountered. Harvest Additional
Indicators from the Report(s).
(This report will also be used in
the next phase to answer
questions)

D8 - If the ransomware variant is positively identified (did not have to resort to reverse engineering or behavioral
analysis) download an authoritative write-up for the specific ransomware variant. The Ransomware Census site in the
previous step has links for some variants. Malwarebytes Labs has a good collection as well.

The information in the write-up generally includes how the ransomware initially infects/utilizes a dropper, operates,
persists within a system, spreads to other systems, and communicates with its creator. This information gives you the
power to contain, eradicate, and recover in the next step. It may also give you additional IOCs to find more infections or
validate that systems are clean.

There are many sources for ransomware write-ups, if your favorite security tool vendor or security news hotspot doesn’t
have a write up, search google or your favorite search engine for “<variant_name> ransomware write up.” Be sure to
compare what you collected about the ransomware (hashes, file names, ransom notes, etc.) against what the write up
shows. If the write up doesn’t show the same information, it isn’t for the right variant. Keep looking.

If you perform an exhaustive search but don’t find an authoritative write up, skip this step. Not all of them have write-
ups.

Document the write-up (if available) as part of your incident artifacts per your Incident Response Program requirements.

Resources:

https://goo.gl/b9R8DE

https://blog.malwarebytes.com/category/threat-analysis/

Page 24 of 38
Contain/ Eradicate/ Recover

The Contain/Eradicate/Recover phase puts all the work and information from the previous phases into action. In this
phase the responders will track the ransomware infection back to its initial infection vector and forward through the
entire infection chain until all affected systems are identified and remediated.

From
Analyze

E2 - Blacklist Ransomware and

E1 - Able to blacklist
Dropper/Infection/Persistence Yes
executables?
Mechanism Hashes

E1& E2–If you have the enterprise security tools to block executables from running in your environment (generally
based on file hash), add all known bad file hashes gathered in the previous phase to the blacklist in your tool. Be sure to
include droppers, ransomware executables, and known executable support/persistence mechanisms. With most
commercial tools this will stop it from executing even if it was already running.

Run a report from the tool to show which systems have the ransomware. Document the infected systems with your
incident artifacts per your Incident Response Program requirements. You will need this information later to eradicate
and recover.

If your organization does not have the capability to blacklist executables, move to E3 to use other tools to find and
isolate infected hosts.

Document your tools and TTPs related to executable blacklisting and reporting here.

Document the files/hashes blacklisted as part of your incident artifacts per your Incident Response Program
requirements.

Page 25 of 38
 E3 - Scan Endpoints and Check
System/Network Artifacts (Logs,
E1 - Able to blacklist
executables?
No Flows, etc,) for Indicators of
Compromise and Lateral
Movement

E3–This step will be highly variable based on the tools your organization has available. The ultimate goal in this step is to
find any and every other infected system using the indicators of compromise gathered in the previous phase so that they
can be remediated. There are a variety of tools that can accomplish this, it will be a matter of identifying the tools you
have available, their capabilities for finding specific classes of IOC, and documenting them here.

The specific IOCs related to the identified ransomware infection used will depend upon one or more tool capabilities.
Responders generally need tools that scan file systems/hashes, system and application logs, network artifacts (arp
cache, dns cache, packets), registry or config files, and enumerate OS features used for persistence mechanisms (cron
jobs, scheduled tasks, installed services, etc.)

Tools that can scan for IOCs (whether by automated or manual processes) include, but are not limited to:

 IOC scanners – on demand, such as Redline, Loki, or NMAP with appropriate NSEs
 IOC scanners – automated such as AMP or CounterACT
 Remote scripted searches using native OS languages/features such as bash over SSH or WMI
 Endpoint anti-virus/malware that allows you to create custom rules
 Host based intrusion prevention software that allows you to create custom rules
 Log collection and analysis systems, such as Splunk or ELK stack, if certain OS aspects are set to log
 Network based security tools, such as Intrusion Prevention Systems or NetFlow analyzers

Each of the above toolsets has strengths in detecting some IOC’s and weaknesses in others. For instance, network based
security tools are excellent at detecting communication to/from C2 internet addresses that are associated with a
particular ransomware variant, some can even detect infected executables in a network stream. But network based
security tools can’t detect whether or not a particular registry entry or cron job has been deployed to a system.

Identify gaps in your IOC detection toolset and fill them.

Document your tools and TTPs here.

After you scan for known IOCs, add any additional infected systems to the incident and document your searches per
your Incident Response Program requirements.

Page 26 of 38
 E4 - Does this
Ransomware Variant
Spread Itself?

E4 – Some ransomware can propagate itself and spread throughout the internal network and possibly throughout the
public internet, some ransomware cannot.

If the variant has an authoritative write-up or reverse engineering efforts (for unknown variants) show that the code
lacks the ability to spread, follow the ‘No’ path to E7.

If the variant has the capability, even if the responders have no evidence the ransomware tried to spread, follow the
‘Yes’ to E5.

Page 27 of 38
 E5 - If Possible, Block Known
Communication and
Infection Channels (Firewall,
Email Senders, NAC, etc.)

E5 – This step will be highly variable based on the tools your organization has available. The goal in E5 is to use any
internal to internal and internal to external tools to block known communication channels. Communication channels can
be gleaned from an authoritative write-up, reverse engineering, or direct observation of network traffic to/from infected
hosts.

Possible ways to block traffic include, but are not limited to:

 Access Control lists on network firewalls or other network infrastructure

 Network Access Control (NAC) technologies
 Host-based firewalls
 Intrusion Prevention Systems (Network and host based)
 Network black-hole routes
 Proxy (Internal and remote)
 Email Filtering
 Endpoint Security Suite
 Blocks at network infrastructure via port-level (bring the interface down) or MAC address blocks.

Document actions taken to block traffic as part of your incident artifacts per your Incident Response Program
requirements.

Document your tools and TTPs that can block ransomware traffic here.

Page 28 of 38
 E6 - Isolate (disconnect
wireless and wired) and
Acquire Infected Hosts

E6 – Infected systems should now be isolated from the wired and wireless network. Turn off the wireless and wired
adapters. This may be able to be done remotely depending upon the endpoint management tools available.

Remote management and remote security tools will no longer work on endpoints with disabled interfaces. Endpoints
with disabled interfaces should be acquired by the SOC. Virtual hosts may still be able to be managed or connected to
via the virtualization product’s management interface.

Document your tools and TTPs that can disable endpoint network adapters here.

Document isolated and acquired endpoints as part of your incident artifacts per your Incident Response Program
requirements.

E7 - Use Remote (if available)/Admin

Tools to Kill Malicious Processes and
Remove Files/Persistence Mechanisms
from Infected Hosts; or Re-image/Rebuild.

E7 – This step is fed via one of two paths; from E2 where the ransomware executables are no longer able to run and the
endpoint is still on the network (but not able to talk to C2 servers or spread), or from E6 where the endpoint has been
removed from the network.

The end goal of this step is to clean the ransomware files, configuration items (registry, config files, etc.), and any
persistence mechanisms left behind.

This may be possible through remote tools, if your organization possesses the tools and the endpoint is still on the
network. Otherwise, cleaning tools can be loaded on the acquired infected hosts.

If no automated cleaning tools are available (whether it is being cleaned remotely or locally), utilize information gleaned
from the authoritative write-up, reverse engineering report, or from direct observation of the ransomware’s IOCs to
remove the components of the infection.

If there is no critical information on the endpoint, or the information that is on it is deemed unrecoverable, it may make
sense to re-image the workstation to save time and get it back to a known-good state. Before reimaging, pull any
forensic data you will need to further investigate the ransomware incident.

Document the conditions where the endpoint will be re-imaged rather than cleaned here.

Document your tools and TTPs related to ransomware infection removal here. Be sure to include options for
ransomware variants that do not have automated cleaners and options for remote and local cleanup.

Document actions taken to clean and/or reimage endpoints as part of your incident artifacts per your Incident Response
Program requirements.

Page 29 of 38
 E8 - Apply Patches,
Security Products, etc.
or Other Mitigations to
Prevent Re-Infection

E8 – Now that the identified endpoints are clean, take steps to prevent re-infection. Utilize the information collected
from the authoritative write-up, reverse engineering report, or from direct observation of the ransomware’s IOCs to
close vulnerabilities, stop infected email, stop connections to infected web sites, or install new security tools to prevent
re-infection of the newly cleaned devices and future infection of other devices.

Document actions taken to prevent reinfection as part of your incident artifacts per your Incident Response Program
requirements.

Resource:

https://documents.trendmicro.com/images/tex/infographics/ransomware-101.jpg

E9 - Chain the Attack

(Investigative Chains)
Backward and Forward
Until You Discover the
Initial Infection Vector
and Each Infected
Endpoint

E9 – To ensure responders remediate the entirety of the ransomware infection, employ knowledge of its infection and
spreading mechanism in combination with logs/alerts/reports from security tools and forensics data to trace the
ransomware back to its initial infection. Likewise, for spreading variants, track infected endpoint activities forward.

In both cases the goal is to make sure responders can account for all of the systems involved in the infection.

The tools and TTPs utilized will vary depending upon what tools and TTPs are deployed. In general, various logging
systems and network traffic analyzers/intrusion prevention will carry the bulk of the evidence trail.

Document investigative actions taken to identify additional ransomware components as part of your incident artifacts
per your Incident Response Program requirements.

Document tools and TTPs related to investigating and following the spread of ransomware here.

Page 30 of 38
 E10 - Rescan Endpoints
for Indicators of
Compromise and Lateral
Movement

E10 – Utilize all of the IOCs and information about the infection chain to re-scan the entire network for IOCs and further
signs of lateral movement. This scan will be similar to E3, but responders may have more IOCs to search for now.

If additional infected endpoints are found, start them over at E4.

If no additional infected endpoints are found, continue to E11.

Copy any documented tools and TTPs from E3 here. If additional tools are identified to scan additional indicators found
since E3, make sure you document them in E3 as well for reference in future incidents.

After you scan for known IOCs, add any additional infected systems to the incident and document your searches per
your Incident Response Program requirements.

E11 - Decryptor
E12 - Decrypt Files Yes
Available?

No

E11 & E12 – If a decryptor was found to restore encrypted files, decrypt them (if required) and skip to E15. Keep in
mind, decryption may be scriptable.

Otherwise, continue to E13.

Add the decryptor to the incident artifacts and document decryption actions taken as part of your incident artifacts per
your Incident Response Program requirements.

Page 31 of 38
 E14 - Restore Encrypted E13 - Backup
Yes
Files Available?

E13 & E14 – If there is a backup of encrypted files available, restore them (if required).

Document restoration actions taken as part of your incident artifacts per your Incident Response Program requirements.

E15 – Retain
Unrecoverable Files
(if required) and
Reconnect/Return
Isolated Hosts

E15 – If there are files that are not decryptable or restorable, but they contain critical information that the
business/user would like back, retain the files with information about the ransomware that encrypted them. A decryptor
may become available in the future.

Endpoints can now be returned and/or reconnected to the production network.

Document stored files and returned/reconnected endpoints as part of your incident artifacts per your Incident Response
Program requirements.

Page 32 of 38
 E16 - Is this
Ransomware
Yes
variant a known
data stealer?

E17 - Initiate Data Loss/Theft

Playbook

E16 & E17 – Based on the information from the authoritative write-up, reverse engineering efforts, or direct
observation, determine whether or not the ransomware is a known data stealer.

If it is, initiate the Data Loss/Theft Playbook.

Document whether or not the ransomware is determined to be a data stealer, and whether or not the Data Loss/Theft
Playbook was initiated as part of your incident artifacts per your Incident Response Program requirements.

E18 - Block Any Additional

Communication and Infection
Channels Discovered During
Containment and
Eradication(Firewall, Mail
Senders,NAC, etc.)

E18 – If additional communication or infection channels were identified during the investigation loop between E4 – E10,
block them. Similar to E5 and E8.

Document tools and TTPs that can block communication channels and infection vectors here. These can be copied from
E5 and E8.

Document actions taken as part of your incident artifacts per your Incident Response Program requirements.

Page 33 of 38
 E19 - Send Samples/Indicators
to Vendors That Did Not Detect
Threat (follow their defined
process)

E19 – If a security tool did not detect or alert, but should have, follow the vendor’s process to send samples, indicators,
traffic captures, etc. for analysis.

Document what was sent and to whom it was sent as part of your incident artifacts per your Incident Response Program
requirements.

E20 - Implement New/Custom

Detection Rules (IPS, Anti-
Malware/Virus, Log Correlation,
Analytics, Etc.

E20 – Review all indicators and behaviors of the ransomware. Implement new or custom rules in your security tools to
detect or prevent the variant encountered in the future. What tools are modified will highly depend on your
organization’s environment.

Document tools and TTPs related to the ability to deploy custom rules in your security tools here.

Document what was added or modified to each tool as part of your incident artifacts per your Incident Response
Program requirements.

Page 34 of 38
Post-Incident

The Post-Incident phase covers the assessments and activities that occur after the ransomware threat has been
remediated. These include various reviews and reports that are sent to upper management and are stored, gap
assessments and corrective actions, and additions or modifications to playbooks, internal documentation, and TTPs.

From
Containment/
Eradication/
Recovery

F1 - Incident Review

F1 - Incident Review is an event and report for stakeholders and upper management to review and provide input about
what happened, when it happened, how it happened, how it was investigated, and how it was remediated.

Summarize and cover everything documented throughout the various phases and steps. Identify improvement
opportunities and roadblocks.

The ultimate goals are to communicate damages the business sustained, how they will be dealt with, and what will be
done different in the future to stop it from happening again. Additionally, cover any continuing actions (legal action,
regulatory action, other playbooks triggered, technical or procedural improvements, etc.) and who is handling them.

Resource:

https://www.crest-approved.org/wp-content/uploads/2014/11/CSIR-Procurement-Guide.pdf (page 44)

https://www.nasa.gov/pdf/589502main_ITS-HBK-2810.09-02%20%5BNASA%20Information%20Security%20Incident%20Management%5D.pdf (page 21)

Page 35 of 38
 F2 - Review Lessons
Learned

F2 – The Lessons Learned Review may be spliced into F1 for smaller incidents. Stakeholders and upper management is
invited to review and provide input.

This event and report will cover the “what-if” scenarios.

 Could any unforeseen events during the incident been detected earlier or prevented?
 What pre-cursors did we miss?
 How can we handle this type of event better in the future?
 What would we do different next time?
 What was stopping us from making progress on the incident that we didn’t recognize at the time?

Resource:

https://www.crest-approved.org/wp-content/uploads/2014/11/CSIR-Procurement-Guide.pdf (page 44)

F3 - Review Lessons
Applied

F3 – The Lessons Applied Review may be spliced into F1 for smaller incidents. Again, stakeholders and upper
management is invited to review and provide input.

This event and report will cover any corrective actions that have been taken, or will soon be taken, as a result of the
incident. At minimum this will include actions taken during E8. If additional/updated tools or TTPs will be deployed, they
should be reported about here.

Page 36 of 38
 F4 - Evaluate Gaps In
Prevention, Detection,
Response, Remediaton;
Make Corrective Action
Recommendations to
Management

F4 – This step takes the information from F1 – F3 and puts it to use with appropriate analysts and engineers to find gaps
in your organization’s security tools and TTPs. Executable corrective action plans with required budget are submitted to
management.

If the incident was ruled a false-positive from Detect, this step is optional.

F5 - Update
Documentation, To
Prepare
Procedures, and
Playbooks

F5 – In this step the responders take update documentation based on information discovered during the incident and
the assessments/reviews above. Internal documentation, help desk documentation, internal procedures, playbooks,
network diagrams, inventories, etc. are updated and fed back into the prepare phase to be applied to other phases in
this playbook and other playbooks.

If the incident was ruled a false-positive from Detect, this step is optional.

Resource:

https://www.crest-approved.org/wp-content/uploads/2014/11/CSIR-Procurement-Guide.pdf (page 45)

https://www.nasa.gov/pdf/589502main_ITS-HBK-2810.09-02%20%5BNASA%20Information%20Security%20Incident%20Management%5D.pdf (page 22)

Page 37 of 38
 F6 - Create, File, and
Communicate Final
Reports to Stakeholders

Incident End

F6 – In this final step before the incident is completely finished, all final reports (from above) are sent to appropriate
stakeholders and upper management. Wait until the end of the process to send them as responders may find additions
or changes need to be made to the reports based on the updates in F5.

If the incident was ruled a false-positive from Detect, this step is optional.

Resource:

https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf (page 54)

Page 38 of 38