Introduction
Chapter 1
EDR Components
Instead of just being a detection software, an EDR is a complex ecosystem of various components co-working with each other to analyze data and prevent malicious actions and software.
While each EDR vendor adds their own flavor, it is important to know the generic EDR formula so as to get a idea on how the basic underlying systems work.
It is also to be noted that while the generic formula remains the same, each commercial EDR is vastly different to each other. Red-teamers must keep in mind to model their actions and tooling as per the client's security solution.
Telemetry
Telemetry in the context of EDRs are the raw data generated by a sensor or the host. This raw data can be refined and analyzed to determine if the actions are malicious or not.
Every action on the system generates some telemetry in one form or another. These telemetries add up to define a chain of events which can be classified as safe or unsafe.
On its own, information about how a process was created or a file was accessed rarely provides enough context to make an informed decision regarding actions to be taken. Moreover, a process detected by an EDR can terminate at any point in time. Therefore, it is important for the telemetry feeding into the EDR to be as complete as possible.
The EDR then passes the data to its detection logic. This detection logic takes all available telemetry and uses some internal method, such as environmental heuristics or static signature libraries, to attempt to ascertain whether the activity was benign or malicious and whether the activity meets its threshold for logging or prevention.
Sensors
EDR sensors work passively by intercepting data flowing through an internal process, extracting information, and forwarding it to the central agent.
Because these sensors often need to sit inline of some system process, they must also work incredibly fast. Even minor delays can add up pretty fast.
Although Windows has numerous telemetry sources available, EDRs typically focus on only a select few. This is because certain sources may lack data quality or quantity, may not be relevant to host security, or may not be easily accessible.
While some sensors are built into the operating system, such as the native event log, EDRs also introduce their own sensor components to the system, such as drivers, function-hooking DLLs, and minifilters.
Detections
Detections are the logic that correlates discrete pieces of telemetry with some behavior performed on the system. A detection can check for a singular condition (for example, the presence of a file whose hash matches that of known malware) or a complex sequence of events coming from many different sources (for example, that a child process of chrome.exe was spawned and then communicated over TCP port 88 with the domain controller).
These rules are written by detection engineers. Some detection engineers work for the EDR vendor and so must carefully consider scale, as the detection will likely affect a substantial number of organizations.
On the other hand, detection engineers working within an organization can build rules that extend the EDRâs capabilities beyond those that the vendor provides to tailor their detection to their environment.
An EDRâs detection logic usually exists in the agent and its subordinate sensors or in the backend collection system. Some EDRs utilize both. But each approach has it's pros and cons.
EDR agent detections can take immediate actions but fail against more advanced attacks whereas backend detections can analyze more sophisticated attacks but the response might be delayed.
Agent
The EDR agent is an application that controls and consumes data from sensor components, performs some basic analysis to determine whether a given activity or series of events aligns with attacker behavior, and forwards the telemetry to the main server, which further analyzes events from all agents deployed in an environment.
If the agent deems something malicious, it:
Logs that malicious activity in the form of an alert sent to a central logging system (SIEM)
Blocks the malicious operationâs execution by returning values indicating failure to the program that is performing the action
Deceives the attacker by returning to the caller invalid values, such as incorrect memory addresses or modified access masks, causing the offensive tooling to believe that the operation completed successfully even though subsequent operations will fail.
Identifying Malicious Activity
To build successful detections, an engineer must understand more than the latest attacker tactics; they must also know how a business operates and what an attackerâs objectives might be. Then they must take the distinct and potentially unrelated datapoints gleaned from an EDRâs sensors and identify clusters of activity that could indicate something malicious happening on the system.
But this is not that easy. For example, if a new service is created in a system, it doesn't necessarily mean that a malware has installed it's persistence in the system. It's more likely that the user has installed some legitimate software or it's the byproduct of some poorly implemented installer.
The best way to make informed decisions is to consider the context of the actions in question. Compare them with user and environmental norms, known adversary tradecraft and artifacts, and other actions that the affected user performed in some timeframe.
For example, the below table shows the timeline of a malicious chain of events.
Remember that the overwhelming majority of activities on a system are benign, assuming that something horrible hasnât happened. Engineers must determine how sensitive an EDRâs detections should be based on how many false negative the customer can tolerate.
One way that a product can meet its customersâ needs is by using a combination of so-called brittle and robust detections.
Brittle Vs Robust Detections
Brittle Detections
Brittle detections are rules that are designed to detect a specific artifact (a string or sha256 hash). These rules help to effectively detect malicious files containing those artifacts but can be easily bypassed with slight variation to those artifacts.
For example- an attacker can just change the variable names in the source code of mimikatz (a tool used to extract password hashes from LSASS) and the EDR will fail to detect it.
This is why they are called "brittle". They are extremely specific, often targeting a single artifact. This means that the likelihood of a false positive is almost nonexistent while the likelihood of a false negative is very high.
Despite their flaws, these detections offer distinct benefits to security teams. They are easy to develop and maintain. They can also effectively detect some common attacks. For example, a single rule for detecting an unmodified version of the exploitation tool Mimikatz brings tremendous value, as its false-positive rate is nearly zero and the likelihood of the tool being used maliciously is high.
Thus a detection engineer must carefully consider what data to use when creating brittle detections. The best brittle detections target attributes that are either immutable or at least difficult to modify.
Robust Detections
Robust detections aim to detect behaviors and could be backed by machine-learning models trained for the environment. They dynamically analyze incoming telemetry to detect malicious activity. Most robust detections are simply rules that more broadly try to target a technique.
A robust ruleset backed by a machine learning model might flag the modified file in the previous example as suspicious because it is unique to the environment or contains some attribute that the classification algorithm weighted highly.
While this seems to be great, it comes with it's own drawbacks. These types of detections exchange their specificity for the ability to detect an attack more generally, reducing the likelihood of false negatives by increasing the likelihood of false positives. Compared to brittle signatures, these rules can be much harder to develop due to their complexity.
Additionally, the detection engineer must consider an organizationâs false-positive tolerance. If their detection has a very low false-negative rate but a high false-positive rate, the EDR will behave like the boy who cried wolf. If they go too far in their attempts to reduce false positives, they may also increase the rate of false negatives, allowing an attack to go unnoticed.
Because of this, most EDRs employ a hybrid approach, using brittle signatures to catch obvious threats and robust detections to detect attacker techniques more generally.
Example - Elastic Detection Rules
Elastic EDR leverages event data to identify alerts from Elastic Defend, focusing on potential threats while excluding non-relevant modules. The Elastic Agent sends data to the Elastic stack, and Elastic's "Defend" integration allows it to function as an EDR for hosts.
Elastic is also the one of the only EDR vendors publicly release its detection rules.
For example, consider Elasticâs rule for detecting Kerberoasting attempts that use Bifrost, a macOS tool for interacting with Kerberos:
query = '''
event.category:process and event.type:start and
process.args:("-action" and ("-kerberoast" or askhash or asktgs or asktgt or s4u or ("-ticket"
and ptt) or (dump and (tickets or keytab))))
'''This rule checks for the presence of certain command line arguments that Bifrost supports. An attacker could trivially bypass this detection by renaming the arguments in the source code (for example, changing -action to -dothis) and then recompiling the tool. Additionally, a false positive could occur if an unrelated tool supports the arguments listed in the rule.
But this isn't a bad rule. Not all adversaries operate at the same level. Many threat groups continue to use off-the-shelf tooling. This detection serves to catch those who are using the basic version of Bifrost and nothing more.
Because of the ruleâs narrow focus, Elastic should supplement it with a more robust detection that covers these gaps; which it has also provided
query = '''
network where event.type == "start" and network.direction == "outgoing" and
destination.port == 88 and source.port >= 49152 and
process.executable != "C:\\Windows\\System32\\lsass.exe" and destination.address !="127.0.0.1"
and destination.address !="::1" and
/* insert False Positives here */
not process.name in ("swi_fc.exe", "fsIPcam.exe", "IPCamera.exe", "MicrosoftEdgeCP.exe",
"MicrosoftEdge.exe", "iexplore.exe", "chrome.exe", "msedge.exe", "opera.exe", "firefox.exe")
'''This rule targets atypical processes that make outbound connections to TCP port 88, the standard Kerberos port. While this rule contains some gaps to address false positives, itâs generally more robust than the brittle detection for Bifrost. Even if the adversary were to rename parameters and recompile the tool, the network behavior inherent to Kerberoasting would cause this rule to fire.
If the adversary modified the tool's cli to look like one of the whitelisted files and also modified the toolâs command line arguments, they would evade both the brittle and robust detections.
Most EDR agents strive for a balance between brittle and robust detections but do so in an opaque way, so an organization might find it very difficult to ensure coverage, especially in agents that donât support the introduction of custom rules.
Agent Designs
Agents of various EDR vendors can be broadly classified into three categories.
Basic
Agents are composed of distinct parts, each of which has its own objective and type of telemetry it is able to collect. Most commonly, agents include the following components:
The static scanner - An application, or component of the agent itself, that performs static analysis of images, such as Portable Executable (PE) files or arbitrary ranges of virtual memory, to determine whether the content is malicious. Static scanners commonly form the backbone of AV services.
The hooking DLL - A DLL that is responsible for intercepting calls to specific application programming interface (API) functions.
The kernel driver - A kernel-mode driver responsible for injecting the hooking DLL into target processes and collecting kernel-specific telemetry.
The agent service - An application responsible for aggregating telemetry created by the preceding two components. It sometimes correlates data or generates alerts. Then it relays the collected data to a centralized EDR server.
This basic design doesnât have many sources of telemetry. Its three sensors (a scanner, a driver, and a function-hooking DLL) provide the agent with data about process-creation events, the invocation of functions deemed sensitive (such as kernel32!CreateRemoteThread), the signatures of files, and potentially the virtual memory belonging to a process.
This basic EDR would be incapable of detecting files being created, deleted, or encrypted on the host.
Intermediate
While a basic agent can collect a large amount of valuable data with which to create detections, this data may not form a complete picture of the activities performed on the host.
Usually, the endpoint security products deployed in enterprise environments today have substantially expanded their capabilities to collect additional telemetry.
Most of the agents that attackers encounter fall into the intermediate level of sophistication. These agents not only introduce new sensors but also use telemetry sources native to the operating system. Additions made are:
Network filter drivers - Drivers that perform network traffic analysis to identify indicators of malicious activity, such as beaconing.
Filesystem filter drivers - A special type of driver that can monitor for operations on the host filesystem.
ETW consumers - Components of the agent that can subscribe to events created by the host operating system or third-party applications.
Early Launch Antimalware (ELAM) components - Features that provide a Microsoft-supported mechanism for loading an antimalware driver before other boot-start services to control the initialization of the other boot drivers. These components also grant the ability to receive Secure ETW events, a special type of event generated from a group of protected event providers.
This design builds upon the basic architecture and adds many new sensors from which telemetry can be collected. For instance, this EDR can now monitor filesystem events such as file creation, consume from ETW providers that offer data the agent wouldnât otherwise be able to collect, and observe network communications on the host through its filter driver, potentially allowing the agent to detect command-and-control beaconing activity. It also adds a layer of redundancy so that if one sensor fails, another might be able to pick up the slack.
Advanced
Some products implement more advanced features to monitor specific areas of the system in which theyâre interested. Due to these features being highly specific, they are not commonplace.
Hypervisors - They provide a method for the interception of system calls, the virtualization of certain system components, and the sandboxing of code execution. These also provide the agent with a way to monitor transitions in execution between the guest and host. Theyâre commonly leveraged as a component of anti-ransomware and anti-exploit functionality.
Adversary deception - It Provides false data to the adversary instead of preventing the malicious codeâs execution. This may cause the adversary to focus on debugging their tooling without realizing that the data in use has been tampered with.
Types Of Bypasses
Threat actors leverage four types of bypasses in order to operate undetected.
Configuration bypass - Occurs when there is a telemetry source on the endpoint that could identify the malicious activity, but the sensor failed to collect data from it, leading to a gap in coverage. For example, even if the sensor is able to collect events from a specific ETW provider related to Kerberos authentication activity, it might not be configured to do so.
Perceptual bypass - Occurs when the sensor or agent lacks the capability to collect the relevant telemetry. For example, the agent might not monitor filesystem interactions.
Logical bypass - Occurs when the adversary abuses a gap in a detectionâs logic. For example, a detection might contain a known gap that no other detection covers.
Classification bypass - Occurs when the sensor or agent is unable to identify enough datapoints to classify the attackerâs behavior as malicious, despite observing it. For example, the attackerâs traffic might blend into normal network traffic.
Configuration bypasses are one of the most common techniques. Sometimes they are even used unknowingly, as most mature EDR agents have the ability to collect certain telemetry but fail to do so for one reason or another, such as to reduce event volume.
Perceptual bypasses are generally the most valuable because if the data doesnât exist and no compensating components cover the gap, the EDR has no chance of detecting the attackerâs activities.
Logical bypasses are the trickiest to pull off because they generally require knowledge of the detectionâs underlying logic.
Lastly, classification bypasses require a bit of forethought and system profiling, but if executed well, classification bypasses can approach the efficacy of a perceptual bypass for less work than that required for a logical bypass.
These classifications let us discuss blind spots in our detection strategies with greater specificity.
Perceptual bypasses are important to understand but are often the hardest to find. If our EDR simply lacks the ability to collect the required data, we have no choice but to find another way to build our detection.
Logical bypasses happen due to decisions made when building the detection rules. Because SOCs arenât staffed with an infinite number of analysts who can review alerts, engineers always seek to reduce false positives. But for every exemption they make in a rule, they inherit the potential for a logical bypass.
Finally, classification evasions can be the trickiest to protect against. To do so, engineers must continue to tune the EDRâs detection threshold until itâs just right.
Thus EDR evasion isnât a simple matter of finding a silver bullet. Rather, itâs the process of abusing gaps in a sensor to fly under the threshold at which the EDR generates an alert or takes preventive action.
Last updated