2024-11-11 –, WestIn - Munich
Today, a prep phase against endpoint protection (EPP) and endpoint detection and response (EDR) products is part of every red team engagement, and preparing to create evasive malware that bypasses the targeted EDR to gain initial access can often be very time consuming. In general, when preparing malware such as a shellcode loader or similar, we want to be as sure as possible that our malware will be able to bypass the targeted EDR. The simplest approach is to start building malware and use trial and error to see if your malware is able to evade the EDR (evasion defined as not prevented and not detected) or if the malware is caught by the EDR. In order to build not only better, but more effective malware, it really helps to go beyond trial and error testing and start investing time and energy in reversing and debugging EDRs and trying to better understand the logic of the detection mechanisms they implement.
To build more evasive or effective malware, you need to know your enemy, in this case the EDR. By now most community members are aware that modern EDRs use things like the Antimalware Scan Interface (AMSI) to detect malicious powershell activity, or use user mode hooking to detect potentially malicious behaviour in the context of Windows APIs, or use kernel drivers to register various types of kernel callback routines such as ProcessNotifiyRoutine to detect when a new process is created, and so on. However, in addition to these well-known mechanisms, some EDRs use more sophisticated and unconventional mechanisms that have been used by the game hacking community for many years. By looking at these EDRs more closely, by trying to reverse engineer and debug them, some of these detections can be interpreted as some tricky traps for malware influenced by the game hacking community. In my talk "EDR Analysis: An introduction to reversing sophisticated detection," I will provide insights into how to debug, reverse, and understand these EDR detection mechanisms in detail, as well as how to evade them.
In my role as a red teamer, commercial tester and researcher of security products, I regularly have the opportunity to learn about the latest technologies. In addition to these topics, I have always been fascinated by reverse engineering and find this area extremely exciting. Therefore, I am constantly trying to learn more about debugging and reverse engineering step by step, and at the beginning of this year 2024, I started to take a closer look at some well-known EDRs. The motivation to learn more about reverse engineering and debugging in the context of EDRs is my constant drive to better understand EDRs on Windows, to learn more about Windows Internals, and also to create more evasive and more effective malware.
By now most community members are aware that modern EDRs use things like the Antimalware Scan Interface (AMSI) to detect malicious powershell activity, or use user mode hooking to detect potentially malicious behaviour in the context of Windows APIs, or use kernel drivers to register various types of kernel callback routines such as ProcessNotifiyRoutine to detect when a new process is created, and so on. But in the context of some known EDRs, I started digging a little deeper by debugging and reversing them, and came across interesting detections or chains of detections that rely on several different components, going beyond the most well-known mechanisms I mentioned earlier. Over time, I was able to gain a better understanding of the rather sophisticated and unconventional detection mechanisms of these EDRs. During my learning process, I discovered that some of these concepts have been used in the game hacking community for several years and are now finding their way into the EDR world. During my journey to better understand these detections from these two EDRs, I came across fake DLLs, guard pages, hardware breakpoints, vectored exception handling, etc., and it turned out, or rather I had the impression, that these types of detection mechanisms are designed to serve as a kind of tricky trap for malware.
In my talk "EDR Analysis: An introduction to reversing sophisticated detection" I would like to give the community an insight into how these sophisticated and unconventional detection mechanisms of EDRs are implemented and how I debugged and reversed them. Ultimately, this talk should help the offensive community gain a better understanding of these sophisticated and unconventional detections of EDRs on Windows and also show some ways to effectively work around them. Furthermore, I will bring my own learning process into the talk and encourage other members of the community to experiment and research EDRs themselves.
Reverse Engineering, EDR-Evasion, Malware Development
Daniel Feichter, 38, is from Austria and goes by VirtualAllocEx on Twitter and other platforms. With a background in electronics and communications engineering, he began his career as a junior penetration tester in 2018. After discovering a passion for ethical hacking, he has remained dedicated to the field. In late 2021, he founded his own company, RedOps, to pursue a research-driven focus, particularly on EDRs. Since October 2024, Daniel has also been a member of the ARES Red Team at NVISO, working as a Red Team Operator.
He focuses on learning and researching in the area of Windows Internals, endpoint security, malware development, and reverse engineering. He enjoys sharing his findings through blog posts, conference talks, and workshops, contributing to the community at conferences such as DEFCON 30 (Adversary Village), DEFCON 31 (Red Team Village), SANS Hackfest, BSides Munich, MCTTP etc.
Outside of work, Daniel values spending time with family and friends, playing tennis and has practiced taekwondo consistently for over a decade.