Windows

A researcher who goes by Two Seven One Three published a Windows process injection technique and a working proof of concept on September 26, 2026, through the Zero Salarium blog. It places shellcode into another process and runs it without ever calling WriteProcessMemory, VirtualAllocEx or CreateRemoteThread, the three Windows functions that most endpoint detection and response (EDR) products treat as the fingerprint of code injection. There is no CVE and no software bug to patch. This is a method an attacker uses once they already have the ability to run code on a Windows host.

The reason it matters is that a lot of injection detection is built on that classic API chain. By routing the payload through a console program's standard input instead, the technique avoids every call in that chain, so a defence that only pattern-matches those functions can miss it. No use in real attacks has been reported yet, but the proof of concept is public on GitHub, which turns it into a detection gap to close rather than an emergency to patch tonight.

How it works

The textbook way to inject code into another process is a four-call sequence: OpenProcess to get a handle, VirtualAllocEx to carve out memory in the target, WriteProcessMemory to copy the shellcode into it, and CreateRemoteThread to run it. EDR vendors hook those functions in user mode or watch for them through kernel callbacks, because together they are a strong signal that one process is writing executable code into another.

This technique reaches the same end state without any of them. The injector calls CreateProcess to launch an interactive console program, with nslookup.exe and netsh.exe given as the examples, and redirects that child's standard input to a named pipe whose write end the injector keeps. A console program expects to read commands from stdin, so Windows copies whatever arrives on that handle into the child's own memory. The injector then calls WriteFile to push the payload bytes down the pipe. The shellcode lands inside the target process as ordinary input data, and no WriteProcessMemory call ever happens.

Two steps remain. The input buffer is not executable, so the injector calls VirtualProtectEx on the child to change the protection of that memory region and add execute permission. VirtualProtectEx is a legitimate function that programs use on their own memory constantly, and it draws far less scrutiny than WriteProcessMemory. Finally the injector finds the payload inside the child by searching for distinctive marker bytes written at its start, works out the exact address from that offset, and hijacks a thread in the console process so its instruction pointer (RIP, the register that holds the address of the next instruction) points at the shellcode. In the published proof of concept the custom shellcode sits at offset 0x19 in the data array, which is where you would place your own.

The result is code running inside a signed, expected Windows binary, reached by functions that on their own look harmless: spawning a console tool, writing to a pipe, changing a memory protection flag, and setting a thread's context. None of the heavily watched injection calls appear.

Where this stands

The work is credited to Two Seven One Three, with a demonstration repository named InjectSetConsole that a second account has since forked, and the accompanying write-up is the Zero Salarium post. It is research and a proof of concept, not an observed campaign. No security vendor has tied it to a named group or reported it in an active intrusion as of this writing.

Two details make it worth acting on before that changes. The console programs it abuses, nslookup.exe and netsh.exe, are signed Windows binaries that already appear in attacker playbooks as living-off-the-land tools, so their presence does not itself raise an alarm. And because the method and the code are now public, the effort to copy it is small, which is usually what moves a technique from a blog post into tooling.

What to detect and harden

With no patch to apply, the work is detection and reducing what an attacker can do once inside. The technique needs code execution on the host first, so every control that keeps that foothold from happening still carries its weight.

• Alert on VirtualProtectEx called against a different process rather than the caller's own. Changing another process's memory to executable is rare in normal software and is the one step here that is hard to avoid.
• Watch for a console binary such as nslookup.exe or netsh.exe that is started with its standard input redirected to a pipe, especially when the parent process is not a shell or an administrative tool that would plausibly drive it that way.
• Treat thread context changes, in particular SetThreadContext against a freshly spawned process, as a signal worth correlating rather than ignoring.
• Correlate the sequence instead of trusting one event. A signed console tool spawned by an unusual parent, followed by pipe writes into it, a memory region turning executable, and a thread being redirected, is suspicious as a chain even though each step is individually benign.
• Where application control is already in place, review which processes are allowed to launch netsh.exe and nslookup.exe. You cannot block those binaries outright without breaking administration, but narrowing who can invoke them removes easy cover.

If your EDR relies on user-mode hooks of WriteProcessMemory and CreateRemoteThread, confirm what else it inspects. Many products also collect kernel telemetry on remote memory protection changes and thread manipulation through Microsoft's Threat Intelligence callbacks, and that is the telemetry that catches this. A product that only watches the classic API pair has a blind spot here.

The wider lesson

Injection detection anchored to a single hooked function is brittle, because there are many ways to get bytes into another process and only a handful of them run through the obvious API. The durable answer is behavioural: correlate process creation, interprocess communication, memory protection changes and thread context across a short window, and score the combination. That is more work than matching one call, and it is what separates an EDR that catches a new variant from one that waits for a signature update.

Our security operations work tunes EDR and SIEM detections for exactly this kind of multi-step behaviour, and our red team and code review engagements test whether your defences see techniques like this one before an attacker proves they do not. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would do the work.

---

Sources: Zero Salarium, Dark Reading, Cyber Security News, GBHackers, InjectSetConsole proof of concept.