New Windows Process Injection Technique Bypasses EDR Without WriteProcessMemory
A novel 'console named-pipe injection' method evades common EDR detection by delivering payloads via a child process's standard input and repurposing existing memory, bypassing the typical allocate-write-execute sequence.
Security researchers have detailed a new Windows process injection technique, dubbed "console named-pipe injection," that adeptly bypasses traditional Endpoint Detection and Response (EDR) monitoring by avoiding the use of two commonly targeted APIs: VirtualAllocEx and WriteProcessMemory. This method, disclosed by researcher Two Seven One Three, represents a significant evolution in stealthy code execution, as it delivers malicious payload bytes through a child console process's redirected standard input and then repurposes memory that Windows has already allocated and populated.
Traditional process injection, tracked by MITRE ATT&CK as T1055, typically follows a predictable sequence: an attacker allocates memory in a target process, writes their malicious code into that allocated space using WriteProcessMemory, and then executes it by starting a new thread or hijacking an existing one. EDR solutions are frequently tuned to detect this allocate-write-execute chain by monitoring for suspicious memory allocation patterns and thread manipulation activities.
The console named-pipe injection technique circumvents this by leveraging Windows' interprocess communication (IPC) mechanisms rather than direct cross-process memory writes. The attack begins with the injector creating a child console process, such as legitimate utilities like nslookup.exe or netsh.exe. Crucially, the standard input of this child process is redirected to a named pipe, allowing the injector to send its payload to the child process by writing to the pipe.
Once the payload bytes are present in the child process's address space as it processes the input from the pipe, the injector locates these bytes. The proof-of-concept demonstrates that the injector can then use VirtualProtectEx to change the memory protection of the existing committed pages to make them executable. Subsequently, the injector suspends a thread within the child process, modifies its instruction pointer to point to the newly executable payload, and then resumes the thread, thereby executing the injected code.
While this technique bypasses the direct use of VirtualAllocEx and WriteProcessMemory for payload delivery, it is not entirely invisible. Detection remains possible by correlating behavioral anomalies. High-value indicators for defenders include an unusual parent process launching an interactive console binary with redirected standard input handles, suspicious writes to standard input, the use of VirtualProtectEx to grant execute permissions to previously non-executable memory regions, and thread context manipulation (SetThreadContext) followed by thread resumption.
Sysmon Event IDs 17 and 18 can provide telemetry for named pipes, though anonymous standard-input pipes might require more granular endpoint visibility. Security teams are advised to move beyond single-API alerts and focus on correlating the complete sequence of events. Baseling normal console automation and hunting for rare combinations of these activities, rather than flagging every instance of conhost.exe or pipe operations, will be key to effective detection.
This research underscores a critical lesson for security tool engineering: reliable detection of advanced process injection techniques requires a holistic approach. Instead of relying on the detection of specific API calls, defenses must be capable of analyzing the entire lifecycle of process creation, handle sharing, memory protection changes, and control flow alterations to effectively counter evolving threats.