EDR (Endpoint Detection and Response) evasion techniques are becoming increasingly common amongst attackers as they evolve their strategies to bypass security measures without being detected. There are many different types of EDR evasion techniques, many of which are listed on the MITRE ATT&CK website. The complexity and evolution of these methods vary widely; some can be quite simple, exploiting known vulnerabilities or configuration errors, while others involve sophisticated techniques that adapt to countermeasures over time. One of the most popular methods is “reflective loading”.
Reflective loading is the process of injecting payloads directly to host process memory so that the OS will think that the code executed from memory belongs to the actual process. Many tools in Windows, for example, use this legitimately for debugging and virtualization purposes.
This research will cover three different variants of this technique, showing how they can be used for EDR evasion. In the end, we explain what this means for organizations and EDR vendors, and what security professionals can do to enhance their security posture.
Organizations should be aware of these attacks as they can bypass your organization’s primary defense mechanisms, leading to data breaches, operational disruption and significant financial and reputational damage.
The first tactic uses reflective loading to run Mimikatz, while evading AV and EDR products like Windows Defender. While Windows Defender supposedly blocked this method, we show a new way to handle dependencies. This is done by using DLL forwarding and ApiSet Improvements, allowing LoadDLL to preload DLL files from memory or disk. This means these files are imported by DLLs and EXE rather than LoadLibrary(). As a result, the attacker can load their own copy of DLLs, bypassing EDR hooks.
The second tactic shows how to implement a framework for interactions with reflectively loaded modules. This is done by using MemoryAPI to access data, BufferAPI to buffer local objects to remote memory, and ModuleAPIs to represent functions while executing code on the remote client.
Such a framework can be used to reflectively load DLLs into a remote host’s memory, allocate objects and then call functions inside the DLL. This allows using a local Reflective DLL technique on multiple hosts at once.
The third tactic helps overcome network latency issues when interacting with native DLL modules, by creating a “scripting language” for these interactions. This language, which we called DevalScript, is based on the following premises:
Reflective loading allows executing payload on remote hosts without being detected by XDR systems. This is because it provides the following advantages:
It’s recommended for security professionals to follow these steps:
For more information, reach out to us at [email protected].
Begin your journey in security validation and see why leading companies trust us with their cybersecurity validation.