New Windows Process Injection Attack Evades EDR Without WriteProcessMemory

Key Takeaways

• A novel Windows process injection technique bypasses common EDR detections by avoiding typical API calls like VirtualAllocEx and WriteProcessMemory.
• The method, dubbed console named-pipe injection, leverages standard input redirection in child console processes to deliver and execute payloads.
• Security researcher Two Seven One Three demonstrated the technique, which injects code into existing memory regions within legitimate console applications like nslookup.exe.
• Detection requires a comprehensive approach, correlating multiple behavioral signals rather than relying on single-API alerts.

A sophisticated new Windows process injection method has emerged, designed to evade endpoint detection and response (EDR) systems by circumventing the application programming interfaces (APIs) traditionally monitored for such attacks. This technique, disclosed by security researcher Two Seven One Three, avoids direct calls to VirtualAllocEx and WriteProcessMemory, which are frequently flagged during remote code injection attempts.

The method, termed “console named-pipe injection,” ingeniously utilizes a child console process’s redirected standard input to deliver malicious payload bytes. Instead of allocating new memory, it repurposes existing memory regions already populated by Windows, effectively disrupting EDR detections built on the conventional allocate-write-execute sequence.

Process injection, categorized by MITRE ATT&CK as T1055, involves executing arbitrary code within another process. This allows attackers to mask malicious activities by making them appear as legitimate operations originating from a trusted application. Traditional implementations typically involve opening or creating a target process, allocating remote memory, copying code using WriteProcessMemory, and then starting or hijacking a thread. EDR solutions commonly correlate these memory and thread manipulation signals to identify suspicious behavior.

Windows Process Injection Evades EDR

This innovative variation exploits Windows interprocess communication mechanisms rather than relying on direct cross-process memory writes. The injector initiates an interactive console child process, such as nslookup.exe or netsh.exe, and redirects its standard input to a pipe. The payload is then transmitted into the child process’s address space via WriteFile.

Microsoft documentation confirms that a parent process can assign the read end of a pipe as a child process’s standard input handle while retaining the write end for itself. This mechanism allows the payload bytes to reside within the console program’s address space as it processes input.

The proof of concept involves prefixing the payload with a unique marker. The injector then scans accessible memory within the target process for this signature to locate the embedded shellcode. Once found, the entry point for the shellcode is calculated beyond the marker.

The provided code image illustrates the configuration of inheritable handles within STARTUPINFO, followed by a CreateProcess call with redirected streams. After successfully locating the payload buffer, the injector invokes VirtualProtectEx to alter the protection of the existing committed memory pages, making them executable. Subsequently, a thread within the target process is suspended, its instruction pointer is modified to point to the shellcode, and execution is resumed.

Microsoft specifies that VirtualProtectEx is used to change memory protections in another process and requires the PROCESS_VM_OPERATION permission. The vendor also advises suspending a thread before modifying its context to ensure stability and control.

Demonstration from security researcher Two Seven One Three shows the successful injection of 368 bytes into an nslookup.exe region. The memory protection was changed from read-write to executable-read-write, and the main thread was redirected to the newly executable address.

A critical consideration for payloads using this technique is to avoid certain bytes, specifically carriage returns, line feeds, and Ctrl+Z substitutes, as console parsing mechanisms might interpret these as command terminators or end-of-file indicators. Furthermore, while the technique bypasses specific API calls, actions such as memory discovery, remote protection changes, and thread-context manipulation still present detectable signals for advanced EDR solutions.

Unlike other related research, such as process-parameter poisoning, this method does not necessitate launching the child process in a suspended state or injecting unusually formatted data into command-line arguments or environment variables.

While SensePost researchers Max Hirschberger and Ogulcan Ugur said their distinct technique successfully bypassed four leading EDR products, it’s important to note that their findings do not directly validate the efficacy of this newer console named-pipe injection method against specific EDR solutions.

What You Should Do

• Correlate Behavioral Signals: Move beyond single-API alerts. Implement EDR rules that correlate multiple suspicious behaviors, such as an unusual parent process launching an interactive console binary with redirected handles, binary-like standard-input writes, memory scanning within a process, remote VirtualProtectEx calls transitioning memory to executable permissions, and SetThreadContext followed by thread resumption.
• Monitor Console Automation: Baseline normal console automation activities within your environment. Hunt for rare or anomalous combinations of conhost.exe, nslookup.exe, netsh.exe, or other console binaries interacting with pipes, rather than flagging every instance.
• Leverage Sysmon Telemetry: Utilize Sysmon Event IDs 17 and 18 for named-pipe telemetry. For anonymous standard-input pipes, ensure your endpoint and handle-level visibility is sufficiently rich to detect their creation and usage.
• Enhance Process Creation Monitoring: Focus on how processes are created, how handles are shared between processes, how memory protections are modified, and how control flow changes within processes. Robust detection requires a holistic view of these interactions.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.