Inhalt
Modern EDR and XDR solutions are able to detect suspicious behavior. The widely used Elastic solution has integrated this feature with Elastic Defend since 2019 and offers industry-leading transparency. Below we show how security experts work with it. First, some general information:
Endpoint Detection and Response
Endpoint detection and response systems (EDR) are a central component of comprehensive IT security concepts. As a further development of classic antivirus programs, they continuously monitor the behaviour of endpoints and search for signs of potential security breaches or attacks. The function of an EDR system is also included in the even more comprehensive XDR systems (eXtended Detection and Response), which also analyze network traffic in a threat-oriented manner. Managed Detection and Response (MDR) systems have the same functions as EDR and XDR, but offer round-the-clock managed services for monitoring end devices and eliminating and remedying threats.
Transparency through an open source approach
The Elastic Security detection and response solution was expanded into a comprehensive product family with the acquisition of Endgame in 2019. One special feature is that Elastic, a provider rooted in the open source movement, published the corresponding detection rules for its EDR solution Elastic Defend on Github shortly afterwards. The company had previously published its SIEM detection rules.
With the exception of machine learning components, all detection logic for the Windows, Linux and macOS operating systems can be found in the protections-artifacts repo. This transparency is rare in the IT security industry and may seem strange at first glance. However, in line with the security concept of open source software, this approach makes a lot of sense as it has many advantages:
- Better understanding of how it works
- Detection of gaps in detection rules
- Opportunity for collaboration and exchange
- Quality assurance through the multiple-eye principle
Filtering out suspicious processes
Within the IT security community, Elastic’s publications of detection rules have repeatedly generated positive feedback, most recently regarding call stack telemetry from Microsoft Windows Threat Intelligence Event Tracing for Windows (Ti-ETW). By way of explanation, call stacks are very useful for both technical detection and threat hunting as they provide a lot of context to the activities of a process. This is valuable because, simply put, the call stack lists the logical flow of all functions imported and called by a program from the Microsoft API.
transparency and own operation
By deciding to publish its detection logic, Elastic is deliberately bucking a negative trend. Apart from OpenEDR, no other EDR provider is prepared to do so. Instead, all other vendors refer at best to abstract metrics such as MITRE ATT&CK, which do not allow any reliable, qualitative classification. This convenient policy can become problematic for customers in the medium term. In the SIEM environment, for example, BaFin has long been demanding transparency from banks and insurance companies regarding the functionality of use cases. It is not unlikely that the supervisory authority will also demand more transparency for EDR systems in the long term.
Elastic also scores highly in terms of cloud compulsion with freedom of choice and a high level of data protection, which is extremely relevant in terms of confidentiality and is not least a focus in Germany. After all, it should not be forgotten that US companies are obliged to hand over data stored in their cloud to their own authorities on demand, even if the data is stored in an EU-based data center.
Detection logic
The detection logics published by Elastic can be divided into the following categories:
- YARA signature-based recognition for files and memory
- Behavior-based detection in the form of EQL, KQL or ES|QL
- Ransomware detection
Behavior-based detection in Elastic Defend
By correlating file operations, network data, memory accesses and system events, malicious behavior is detected and prevented. Examples of this include
- Execution of unknown or suspicious processes
- Suspicious file activities
- Unusual network activities
- Abnormal user behavior patterns
- Suspicious system configuration changes
- File and folder access changes
- Execution of privileged actions by unauthorized users
The following examples show how behavior-based detection is implemented in Elastic Defend:
Example 1:
OS Credential Dumping: LSASS Memory (ID: T1003.001)
LSASS memory dumping” involves accessing the working memory of the LSASS process (Local Security Authority Subsystem Service) in order to extract sensitive information such as login information, passwords or tokens. This information can then be used by the attacker to gain access to privileged accounts or to access the system later.
The generated dump file:
The generated alarm in Elastic Defend:
The corresponding rule from the Elastic Repository:
In this example, the following behavior is detected:
- Calling the Windows API Calls OpenProcess or OpenThread
- Target process is lsass.exe
- The executing process imports the MiniDumpWriteDump function from the system libraries dbgcore.dll or comsvcs.dll
Example 2:
In this example, we see the execution of meterpreter shellcode in a newly started process (calc.exe). Meterpreter is a component of the Metasploit framework and, along with Cobalt Strike, one of the most frequently used C2 frameworks[1].
A look at the “Potential Injection via Asynchronous Procedure Call” rule:
[1] Sources:
Meterpreter, a key component of the Metasploit framework, is one of the few highly-prevalent malware families we see impact Windows, Linux, and macOS.(Elastic Global Threat Report 2023)
Adversaries have long used open source and leaked versions of commercial frameworks, most notably Metasploit and Cobalt Strike.(Red Canary 2023 Threat Detection Report)
This rule recognizes the call of the QueueUserAPC function
APC Queue
If a process is in a kind of waiting or sleeping state, this is referred to as an “alertable state“. Further instructions are then written to a so-called APC queue. The Windows kernel processes these instructions until the process leaves the “alertable state”. The code injection process is as follows:
1. start a new process (calc.exe – Suspended)
2. Allocate memory in the new process
3. write meterpreter shellcode into the memory
4. make the memory area executable
5. insert the code into the APC queue and start the process:
Result
The successful code injection via APC queue leads to a meterpreter session:
Successful detection and alerting in Elastic Defend:
Conclusion
As these examples show, behavior-based detection with Elastic Defend is a powerful but easy-to-use tool that reaches down to the level of individual function calls in the call stack and even includes modern obfuscation methods such as Threadless Injection or PoolParty Injection.
Do you want to comprehensively detect, analyze and defend against cyber attacks without drowning in a flood of alarms?
Discover the cloud-free MDR solution from SECUINFRA now:
Further links
https://www.elastic.co/security-labs/doubling-down-etw-callstacks
