A newly described Windows process-injection technique demonstrates how attackers can route payload data around two of the signals endpoint tools commonly watch: VirtualAllocEx and WriteProcessMemory. The proof of concept uses a redirected console input pipe to place bytes inside another process, then repurposes that existing memory for execution.

The researcher, who publishes as Two Seven One Three, calls the method console named-pipe injection. It does not make process injection invisible, and it has practical restrictions. Its importance is that it breaks a familiar detection assumption: code does not always arrive through an obvious cross-process memory-write call.

Payload data arrives as console input

Traditional injection often follows a recognizable sequence. A program obtains access to a target, allocates memory in it, copies a payload into that allocation and creates or redirects a thread. Security products can correlate the allocation, write and execution events. MITRE ATT&CK groups this broad family of behavior under technique T1055.

The new variation creates a console child process, with examples such as nslookup.exe or netsh.exe, and redirects the child’s standard input to a pipe. Windows allows the parent to give the child the pipe’s read handle while retaining the writing end. When the parent sends data with WriteFile, the console application receives it through an ordinary interprocess-communication path and Windows places the bytes into the child’s address space.

A marker is added before the payload so the injector can search accessible memory and find the relevant buffer. Once located, the code calculates the payload’s entry point, changes the page protection with VirtualProtectEx, suspends a thread, changes its instruction pointer and resumes it. The public demonstration found a 368-byte sequence in an nslookup process before redirecting execution.

A bypass of two APIs is not an absence of telemetry

A product that treats WriteProcessMemory or VirtualAllocEx as mandatory evidence could miss the data-delivery stage. However, later actions remain unusual. The injector searches remote memory, changes committed pages from writable to executable, manipulates a thread’s context and resumes execution at a new address. VirtualProtectEx also requires process access that defenders can observe or restrict.

The initial setup provides context too. An unexpected parent launches an interactive console utility with inherited and redirected handles, then supplies input that resembles binary content rather than a human command. Any one event may be legitimate, but the combination is rare in most business environments.

The technique also has payload constraints because console processing may interpret carriage returns, line feeds or the Ctrl+Z substitute character as control input. Those limitations could force an adversary to encode, reshape or stage payloads, potentially creating further detection opportunities.

Detection should correlate the full behavior chain

Defenders should avoid blocking every use of nslookup, netsh, conhost or pipes. These are normal Windows components and broad rules would create noise. A stronger strategy is to baseline expected console automation and alert on uncommon combinations:

• A nonstandard parent creates a console program with redirected standard handles.
• The parent writes binary-like data through the child’s input channel.
• One process scans memory belonging to the console child.
• Remote memory protections change to executable, particularly executable and writable.
• A thread is suspended, its context changes and it resumes at an address outside the expected image.

Sysmon events 17 and 18 can help investigate named-pipe activity, although anonymous pipes used for standard input may require endpoint telemetry that records handles and process relationships. Memory-protection and thread-context events therefore remain especially valuable.

Engineering detections around intent, not one implementation

The research is a useful test case for endpoint detection design. An alert tied only to one popular API is easy to reason about, but attackers can achieve the same result through different Windows mechanisms. Durable analytics describe the outcome: an unusual process receives attacker-controlled bytes, memory becomes executable, and control flow is redirected.

Security teams can use the proof of concept to validate whether their tools capture redirected handles, cross-process protection changes and thread manipulation. They should also test correlation windows carefully, because the events may be separated in time. The goal is not to declare the method undetectable; it is to ensure visibility survives when one familiar link in the allocate-write-execute pattern disappears.

Source: Cyber Security News.