The payload did not enter nslookup.exe through WriteProcessMemory. It arrived through standard input, the same logical route used when a person types into an interactive console program. Once the child process had consumed those bytes into its own memory, the injector found them, changed the page permissions and redirected a thread to execute them.

In the published demonstration, that payload was 368 bytes. The number is not a Windows limit or a magic detection threshold. What matters is the route: the console-pipe proof of concept by Two Seven One Three removes VirtualAllocEx and WriteProcessMemory from a familiar process-injection sequence.

That does not make the technique invisible. It makes a narrow detection model incomplete.

Classic Windows injection often follows a recognisable chain. An injector opens or creates a target process, reserves memory in it with VirtualAllocEx, copies a payload with WriteProcessMemory and transfers execution to the new region. Products can treat that combination as a high-value signal because few ordinary applications need to allocate, write and execute memory in another process.

The new proof of concept starts interactive console programs such as nslookup.exe or netsh.exe with redirected standard input. The parent writes the payload to the pipe with WriteFile. The important nuance is that WriteFile does not magically write into an arbitrary remote address. The child consumes its standard input, causing those bytes to be held in memory that already belongs to the child.

The injector then searches the target's memory for a distinctive marker placed before the payload.…