An emerging EDR evasion technique has proved significantly harder to detect when researchers combined it with additional methods for sidestepping endpoint security tools.
Flashpoint just published research on "process parameter poisoning," a recently discovered evasion technique designed to cheat endpoint detection and response (EDR) in Windows. First described by researchers Max Hirschberger and Ogulcan Ugur back in July, the technique relies on the fact that security tools and threat actors have historically leaned on a small set of Windows APIs to detect or execute process injection. These APIs include (but are not necessarily limited to) VirtualAllocEx(), WriteProcessMemory(), and MapViewOfFile2().
Researchers at the company discovered a way for an attacker to hide a malicious payload directly inside the standard process initialization structures that are launched alongside the process itself.
An attacker already executing code on a Windows system can create a "sacrificial process" and abuse the startup parameters Windows automatically transfers into that new process. This is all done without using some of the memory allocation and write operations that EDR products traditionally monitor for process injection.
Back in July, Hirschberger and Ugur tested the strategy against four unspecified market-leading EDR offerings, and said in their blog post at the time that "code injection succeeded in all cases and no alerts were created, even though the EDRs were configured to detect, block and remediate."
Flashpoint's researchers built and tested their own implementation of the technique in Rust in order to assess how it might be able to circumvent certain endpoint detection mechanisms. Flashpoint's work independently validates the original research while exploring how the technique behaves when implemented in Rust and combined with additional evasion measures.
In this case, Flashpoint tested the base technique through its Rust POC against a commonly used open source EDR platform with an extended detection and response (XDR) component. The EDR platform failed to produce any alerts from executing the binary, but the XDR component blocked subsequent activity by the second-stage payload.