First and foremost, I want to try and keep this on a simpler level for everyone, not super deep. Based on the nature of what we are discussing there will be a need to dive a bit deeper into the technical side of things, but I will try to keep it approachable for all levels!
- What are the different parts of an EDR
EDR is a very common term and seems to be very misunderstood throughout the channel and enterprises, it’s short for Endpoint Detection and Response. A very simple premise with a complex underpinning which we are going to explain in a bit more detail.
Endpoint should be straightforward, it’s the device the user interacts with daily or a server which runs one (or many) different roles within your company (AD server, Domain Controller, etc.).
Detection is the act of identifying or investigating items which are either on the border of being malicious or have already been classified as malicious (this would be known malicious for future usage in this article). This is the portion responsible for collection and correlation of data via what’s known as “telemetry”.
Respond is the action taken when an object meets the specified criteria of rules (generally called D&R rules). The design here is to go beyond what a typical AV solution would have in terms of signature or hash-based recognition and find patterns/behaviors which are indicative of malicious activity.
- How does EDR function?
The EDR is comprised of different parts, some of which we described above, but they all work together to increase the security posture of your endpoint.
On the endpoint, you will have an agent, many are extremely lightweight, and the purpose of the agent is to stream data to the console for aggregation and correlation. This agent operates within the kernel space giving it access to the i/o of the machine (input/output), generally in the form of filter driver.
The data collected and streamed is called telemetry and includes (but absolutely not limited to)
- Process creation and process trees
- Command lines being run on the endpoint
- Hashes of files and signers of said files
- Modules being loaded by processes
- Files and Registry operations (changes/modifications/deletions)
- DNS and Network Connections (websites being accessed along with IP addresses of device and external destination)
As you can see that’s quite a bit of data which an EDR vendor has access to and it’s partially the reason we are writing this article.
Once the above data has been streamed to either the cloud or on-prem device the analytics start to work and IOCs and IOAs are identified (Indicators of Compromise, Indicators of Attack). This is done by leveraging the D&R rules we mentioned earlier, when something matches the rule, the appropriate action is taken against the item in question.
Actions taken can vary depending on the EDR in question and what the rule tells it to do (some EDR are far more modular than others). The general actions most EDRs support in this situation are
- Isolating the host
- Generally if this is done it will allow communication to the console only, or potentially allow certain pre-defined IP addresses to connect for incident response purposes).
- Killing or Suspending processes
- This is more common, isolating the host is a far more extreme response. Within this action you would see files quarantined or deleted, files blocked throughout the organization based on hash, and obviously killing the process in question to prevent further spread/attack.
The depth of what can be done by your EDR depends on how modular the EDR is. Some give you the ability to create your own rules from scratch, some limit you to prebuilt rules and leveraging their ML for responses. Determining the level of EDR you need is one of the first steps when choosing an EDR for your environment.
- Why a Kernel driver, didn’t that take down machines recently?
Yes, a kernel driver was partially responsible for taking down machines as part of a CrowdStrike update. There have only been a couple instance of catastrophic outages pertaining to a kernel driver in over 30 years.
Kernel drivers are leveraged for both EDR and EPP solutions as a part of gaining extremely deep visibility into the actions of a machine, such as event that user-mode can miss or be able to see them earlier in the lifecycle than user mode would report. Examples of items the kernel can see faster and have better access to are
- Process start or thread start
- DLL files being loaded
- File and Registry operations
Extremely critical items you want monitored as quickly as possible when they are invoked. Adding to this, kernel mode gives the application the capability to block or modify an operation before it completes, user mode is limited to upon completion. This means denying a file open command or killing a socket connect action.
The most important aspect of why kernel level drivers are used is to prevent items from within user mode from shutting down crucial processes or services associated with the EDR. Imagine a scenario where all you need to do is right click and “terminate process” on an EDR, or leverage PowerShell by invoking System.Runtime.InteropServices along with $PROCESS_TERMINATE. Not a great solution if you can kill it off and render it useless. This self-protection being at the kernel level ensures that it cannot happen easily (there are still ways to do it, just not easily).
- How do the driver and agent cooperate?
This is where we need to get a bit deeper, but I will try and keep this at a high level.
- The kernel driver will observe an action, such as Powershell being invoked or an executable being run on the device.
- It then emits an event to the user-mode service.
- Once the event is received the local policy/rules/machine learning will decide to allow/block/contain or collect more data on what is occurring.
- A decision is returned to the driver for what’s considered an inline block or
- The agent executes a response such as killing the process, isolating the machine, or quarantining the process/file.
Once the above is done the data is streamed back to the on-prem or cloud appliance and is correlated for future usage.
Above we mentioned inline block which is different than other actions of the EDR (observe, which is where an EDR excels), there are major differences in the two actions. This comes down to preventing vs. observing.
Inline focuses on things like opening a known malicious payload which will return an inline block. The inline actions are also responsible for network blocks via WFP (Windows Filtering Platform) and denying hostile handles to the EDR processes (such as trying to kill them off with the above-mentioned actions).
It’s important to note that EDRSilencer and EDRKillShifter are examples of ways in which EDRs can be manipulated by leveraging the same WFP as described above.
On the other side we have Observe, or we could call it Telemetry and Respond.
This is where items are monitored and correlated, once the telemetry is sent it will take a response action. Commonly you will see this with suspicious parent items executing child processes. LOLBins (Living of the Land Binaries) are a common suspicious parent/child chain, along with abuse of the Windows Scripting Host or attempts to elevate privileges abnormally.
This is how the EDR (and its components) all work and hopefully this gives a better understanding of what all the solutions have access to and can report on! As always this should be part of your security stack and is not a silver bullet to keep you safe from threats.
