EDRs, XDRs, and RemoteOps tools are now relatively common in corporate settings, and many offer the incident response team the ability to get basic DFIR visibility. However, they are limited in the data they collect, which is often insufficient for a complete IR investigation.
In this blog post, we will look into the EDR gaps with respect to DFIR and how you can use EDRs effectively during your response to deploy your other DFIR tools.
The goal is to ensure you understand the gaps and that you are prepared when an incident happens.
EDR Basics
Endpoint Detection and Response (EDR) systems evolved from basic anti-virus (AV) applications that used signature analysis to detect malware. Most EDRs go beyond that and collect detailed process information to try to detect malicious activity.
According to Gartner, the current leaders in this space are:
- Microsoft Defender
- Crowdstrike
- SentinelOne
For the incident responder, EDRs are far superior to old AV applications because AV only told you what files were quarantined and what the malware family name was, without providing any context around the threat. It was also difficult to add new hash values to the AV bad lists and AV didn’t support other IOCs or searching across all of your hosts. EDRs collect and retain a variety of telemetry so that you can later review it, search across all hosts, and see how an incident unfolded.
In an ideal situation, an EDR detects malicious activity and then shows what process launched it, which user account was involved, what operating settings were modified, and what files were accessed, created or modified. Sometimes this is enough to determine the origination of the threat. Unfortunately, most incidents are not that ideal or easy and the data is not all there — especially when the attacker is “living off the land.” Let’s look at why.
EDR DFIR Limitations
There are several key limitations of an EDR when it comes to a forensic investigation.
- Incomplete Data: EDRs don’t have all of the data you may need for the investigation. They may not have been recording a type of activity that the attacker used, which could be why the attack was successful and the EDR didn’t stop it. Or, you may want to ensure you have the original source file with the evidence for your own processing.
- Limited Retention: In addition to the limited types of data, the retention time of the collected data is also limited. Most environments have only 30-days of data, with some low cost options as low as 14-days. This means that evidence from before that date is gone from the EDR (but evidence may still exist on the victim systems in various files). While dwell time for ransomware incidents may be measured in days for most other types of attacks the dwell time is often measured in months.
- UI Optimized For Alerts: EDRs are primarily focused on prevention and showing you alerts of possible attacks. The UIs are alert-focused. That is great for the SOC analyst, but is less ideal for the incident responder who is trying to create a timeline of the attack. This means that your responders will need to use other tools, such as a spreadsheet, to keep track of the details.
- No Hindsight: EDRs won’t know what happened before they were installed. They focus on real-time observations and do not look for evidence in files and artifacts. This means that if you install them after an attack, they won’t show you what happened before.
Run DFIR Tools Through EDRs
Because of these gaps, EDRs will not be the sole source of evidence in your investigation. You’ll need to collect additional artifacts on the hosts you suspect were involved in the incident. This will mean bringing them into your DFIR analysis environment.
Fortunately, nearly all EDR companies recognize this and offer you a way to collect more data via:
- Deploying and running scripts
- Accessing a command or PowerShell prompt on the remote system
- Application Programming Interface (API)
Therefore, the EDR infrastructure can become a key enabler of your investigation even if it’s not providing all of the data. Let’s look at how.
Key Challenges to Getting Forensic Artifacts
There are three key challenges when running a 3rd party DFIR collection tool from an EDR or other IT infrastructure:
- Getting the DFIR collection tool to the system
- Time limits and status while the tool is running
- Getting the artifacts off the system
Each EDR is a bit different, but let’s cover the basic concepts.
For example, we will use our Cyber Triage Collector tool. We recommend responders and investigators use this tool to collect additional DFIR artifacts. Here are some basic concepts of the Collector to help you understand the examples:
- It’s a single Windows executable that will collect and parse numerous files, such as the MFT, registry, and event log.
- It collects executable files associated with startup items, scheduled tasks, processes, etc.
- It collects hashes of everything on disk for future correlation.
- Its output is a JSON file that can be sent to disk, uploaded to S3, or sent to a Cyber Triage server.
- There is a Deployer Powershell script that allows you to easily integrate the Collector with EDRs.
Getting DFIR Collection Tools Onto The Systems via EDR
The first step is obviously to make sure your DFIR tools are on the target system. There are several basic approaches to doing this with an EDR:
- Push via EDR: Some EDRs can copy one or more files over. The files could be either the tool itself or a script that will download tools. For example, Sentinel One RemoteOps and Windows Defender can store scripts and tools in the central server and push them out as needed. This approach allows for the greatest amount of automation.
- Remote Shell: Some EDRs will provide you a remote Powershell prompt (or similar). From there, you can use a command such as ‘Invoke-Webrequest’ to download the scripts or tools from a URL. This approach may require you to configure a web server to host the data and requires you to type in commands on each system.
- Manual Copy: If the target system has file sharing enabled, you can manually copy the files by mounting the remote C$ drive or using various Powershell file copy commands. This approach requires you to keep track of where you copied the files to and you’ll still need a shell from the EDR at some point to launch those programs.
- File Share: Store your DFIR tools on a file share that each host has access to. You can then launch the tools from there. Note that permissions can be challenging in some environments depending on what account the EDR runs as.
- Baseline: You can include the DFIR tools in the base image on all systems so that they are there in case of an incident. The main challenge to this is making sure the copy on the system is up to date and hasn’t been tampered with. Like the previous approach, you’ll need to also make sure your EDR will give you a shell to launch these programs.
Depending on what DFIR tool you are using, you may need to extract the contents of a ZIP file or install an MSI file once it is on the target system. This is not necessary with the Cyber Triage collector tool.
Using the example of our Cyber Triage Collector tool, there are several options:
- If your EDR has a script library, you can store our Deployer Powershell script in it and push it out as needed. That script can then download the latest Cyber Triage Collector from cybertriage.com and then launch the Collector. This is the easiest way if your EDR supports it.
- If your EDR gives you only a Powershell prompt and you have access to a web server, you can host the Deployer script there, download it, and launch it with no arguments. The script has all of the configuration settings. This approach has the least amount of typing.
- If you have a Powershell prompt but no web server access, then you can instead download the Collector executable from cybertriage.com and launch it yourself with the appropriate arguments to specify where the output goes.
Time Limits and Status
You will need to be aware that some EDRs assume the scripts will be completed in a few minutes. While some are, if you are doing a more in-depth collection or a full IOC scan then you need to be careful. Otherwise, the EDR could kill the collection.
Check the timeout value. In our experience:
- Windows Defender will kill a process after 30 minutes.
- Sentinel One has a similar timeout for a remote shell and longer times for RemoteOps.
You can get around these limits by launching the collection as a background process. The downside of this is that the original script will not know when it finishes. So, you’ll need to do additional work to get status updates. In this scenario, some investigators keep track of which systems have been collected in an incident tracking spreadsheet.
Some EDRs will record the data from the collection tool that is displayed on the UI and show that from within the EDR. This can help debug issues, notably around permissions. But, if the collection tool is run as a background process, then that data is lost.
The Cyber Triage Collector Deployment script has different behaviors depending on the EDR that it is running in.
- For EDRs with a long timeout, it will launch the process as a child of the script and the output can be seen by the EDR. It will also know if it is still running.
- For EDRs with a shorter timeout, it will launch the process as a background process. It will wait around for several seconds to make sure it properly launches and runs and will then exit.
Getting Artifacts Back
There are two broad approaches to getting data from the target system when you start the collection via the EDR:
- Push to Service: Have the collecting program push data over the network to a waiting server, web service (such as S3 or SFTP), or shared drive. Or, you could have a separate program copy the collected data at the end if your DFIR collection tool doesn’t support pushing to the network. These approaches can be challenging if the system was isolated from the network. And they require the collector to have credentials to access the network-based resources.
- Pull from EDR: Write the data to disk and have the EDR copy the file back (if it supports this). This step requires your EDR to know when the collection is complete, which could be challenging if you ended up creating a background process. Many EDRs also have a 2GB size limit, which can be limiting depending on how much data you are collecting. Some DFIR tools make this process more challenging because they have many output files. So, they must be either individually copied or you need to create a single ZIP file with the contents.
The Cyber Triage Collector supports all of the above scenarios, depending on which works best for you:
- The Cyber Triage Server can accept connections over port 443.
- The Collector can upload to an S3 bucket
- The Collector can save to a file or network share
You can configure the destination either as command line arguments or by editing the Deployer script.
Leverage Your EDR to Get DFIR Data
EDRs, XDRs, and RemoteOps systems are designed to prevent incidents; however, intrusions are inevitable as attackers get better at living off the land and evading these systems.
Pre-configuring DFIR tools for easy deployment via these platforms will:
- Save you critical time during an incident investigation
- Encourage proactive threat-hunting using forensic-level analysis
- Enable you to review more systems more often, with far less time spent on collection
To learn more about adding the Cyber Triage collector to your EDR, XDR, or RemoteOps system, please review the following links and feel free to reach out with any questions.
- Documentation: Collector Deployer Powershell Script
- Documentation: Collect with SentinelOne Singularity
- Documentation: Cyber Triage Collector
- Download: Cyber Triage Free 7-day Trial
