New Windows Process Injection Attack Evades EDR Monitoring Without WriteProcessMemory

A Windows process injection method disclosed by security researcher Two Seven One Three sidesteps two APIs closely associated with remote code injection: VirtualAllocEx and WriteProcessMemory.

Dubbed console named-pipe injection, the technique delivers payload bytes through a child console process’s redirected standard input and repurposes memory Windows has already populated. It can disrupt detections built around the familiar allocate-write-execute sequence.

Process injection executes arbitrary code inside another process, potentially masking activity behind a legitimate application.

MITRE ATT&CK tracks the behavior as T1055, while conventional implementations commonly open or create a target, allocate remote memory, copy code with WriteProcessMemory, and start or hijack a thread. EDRs frequently correlate this chain’s memory and thread signals.

Windows Process Injection Evades EDR

The variation exploits Windows interprocess communication rather than a direct cross-process write. An injector creates an interactive console child, such as nslookup.exe or netsh.exe, redirects its standard input to a pipe, and sends the payload with WriteFile.

Microsoft documents that a parent can assign a pipe’s read end as a child’s standard-input handle and retain the opposite end for writing.

The bytes then exist in the console program’s address space as it processes input. The proof of concept prefixes the payload with a distinctive marker, searches accessible memory for that signature, and calculates the shellcode entry point beyond the marker.

The code image shows inheritable handles configured in STARTUPINFO, followed by CreateProcess with redirected streams.

After locating the buffer, the injector calls VirtualProtectEx to make the existing committed pages executable. It then suspends a thread, changes its instruction pointer, and resumes execution.

Microsoft says VirtualProtectEx changes protections in another process and requires PROCESS_VM_OPERATION; it recommends suspending a thread before changing its context.

Demonstration from security researcher Two Seven One Three output shows 368 bytes found inside an nslookup.exe region; its protection changed from read-write to executable-read-write, and the main thread was redirected to that address.

Payloads must avoid carriage return, line feed, and Ctrl+Z substitute bytes because console parsing may treat them as command terminators or end-of-file input. Memory discovery, remote protection changes, and thread-context manipulation also remain detectable.

Unlike related process-parameter poisoning research, this approach does not require launching the child suspended or placing unusually formatted data in command-line or environment fields.

SensePost researchers Max Hirschberger and Ogulcan Ugur said their separate technique bypassed four leading EDR products, but that does not validate this newer implementation.

Defenders should move beyond single-API alerts and correlate the complete behavior. High-value signals include an unusual parent launching an interactive console binary with redirected handles, binary-like standard-input writes, memory scanning, a remote VirtualProtectEx transition to executable permissions, and SetThreadContext followed by resumption.

Sysmon Event IDs 17 and 18 provide named-pipe telemetry, although anonymous standard-input pipes may require richer endpoint and handle-level visibility.

Security teams should baseline console automation and hunt for rare combinations rather than flagging every conhost.exe, nslookup.exe, or pipe operation.

Research shows an important lesson for engineering tools that detect harmful process injections. Reliable detection requires looking at how processes are created, how handles are shared, how memory is protected, and how control flows change. It shouldn’t rely on a single method.

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