New Windows Injection Method Can Slip Past EDR Tools
A newly disclosed Windows process injection technique sidesteps the two system functions that endpoint security tools most commonly watch for, according to research published September 27, 2026 by a security researcher operating as Two Seven One Three.
Key facts
What happened: A Windows process injection method was publicly disclosed that avoids the
VirtualAllocExandWriteProcessMemoryAPI calls associated with classic code injectionWhy it matters: Many endpoint detection and response tools alert on that specific sequence of calls
What it's called: Console named-pipe injection
The risk: Detection rules built around a single API call may miss it entirely
What to do: Correlate multiple behavioral signals rather than alerting on individual API calls
What is process injection?
Process injection is running your own code inside another program's process, so the activity appears to come from a legitimate application instead of from malware. MITRE ATT&CK, the industry's standard catalog of attacker techniques, tracks the behavior as T1055.
Conventional implementations follow a recognizable sequence: open the target process, allocate memory inside it, copy code into that memory, then start or hijack a thread to run it. Endpoint detection and response tools — EDR, the software that monitors laptops and servers for attacker behavior — frequently detect exactly that allocate-write-execute chain.
Why can this technique evade detection?
Because it never performs the write that detection rules look for. Rather than writing into another process's memory directly, the technique uses ordinary Windows interprocess communication to get its payload into a child process's memory, then repurposes memory that Windows has already populated.
The result is that the sequence EDR products key on doesn't occur, even though the outcome is the same. Detections built narrowly around those two API calls can be disrupted.
The method is not invisible. Memory scanning, remote memory permission changes and thread manipulation all remain detectable, and the technique has constraints that limit what payloads work with it.
How should security teams detect it?
By correlating the full behavior instead of alerting on one function call. The research points to several signals worth combining:
An unusual parent process launching an interactive console binary with redirected input and output handles
Binary-looking data written to a process's standard input
Memory scanning activity
A remote change of memory permissions to executable
Thread context modification followed by resumption
Sysmon, Microsoft's free system monitoring tool, provides named-pipe telemetry through event IDs 17 and 18, though the research notes that anonymous standard-input pipes may require deeper endpoint and handle-level visibility.
The practical advice for defenders: baseline what normal console automation looks like in your environment and hunt for rare combinations, rather than flagging every instance of common Windows processes.
What non-technical readers should take from this
Nothing here requires action from an individual. This is research disclosure, not an active attack campaign, and there's no patch to apply — the technique abuses features working as designed.
The takeaway for anyone buying security software: a tool that detects "the known bad thing" will eventually be routed around. Ask vendors how their detection holds up when an attacker avoids the obvious signal. Reliable detection has to look at how processes are created, how handles are shared, how memory permissions change and how control flow shifts — not any single indicator.
Source: Cyber Security News, reporting on research disclosed by Two Seven One Three.