New Windows Process Injection Technique Bypasses EDR Monitoring Without WriteProcessMemory

A newly disclosed method for Windows process injection utilizes redirected console input and named pipes to transfer payload data into a child process without invoking the heavily monitored APIs VirtualAllocEx and WriteProcessMemory.

This technique, called console named-pipe injection, highlights the need for endpoint defenses to correlate events across processes, memory protection, thread context, and interprocess communication, rather than relying on a single suspicious API call.

Windows Process Injection Technique Bypasses EDR

Remote process injection has long been a technique used in Windows environments, allowing code to execute within another process. This capability can let malicious activity inherit the context and perceived legitimacy of a trusted application. Conventional remote-thread injection typically follows this sequence:

• OpenProcess/CreateProcess
• VirtualAllocEx
• WriteProcessMemory
• CreateRemoteThread or thread hijacking

Endpoint Detection and Response (EDR) products commonly focus on this sequence because it includes direct cross-process memory allocation and writing, both strong indicators of code injection. Consequently, Microsoft’s process and memory APIs are frequent detection points for user-mode hooks, kernel telemetry, and behavioral rules.

The new research disrupts this model by removing the two most recognizable components: remote allocation through VirtualAllocEx and payload copying via WriteProcessMemory. Instead of writing directly to another process’s virtual memory, this technique reuses data Windows and a console application already store while processing redirected standard input.

The method begins by launching an interactive console application, such as nslookup.exe or netsh.exe, with its standard input handle redirected to a pipe. The parent process retains the write end of the pipe and sends payload bytes using WriteFile.

As the target console process processes its redirected input, the bytes are stored in its own address space. This mechanism allows arbitrary data to be transported into the child’s memory without a conventional remote memory write operation.

The proof of concept reportedly includes a distinctive marker at the beginning of the payload. The injector scans the accessible memory of the child process for this marker, determines the address of the payload immediately following it, changes the protection of the existing memory region with VirtualProtectEx, and redirects a thread’s instruction pointer to the payload location.

This process retains several recognizable post-exploitation actions, such as altering remote memory protection and modifying thread context. However, it avoids the telemetry cues most closely associated with typical injection techniques.

While effective, this technique has limitations. Since the bytes are transmitted through a console input path, payloads must avoid characters that the Windows console subsystem interprets specially:

• 0x0D- carriage return
• 0x0A-line feed
• 0x1A-substitute character, historically linked with Ctrl+Z and end-of-file behavior

If any of these bytes appear in the data stream, the console program may misinterpret the data as a command or terminate input processing, potentially corrupting the intended payload placement.

The researchers noted that this approach circumvents some limitations of related process-parameter poisoning techniques, which require the target process to be created in a suspended state or to have unusual command-line or environment values.

SensePost researchers Max Hirschberger and Ogulcan Ugur previously explored Process Parameter Poisoning, which similarly uses Windows-managed process data for code transfer rather than relying on standard remote memory writes.

Detection and Mitigation

Defenders should consider this a behavioral detection issue rather than a signature problem. Solely blocking or alerting on WriteProcessMemory and VirtualAllocEx will leave gaps in coverage for methods that utilize Windows interprocess communication (IPC) or process initialization data as alternate payload delivery channels.

Key detection opportunities include:

• An unusual parent process launching interactive console utilities with redirected standard handles.
• Binary-like or unusually large writes to a console program’s standard input pipe.
• Memory scanning activities targeting a newly created console child process.
• Changes made through VirtualProtectEx to make memory in a remote process executable.
• Thread suspension and context modifications, such as SetThreadContext, followed by subsequent thread resumption.
• Correlating named-pipe creation and connection telemetry, including Sysmon Event IDs 17 and 18 where applicable.

The critical defensive takeaway is that an executable memory transition within a remote process, followed by instruction-pointer redirection, remains suspicious, even when the payload is delivered through a named pipe instead of via WriteProcessMemory.

Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup in your SOC