The Truth About EDR: False Positives and Bypasses Uncovered
The adoption of Endpoint Detection and Response (EDR) products has become a cornerstone in the cybersecurity strategy of many organizations. These products are designed to monitor, detect, and respond to potential threats and suspicious activities on endpoints such as computers, servers, and other devices within a network. However, as much as these products are useful, there's a dark reality behind them that organizations need to understand.
Consider a company ABC that invested in an EDR solution to bolster their cybersecurity posture. They went through the rigorous process of installation and migration of their existing data and workflows to the new EDR solution. They felt confident that their network was now fully secured, but they were wrong.
One day, their EDR solution raised a suspicious activity alert, indicating a potential threat on one of their endpoints. They immediately dispatched their cybersecurity team to investigate the issue. After hours of investigation, they discovered that the alert was a false positive triggered by EDR telemetry noise. In other words, the telemetry data generated by their EDR solution was not precise enough, and as a result, it produced false positives.
The cybersecurity team shrugged off the issue and marked it as a one-off event. However, they were unaware that the lack of precise telemetry data would become a huge problem for them in the future. The EDR solution provided a false sense of security that left the company vulnerable to more sophisticated attacks.
The attackers knew that the EDR solution in use had a weak telemetry system and took advantage of it. They launched a sophisticated attack that bypassed the EDR solution without raising any alarms. The attackers went undetected and moved laterally across the company's network, causing significant damage.
The company was left wondering what went wrong despite investing a significant amount of money and resources in an EDR solution. The answer was simple, their EDR solution was not providing enough telemetry data, which led to a false sense of security and left them vulnerable to attacks.
However, attackers can use techniques such as code obfuscation and process hollowing to evade detection by EDR solutions.
Code obfuscation involves modifying the code of an application or malware to make it difficult for EDR solutions to analyze.
For example, an attacker can use encryption or compression techniques to hide the malicious code. EDR solutions may not be able to analyze the encrypted or compressed code and may miss the threat.
Process hollowing is another technique used to evade EDR solutions. In process hollowing, an attacker creates a new process in the suspended state and replaces its code with malicious code.
The attacker then resumes the process, and the malicious code runs in the context of the legitimate process. EDR solutions may not be able to detect the malicious activity because it appears to be part of a legitimate process.
Let's take a look at a technical code example of process hollowing:
#include <Windows.h> int main(int argc, char* argv[]) { // Create a new suspended process STARTUPINFO si = { sizeof(si) }; PROCESS_INFORMATION pi; if (!CreateProcess(TEXT("C:\\Windows\\System32\\notepad.exe"), NULL, NULL, NULL, FALSE, CREATE_SUSPENDED, NULL, NULL, &si, &pi)) { return 1; } // Allocate memory for the malicious code SIZE_T size = 4096; LPVOID address = VirtualAllocEx(pi.hProcess, NULL, size, MEM_COMMIT, PAGE_EXECUTE_READWRITE); if (!address) { return 1; } // Write the malicious code to the allocated memory BYTE code[] = { 0x90, 0xc3 }; // NOP and RET SIZE_T written; if (!WriteProcessMemory(pi.hProcess, address, code, sizeof(code), &written)) { return 1; } // Replace the code of the suspended process with the malicious codeHANDLE thread = CreateRemoteThread(pi.hProcess, NULL, 0, (LPTHREAD_START_ROUTINE)address, NULL, 0, NULL); if (!thread) { return 1; } // Resume the suspended process ResumeThread(pi.hThread); return 0; }This code creates a new suspended process using the Windows API function CreateProcess and then allocates memory in the suspended process using VirtualAllocEx. It then writes the malicious code (two assembly instructions that do nothing but return) to the allocated memory using WriteProcessMemory. Finally, it replaces the code of the suspended process with the malicious code using CreateRemoteThread and resumes the suspended process.
The EDR Telemetry Project: A Comprehensive Comparison
To address the issue of EDR telemetry, a group of experts came together to create the EDR Telemetry project. The goal of the project is to encourage EDR vendors to be more transparent about the telemetry they provide to their customers. The project aims to compare the telemetry generated by different EDR products, helping users make informed decisions when selecting EDR products.
The project methodology involves a systematic approach to ensure the accuracy and reliability of the information presented. The comparison table compares the available telemetry for different EDR products. The data in the table does not represent the capability of each EDR product to detect or prevent a threat, but only focuses on the available telemetry for each product.
- Official project page: https://github.com/tsale/EDR-Telemetry
- Comparison table: https://docs.google.com/spreadsheets/d/1ZMFrD6F6tvPtf_8McC-kWrNBBec_6Si3NW6AoWf3Kbg/edit?usp=sharing
In conclusion, the adoption of EDR solutions is not enough to secure organizations from cyber threats. The EDR Telemetry project provides a comprehensive comparison of EDR products' telemetry data, which is crucial in building additional detections and conducting threat hunting. Organizations need to understand that investing in EDR solutions is not enough, and they need to ensure that the EDR solution they choose provides enough telemetry data to detect sophisticated attacks.
We understand the importance of having a reliable and effective cybersecurity solution to protect organization from emerging threats such as malicious software and APTs. That's why we offer our clients a strong partnership for gathering Scrutiny Engine Detection Intelligence through our EDR companion, which allows us to provide the most effective tools and strategies to enhance your security posture.
To stop advanced attacks in their early stages, it is essential to detect and respond to them as quickly as possible. Some of the major processes where advanced attacks can be stopped include identifying and blocking malicious IPs, detecting and blocking malicious files, and identifying and stopping command and control (C2) communications.
By leveraging the co-pilot phase of advanced detection, customers can significantly reduce their mean time to detect (MTTD) and mean time to respond (MTTR) to advanced threats. This can be achieved by creating custom rules and policies, as well as by integrating our threat intelligence feeds.
By working in parallel with EDR solutions, the scrutiny engine helps to reduce the workload of EDR sysops and increases the efficiency of the overall security infrastructure. The scrutiny engine also helps to protect against attacker bypass techniques, such as signature-less attacks, without collecting any data.
In a recent case study, CyberStanc's scrutiny engine was able to detect a previously unknown malware variant that was designed to evade traditional signature-based detection mechanisms.
Our dedicated R&D center is constantly developing cutting-edge technologies to combat emerging threats, and we take pride in offering our clients the best possible service and support. In addition, our Secure-Tech service provides internal and third-party application scrutiny scans, using our convenient Pay-As-You-Go model. This means you can easily access our advanced cybersecurity services without committing to a long-term contract.