In this post, we are going to show you what role the DFIR team can play to get data and services back online after a ransomware attack. This is the critical first step in the ransomware recovery process.
This is the second post in our continuing series on ransomware, and how a ransomware investigation can be performed using the Divide and Conquer DFIR Process. Divide and Conquer helps investigators organize their approach and keep track of what artifacts they should focus on. If you follow this process during incident response, your investigations will be faster and more comprehensive.
Divide and Conquer is all about breaking investigations down into questions that can be answered with data. In this post, we are going to focus on the first ransomware-based investigative question: “How do we get our data and services back online?”
Let’s get started.
How to Get Data and Services Back After a Ransomware Attack
- What Is the Divide and Conquer Process?
- Review of the Ransomware Series
- Why Is Getting Data/Services Important to Ransomware Recovery?
- Why Tools Impact Ransomware Recovery
- How Do We Get Our Data and Services Back?
- How to Search the Enterprise During Ransomware Recovery
- Example Ransomware Recovery Run-through
- Ransomware Recovery: Next Steps
What Is the Divide and Conquer Process?
Let’s quickly review the basics of Divide and Conquer DFIR. Refer to the previous post or the training for more details.
The Divide and Conquer DFIR process is a framework to help you focus on certain types of artifacts that are relevant to the specific incident you are investigating.
Here is the main concept:
- Investigators start off with a set of questions that they have been tasked to answer
- Those questions are often hard to answer; so, we use the classic problem-solving approach of breaking big problems into smaller solvable problems. In this case, we break big questions into smaller answerable questions
- We repeat this breakdown process until we get to questions that are simple enough to answer with a single artifact category
- We then get the data to answer the question and plan our next step accordingly.
That’s it. The challenge is knowing how to break the questions down and prioritize what question to answer first.
Review of the Ransomware Series
This is post #2 in the Divide and Conquer Ransomware Series and, in the previous post, we outlined the 4 top-level questions that management will be trying to answer when they realize that a ransomware attack has happened.
Those questions were:
- How do we get our data/services back?
- How do we get the attacker out?
- What else did the attacker do besides encrypt?
- How do we prevent this from happening again?
We’re going to dive deeper into the first question in this post and break it down into smaller pieces. The following posts will cover the other questions.
A key concept to understand is that this is meant to be an example of an investigative process and is by no means an all-encompassing ransomware investigation checklist. An analyst can absolutely build upon fundamental ideas and resources discussed within this post, but because every incident is different, this is not designed to be an “end all be all” checklist.
Why Is Getting Data/Services Back Important to Ransomware Recovery?
The question of “How do we get our data/services back?” is the most important big-picture question because presumably the data and services are important to your business or organization and therefore you want to get them back. There is no ransomware recovery if you don’t get data and services operational again.
At the end of the day, you have three main options:
- Pay the ransom
- Restore the data /services from backups
- Reset everything from scratch and lose the data.
Deciding between these is a business decision that the DFIR and IT team are a part of. Maybe the company will decide based on whichever is cheapest. Maybe the company will decide to never pay a ransom (or will not legally be allowed to). We’re not going to decide that for you. We’re just going to make sure you have the needed data.
As we will see in this post, not all of that data comes from DFIR people. We’ll dive deep into only the DFIR topics.
Why Tools Impact Ransomware Recovery
As we talked about in the Divide and Conquer training, there is no single way to answer an investigative question. We’re going to focus on the questions, but the order that you answer them and the techniques will depend on the specific incident and what technical capabilities you have.
Notably, to understand the scope of a ransomware attack, you’ll need to figure out which computers were impacted. Some organizations have continuous monitoring or other IT infrastructure that enables them to easily search for any file by name or extension. Others don’t.
So, we are going to cover examples of how you could answer the question, but some may not be achievable for an organization.
If you don’t have the ability to do some of the searches, don’t feel alone. Lack of endpoint visibility is a key challenge we hear about a lot when talking to people about Cyber Triage.
How Do We Get Our Data and Services Back?
Let’s get to the actual meat of this post: breaking down our top-level question because it can’t be answered by a single artifact category.
As we discussed in the training, the concept of breaking down is easy. The challenge is knowing how to break things down in a useful and complete way. Sometimes that is based on computer fundamentals and other times it’s based on what the attacker is doing.
We’re going to break down the question of “How do we get our data/services back?” based on:
- How ransomware works
- How business make decisions (i.e. based on cost)
The goal of our breakdown questions is to get some understanding of the value of what was encrypted and a cost estimate on what the possible response options are.
We use the following five sub-questions:
- What data or services were impacted? We need a rough list of what data and services are no longer available before we can make decisions based on value or backup existence. The list may not need to be 100% accurate. But, you need some rough idea about what files and services are impacted so that you can later determine value and backup existence
- What is the value of the impacted data and services? Once you know what data or services are impacted, someone will want to know roughly the value of that data. Can it be easily recreated? Is it sensitive? Again, this is likely an estimate and does not need to be down to the penny
- Do we have backups? Based on the data and services enumeration, you need to know if you have backups for the data and services. If so, you’ll have more options. During this step, you should confirm that the backups still exist and work
- Are we allowed to pay? The United States Treasury has started to impose fines if you pay a ransom to someone on their list. You can read more about that here
- What is the cost to rebuild? Having to rebuild IT systems has a cost even if you have backups. Some companies will compare that cost with the ransomware to decide which direction to take.
The astute DFIR reader will notice that many of the above questions are not actual DFIR investigative questions. You can’t answer if backups exist or the value of data based on registry artifacts. So, we’re not going to cover them in this post.
We’re going to spend the rest of our time on the first breakdown question determining what data or services are impacted.
What Data or Services Were Impacted?
The Divide and Conquer DFIR Process is a recursive process that stops when we have a question that can be answered with a single artifact category. We can’t answer our current question with a single artifact, so let’s keep on breaking it down.
We’re going to break down the question of “What data or services were impacted?” based on how ransomware works.
There are two general variants of ransomware:
- Many encrypt a subset of files on a computer, but the computer remains operational
- Others encrypt the entire hard drive or the Master Boot Record (MBR) and make the computer non-operational. For example, Petya and MBR Locker.
There are different ways of detecting these, so let’s breakdown our question based on those variants:
- What files were encrypted by the ransomware? We can’t answer this with a single artifact, so we’ll have to break this down further in the next section
- What servers/services are not available because of ransomware? This isn’t really a DFIR investigative question, it’s more of an IT question. They should have monitoring in place to know which servers are not up. The exact process of determining that depends on what monitoring tools the IT department has.
What Files Were Encrypted By The Ransomware?
You’ll want to have a basic understanding of what files were encrypted. This is a task that will be carried out by both the IT staff and DFIR teams, depending on who has what tooling.
There is not a single artifact category that answers this question because, by design, the files no longer exist and each ransomware is a bit different with respect to what they tell the victim.
We’re going to break this question down based on how malware works, so first let’s cover some basics:
- Ransomware needs to be configured to encrypt files based on path and/or extension
- Ransomware is deployed either on a single system or by propagating it in various ways, such as pushing it out to a domain via various forms of scripts
- When run, the ransomware will encrypt files and delete the original. It often uses a new file name for the encrypted file. Some ransomware will also upload copies of the files to a server
- When finished, the ransomware will leave notes or other UI prompts to let you know that files are encrypted and where to pay. Or, it will restart the computer and show you text that the entire computer is encrypted.
Given that, let’s break down our questions about identifying what files were encrypted. You will not need to answer all of them. It all depends on how thorough you want to understand the scope and what tools you have.
- What files in the enterprise have extensions of known ransomware? We might be able to infer which files are encrypted based on the file names. This approach requires us to know which extensions the ransomware uses. An example list can be found here, but some ransomware uses random extensions. You may also know extensions if you were able to analyze a system that was compromised. This question can be answered with a single artifact category: File Metadata
- What files are in the same folder as known ransom notes in the enterprise? Ransomware will often leave notes in each folder that contains encrypted data. By finding the ransom notes and then looking around, we can figure out the impact without knowing the extensions. You can find the note naming convention from a known system or using standard names. This question can be answered with a single artifact category: File Metadata
- What systems were infected and what files were the ransomware configured to encrypt? Maybe you can’t search for all files or maybe you don’t care as much about an exact list of files. In that case, you could focus on finding compromised systems and guessing about what was on them based on their role. We will need to break this question down further
- What files were on a computer that is now fully encrypted? If the computer no longer runs, we can’t search it for clues. So we need to guess about what is on it or refer to backups. This isn’t really a DFIR-specific question to answer since IT should know if the computer isn’t running and they are likely better at guessing what was on there.
- What files have users reported being encrypted? We shouldn’t ignore the files that users tried to open and couldn’t find! We can get these from help desk tickets.
Note that this list is not exhaustive because there are other techniques for identifying encrypted files, such as high entropy. But, those techniques may find encrypted files that are not from ransomware and these are the common techniques.
Of these questions, only one needs further breakdown. Let’s do it.
What Systems Were Impacted and How Was the Ransomware Configured?
If you don’t want to or are unable to search for ransom notes and known extensions, you can always try to focus on what systems were infected and infer what is encrypted based on how the ransomware was configured. From there, you can infer what kinds of files are likely encrypted.
These are two separate steps that we can use for our breakdown.
- What computers were infected by ransomware?
- How was the ransomware configured?
Let’s dive into each of those some more.
What Systems Were Infected by Ransomware?
We can break down the question of identifying which systems were infected by ransomware based on how ransomware works:
- What computers have ransom notes at a given path? We already saw this general topic when identifying encrypted files, but the difference here is that we’re going to look for a specific path. Some IT organizations are able to perform that kind of search, but not a wildcard search. For example, they could search for a ransom note in “Program Files” or “Temp” instead of something inside of a user folder. This can be answered with a single artifact category: File Metadata
- What computers may the ransomware have propagated to? Different ransomware families and threat actors have different methods for trying to get the ransomware spread as far as possible. By knowing how the ransomware could have propagated, you may identify possible systems. This will not be a precise number though since you won’t be sure if the system was actually infected. Going deeper on this topic is out of the scope of this post.
- What computers have AntiVirus alerts for ransomware? It’s always possible that your Anti-Virus detected the ransomware, but it was too late. It’s useful to look for these alerts and see if the ransomware worked on those systems. You can answer this with a single artifact category: Application Logs
- What computers were reported to the help desk about missing files/slow performance? If nothing else, you can always focus only on the systems that users are reporting. You can answer this with a single question: Help Desk Tickets.
How Was The Ransomware Configured?
Once you have a list of computers that may have the ransomware, you can guess about the impacted files based on how the ransomware is configured. Unfortunately, most ransomware doesn’t have a nice user-friendly configuration file that lists out the file extensions that it is focused on. Oftentimes, the data is encrypted or hard coded into the application.
Therefore the specific techniques here vary depending on what kind of ransomware you are dealing with. Though because some malware will simply encrypt everything on the system, perhaps the file type details are not important once you know a system has ransomware.
How to Search the Enterprise During Ransomware Recovery
Many of the techniques used to accurately answer this question rely on an organization being able to search endpoints in the enterprise to determine where ransom notes and encrypted files are. There are a variety of techniques to do this:
- Continuous Monitoring / Hunting Solutions: Some mature organizations have the ability to search the contents of any system in the enterprise. This may come from an EDR system or some other DIY hunting solution
- IT Management: Some IT systems allow administrators to identify if a specific file exists. They may not be as powerful as a hunting platform but offer basic querying
- Scripts: Other departments rely on Powershell, WMI, and other scripts to look at various endpoints. This is not always the most robust approach since they are built on the fly as the incident is unfolding, but it certainly works when nothing else exists.
As you think about how you’d respond to a ransomware incident, it’s important to think about how you would scope it out and answer the questions in this blog.
Example Ransomware Recovery Run-through
Let’s go through an example for the DFIR-related questions in this post.
Let’s say ACME Company had a user report to the help desk that they logged in to find a message on their screen that the files were encrypted.
Some initial investigation of the user’s system suggests it is Dharma and encrypted files have a “.crysis” extension and ransomware notes are named “FILES ENCRYPTED.txt”.
The company has confirmed the incident on this computer, but wants to know the full enterprise scope before making decisions.
We now start to answer the scoping questions about “What files in the enterprise were encrypted?”:
- What files in the enterprise have ransomware extensions?: The company does not have the infrastructure (EDR or PowerShell enabled everywhere) to search all computers for a given extension, so they can’t immediately answer that question, even though they know to look for “.crysis” files
- What files in the enterprise are in folders with ransom notes?: The company knows what file names to look for, but is unable to search all computers for the file name. So, it can’t immediately answer this question
- What systems were infected with ransomware and how was it configured? The team knows they need some kind of basic answer on scope, so they try to determine which have a ransomware note at a fixed path. They look at the initial system and notice a ransom note in a “C:Program Files….”. application folder that had DOCX and PDF files and where therefore encrypted. The IT infrastructure is used to identify other systems with that ransom note. This search will not work for systems that did not have the application installed, but should provide some more insight.
The company ultimately decides to scope the incident based on the fixed path search results and additional user reports.
Based on those systems, the company then goes through the remainder of the questions to identify:
- The value of the data on the computers
- If backups exist
- If it is legal to pay the ransom
- Cost to rebuild
Meanwhile, the DFIR team goes on to start answering remediation questions, such as “How do we get the attacker out?” We’ll talk more about that question in the next post.
Ransomware Recovery: Next Steps
In this post, we dove into the first question of ransomware investigations and outlined the techniques that DFIR responders need to help answer the question about getting back online.
In reality, this question is not often where the DFIR responders spend their time and the IT staff end up focusing on the scope and ransomware recovery options that were outlined in this article. The DFIR tasks are in the next questions, which deal with getting the attacker out and prevention.
We’ll cover those questions in the coming weeks. In the meantime, sign up for the 3-hour Divide and Conquer video course that covers the basic concepts of the process and provides a basic overview of Cyber Triage
If you’d like to try Cyber Triage, the automated intrusion investigation software built on the principles of the Divide and Conquer Process, you can download it here.
If you liked this content and want to make sure you don’t miss our next article, sign up for the Cyber RespondIR email!
