Security · 28 Sep 2026 · Rob Nidschelm

368 Bytes Entered nslookup.exe Through Its Keyboard. Then They Became Executable.

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.

The payload travelled as input before it became code

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. Once it finds the marker, it calculates the shellcode entry point. VirtualProtectEx changes the existing committed pages from writable memory to executable memory. The proof of concept suspends a thread, changes its instruction pointer and resumes it at the staged payload.

Microsoft documents that SetThreadContext changes a thread’s processor context and warns that a running thread should normally be suspended first. In an injection chain, changing the instruction pointer is the moment a data-staging trick becomes an execution technique.

The 368-byte claim needs careful reading

The demonstration located 368 payload bytes inside nslookup.exe. That is useful evidence that binary data can survive this path, but it does not mean every 368-byte standard-input write is malicious or that larger payloads cannot work. The payload must avoid console-significant bytes including carriage return, line feed and the historical end-of-file character 0x1A. Those constraints shape the shellcode, not the general detection strategy.

The research is also a proof of concept, not evidence of an active criminal campaign. Its author explicitly says no fresh EDR comparison was performed. A related 2026 technique from SensePost, Process Parameter Poisoning, used process-startup parameters rather than console input and reportedly completed injection without alerts from four tested EDR products. That result explains why defenders should take the design problem seriously, but it must not be presented as a test result for this separate console-pipe implementation.

The blind spot is the rule, not the endpoint

An alert that requires VirtualAllocEx plus WriteProcessMemory will miss a chain that deliberately uses neither. That is a blind spot in the analytic. It is not proof that an EDR lacks lower-level memory, handle, thread or behavioural telemetry capable of identifying the remaining actions.

The technique still needs a process handle with meaningful rights. It reads or scans another process’s memory, changes remote page permissions, manipulates a thread context and transfers execution into memory that was recently writable. Those are not ordinary consequences of asking nslookup.exe to resolve a hostname.

MITRE ATT&CK classifies process injection as T1055 and notes that injection can hide execution inside a legitimate process. For this proof of concept, thread execution hijacking under T1055.003 is the especially relevant sub-technique. The implementation changes, but the attacker’s objective and several observable transitions remain.

Build the detection around an improbable sequence

No single event below is enough. Console programs receive input, debuggers change thread contexts and legitimate software changes memory protection. The useful signal is the sequence occurring across the same parent, child and target relationship within a short period.

• Start with the parent-child relationship. Look for an unusual parent creating nslookup.exe, netsh.exe or another interactive console binary with inherited or redirected standard handles.
• Characterise the input. A binary-looking write to standard input without a plausible interactive or automation purpose deserves context. Baseline approved management scripts before treating rarity as malice.
• Correlate remote memory inspection. The injector must find the marker and calculate the payload address. Telemetry showing one process reading broad regions of the child strengthens the case.
• Prioritise remote permission changes. A VirtualProtectEx transition that makes writable memory executable inside the console child is more useful than a pipe event by itself.
• Join thread manipulation to the page transition. SetThreadContext, especially after suspension and immediately before resumption, should be correlated with the new executable region.
• Inspect the destination address. An instruction pointer entering a private or heap-backed page that was recently writable is materially different from returning to a loaded image’s normal executable section.

Sysmon can help, but test what it actually records

Sysmon Event IDs 17 and 18 record named-pipe creation and connection. Microsoft also explains that Windows implements anonymous pipes using a uniquely named pipe internally. That does not guarantee that every endpoint configuration will expose enough detail to reconstruct redirected standard input. Collection rules, filtering, EDR sensors and operating-system versions need laboratory validation.

Do not deploy a rule that treats every conhost.exe, nslookup.exe or pipe event as hostile. The resulting noise will bury the useful relationship. Build and test a joined analytic that follows process creation, handle inheritance, pipe activity, cross-process memory access, an executable permission change and thread redirection.

What defenders should do now

• Ask the EDR vendor what survives without the classic pair. Validate whether protection changes, remote reads, thread-context changes and destination memory types are available to detection logic.
• Run a controlled detection exercise. Reproduce the behaviour only in an isolated laboratory, using a harmless payload and pre-agreed success criteria. The objective is telemetry validation, not proving that a product can be surprised.
• Hunt combinations, not utility names. nslookup.exe and netsh.exe are legitimate tools. Alert on the improbable chain around them.
• Reduce the post-compromise runway. Application control, least privilege, credential isolation and restrictions on untrusted binaries still matter because this is a post-execution technique, not an initial-access vulnerability.
• Retain enough endpoint history. A memory transition can be brief. Investigation depends on preserving process, handle, thread and protection-change telemetry long enough to reconstruct the sequence.

BlackTree’s earlier analysis of Microsoft Defender’s cleanup driver being turned against Defender carried a related lesson: trusted components do not become harmless when an attacker reaches them through an unexpected control path. Here, the legitimate console input path becomes a staging mechanism because a detection strategy assigned too much meaning to two missing API calls.

The enduring defensive question is not whether an attacker called the API in yesterday’s diagram. It is whether one process caused another process to hold attacker-controlled bytes, made those bytes executable and redirected execution into them. That behaviour remains visible if the detection system is looking for the outcome rather than the ritual.

Sources

• Two Seven One Three, EDR Evasion: Process Injection Without WriteProcessMemory, published 26 September 2026 in the source page’s local timezone. Primary research and proof of concept.
• SensePost, Process Parameter Poisoning, related 2026 research by Max Hirschberger and Ogulcan Ugur. Its four-product EDR test concerns a different process-parameter technique.
• MITRE ATT&CK T1055, Process Injection, technique and detection context.
• Microsoft Sysmon documentation, including Event IDs 17 and 18 for named pipes.
• Microsoft anonymous-pipe operations documentation, VirtualProtectEx documentation and SetThreadContext documentation.