Windows Injection Can Bypass a Narrow Call Check
On 26 September 2026, Two Seven One Three described Windows programs nslookup.exe or netsh.exe receiving marked payload bytes through redirected standard input. WriteFile supplies bytes; the child stores them. The injector finds and skips the marker, makes those pages executable and redirects a thread, avoiding VirtualAllocEx and WriteProcessMemory. Input cannot select an arbitrary remote write address.
The research shows 368 bytes in nslookup.exe, excluding carriage return, line feed and the historical end-of-file marker 0x1A. That size sets no ceiling or alert threshold. Suspension order and original comparisons are unspecified. Missing results do not prove absent tests; no active campaign is established.
Separate the evidence from the verdict
Process Parameter Poisoning, related 2026 research by SensePost’s Max Hirschberger and Ogulcan Ugur, used startup parameters instead. Its reported success without alerts from four tested endpoint detection and response (EDR) products belongs to that method. The familiar comparison is access, allocation, copying and execution in another process. A result for a different implementation cannot establish this one’s performance.
A rule requiring that call pair cannot match this chain. That does not establish whether a product has other memory, handle, thread or behavioural evidence. Ask which condition failed before extrapolating to an entire endpoint estate.
What the documented calls establish
Microsoft’s VirtualProtectEx documentation concerns protection on committed pages in a specified process. The process handle needs the relevant access right. Changing protection is distinct from allocating storage or supplying its contents. For investigation, record who requested the change, its range and the earlier permissions.
SetThreadContext sets register context. Microsoft warns that changing a running thread has unpredictable results and says to suspend it first. Keep this documented requirement separate from the research evidence above.
MITRE ATT&CK describes T1055 as execution inside a different live process and lists T1055.003, Thread Execution Hijacking. These classifications describe behaviour rather than certify a product verdict. A trusted program name does not establish the origin or purpose of everything executing within it.
Build a joined investigation
Treat each requirement below as a collection question, using approved baselines and actual sensor evidence. These are proposed checks, not results from BlackTree testing.
- Explain the parent. Identify the launcher and check inherited or redirected handles against approved management scripts. Establish legitimate relationships before treating rarity as malice.
- Characterise the input. Compare its form and purpose with normal automation. A binary-looking transfer needs context; an unusual byte sequence alone does not establish malicious execution.
- Correlate inspection. Determine whether available records connect another process’s broad reads to the child. Preserve the relationship and timing rather than relying on an isolated access event.
- Follow permissions. Join the change documented above to the relevant process and memory range. Pipe activity cannot establish an executable destination.
- Reconstruct the thread. Where collection supports it, correlate suspension, context change and resumption with the destination. Distinguish observed events from a sequence assumed because an API permits it.
- Examine the destination. Distinguish a private or heap-backed region that was writable from a normal executable section of a loaded image. Verify what the sensor actually exposes.
Prove the collection before deploying an alert
Sysmon documents Event IDs 17 and 18 for named-pipe creation and connection. Its filters determine which matching events are retained, and process-access collection can be noisy around diagnostic utilities. Record the deployed configuration and exclusions before interpreting a missing event. A documented event category does not guarantee the complete evidence needed here.
Microsoft’s anonymous-pipe guidance explains inherited handles and an internal uniquely named pipe. That implementation detail does not prove that a particular sensor reconstructs the standard-input relationship. Test the installed operating-system and sensor combination rather than assuming named-pipe logging covers it.
Neither conhost.exe nor a legitimate utility name is a sufficient alert condition. Debugging and management activity also changes process state. A high-volume name-based rule can obscure the joined evidence it was meant to expose.
Actions for the response team
- Ask the vendor specific questions. Establish whether the capabilities in the six investigation checks above are available when the familiar call pair is absent. Record each collection or analytic gap explicitly.
- Validate safely. Use an isolated laboratory, harmless test material and agreed success criteria. Compare expected collection, observed evidence and actual alerts separately. BlackTree has not independently tested this demonstration.
- Hunt relationships. Use the six checks above to investigate combinations. Keep approved scripts and diagnostic tools in the baseline; utility names alone are weak evidence.
- Limit the runway. Retain application control, least privilege, credential isolation and restrictions on untrusted binaries. This requires an existing execution foothold, not an initial-access flaw.
- Retain the history. Agree how long process, handle, thread and protection evidence stays available. Brief transitions are difficult to reconstruct if relevant collection expires before triage.
BlackTree’s earlier cleanup-driver analysis also examined a trusted component reached through an unexpected control path. It supplies context, not a shared exploit or test result.
Can the available evidence reconstruct the entire reported chain and distinguish it from authorised work? Record observed coverage and missing data separately. A diagram of an opportunity is not proof that the deployed system records it.
