Introduction
During our SOC and Red Team researches, we like to give some time to understand the endpoints and their protection methods. EDR records system activities and events taking place on endpoints and provides security teams with the visibility they need to uncover incidents.
Recently, we have installed FireEye EDR on a Windows 10 17763 operating system with all defensive features enabled.
When we analyzed EDR’s capabilities, we did not see much about memory scan and memory exploit mitigation. From that perspective, we decided to focus on process injection techniques in our research.
Process injection in Windows appears to be a well-researched topic, with many techniques now known and implemented to inject from one process to the other. Process injection techniques are used by malware to gain more stealth (e.g., run malicious logic in a legitimate process) and to bypass security products (e.g., AV, DLP and personal firewall solutions) by injecting code that performs sensitive operations (e.g., network access) to a process which is privileged to do so.
Process injection techniques are classified as three categories;
- Process spawning – these methods create a process instance of a legitimate executable binary, and typically modify it before the process starts running. Process spawning is very “noisy,” and as such, these techniques are suspicious and not stealthy.
- Injecting during process initialization – these methods cause processes that are beginning to run, to load their code (e.g., AppInit DLLs). Typically these techniques require UAC elevation (due to writing to privileged registry keys or privileged folders). Additionally, such methods are typically mitigated by the Extension Point Disable Policy.
- Injecting into running processes (“true process injection”) – these are the most interesting techniques, which are the focus of this paper.
In this EDR bypass, we continued with the process spawning a basic process injection method (Following two images summaries it).
We used C# as the primary preference for our process injection tests. First, we started by creating a calc shellcode with msfvenom. After that, we injected it into mspaint process, which was created by our executable.
It was strange that the injection activity was not marked as abnormal behavour and popped up a calculator.
After our calculator experiment, we created a meterpreter reverse https payload shellcode. We tried to inject it directly into a mspaint process, but our executable got caught by a “signature detection” before it was executed. If this is the case, most probably, EDR was detecting the static shellcode inside our binary.
To bypass this signature detection, we need to remove the shellcode from our binary. To do this, we created a meterpreter shellcode and saved it inside a .bin file and put it inside our web server directory. We changed our C# code to download this .bin file, get its contents and inject it inside the process.
After this, the EDR was bypassed and we got a fully operational meterpreter shell. We got a bit disappointed because it was relatively very straight forward than the other EDR’s we had tried.
Notes:
- Even if the EDR does not detect this executable file, it was still too easy to analyze and detect by an analyst, but we will handle this topic on another document about red teaming.
- EDR is not magic.
- * We found out that one of the FireEye EDR processes is vulnerable to process injection, so you can inject your meterpreter shell inside FireEye and get a meterpreter shell through the EDR itself. After confirmation with FireEye, we will update this post
