In our final post in our series on increasing incident response speed, we’re talking about scoping. As a reminder, we’ve reviewed these digital forensics and incident response (DFIR) phases:
- Start the incident investigation after an alert is generated (here’s how)
- Collectdata from the endpoint and network to start analysis (here’s how)
- Analyze the data to answer investigative questions using endpoint forensic techniques (here’s part 1 andpart 2)
- Scope the incident and identifying other endpoints that are involved using hunting techniques.
During the scoping phase of incident response, you use the results from the analysis phase and search dozens, hundreds, or thousands of other computers for the same data. This is often referred to as an “Indicator of Compromise (IOC) Scan.”
The scoping phase is important to root out all traces of the attacker. There is no point in cleaning up one host if the attacker maintains a foothold in five others.
Why Fast Scoping Is Important in Incident Response
Rapid scoping is important if you want to fully understand the attack and eradicate the attacker.
As wediscussed before, the goal of the incident investigation is to answer questions like “how did the attacker gain access?” or “was sensitive data accessed?”
If you want to complete your investigation quickly with the correct answers, you need to reduce the time it takes to find evidence. When you scope, you find other infected endpoints and that will help you to more quickly understand the situation.
For example, the endpoint you start with may not have the evidence you need to answer all of your investigative questions. You may waste time diving deeper and deeper into it in the hope of finding evidence. But, another host may have “lower hanging fruit,” and the evidence you need is more obvious. You may be able to find that other host by looking for copies of the evidence you’ve already found, by looking at every host that has remote desktopped into this computer, or by looking at each computer that a given domain user has logged into.
It’s important to triage as many hosts as possible before diving too deep into a single one.
Fast scoping is also important so that you can remediate more effectively. If you start to remediate one host, but the attacker still has a foothold elsewhere, they are able to stay within the network, steal more data, and infiltrate other hosts.
Methods for Scoping in Incident Response
Scoping involves searching for other hosts with a given indicator. You can use the same techniques that you used when you investigated the first endpoint.
The differences are that:
- The investigation question is much more focused. You’re trying to answer a question such as “Does this host have a file with MD5 hash XYZ?”
- You’re not considering a single host. Scoping can involve anywhere from dozens to hundreds of hosts.
But, the techniques are fairly similar to the ones we outlined in our previouspost on collection.
Let’s review those with a perspective on scoping.
Manual Command Line Tools
We referred to this as the “baseline” in our last article, because it’s what a lot of companies start with. It’s the use of free, command line tools that the responder manually runs each time.
If this is how you are doing incident response, you can’t really scope. You can’t realistically log into each computer and run a set of tools to look for a specific process or file.
Companies that rely on this DFIR approach are likely hoping that the only infected computers are the ones that alerts are being generated for.
Scripted Tools
If you’ve scripted your command line collections via Python, Powershell, or some other method and you have a method for deploying these tools automatically to many hosts, then you can start to think about scoping.
You may need to write your own queueing system to track which hosts still need to be analyzed and a collector so that data can come back to a central place for review.
It is certainly possible to scope using this approach, but it may require significant in-house development.
Continuous Monitoring
If you have continuous monitoring setup (such asEDR), then data is constantly being recorded from the endpoints and sent to a central location. The types of data that are collected depend on how you’ve configured the monitoring.
If the types being collected include the kind of data you are using for scoping (such as MD5 hash or process name), then scoping can be very efficient. You simply need to query the collected data for the indicator.
The scoping challenges with continuous monitoring usually arise if the data type was not collected (because the company was concerned about storage sizes) or if continuous monitoring was being performed on only critical systems. If continuous monitoring is not being done on all endpoints, then you cannot rely on it alone to know where else an indicator exists.
Automated Collection
An automated collection system is an agent-based or agent-less systems that can be triggered by a SIEM or orchestration system to collect data from an endpoint or server. With these integrations, the SIEM or orchestration system sends a hostname or IP address to the collection server, adds the host to a queue, and performs the collection when processing resources are available.
By their design, these systems can often be used for scoping. All you need to do is submit the list of host names that you want to search. They will get added to the queue and eventually collected from.
The drawbacks of this approach for scoping are:
- Some of the tools may collect more data than you need for the scoping. This will result in wasted time and data
- These tools scan for the data currently on the system. The scan will not alert you to computers that were involved with the incident but have the indicator deleted.
If you’d like to try a system that does this, you cantry Cyber Triage, which just added aqueuing system.
Conclusion
Rapid scoping is important to ensure that your root out the attackers and fully understand the scope of the incident. Hopefully, this article provided you with some useful advice as you work to accelerate your response time.
While this concludes our series on speeding up incident response, we’ve got quite a few educational posts in production.
Next up: a deep dive introduction to and review of incident response.
