A newly published Windows proof of concept shows how an attacker can place harmful code inside a legitimate process while avoiding several warning signs that endpoint security tools commonly watch.
The method, called Process Parameter Poisoning, uses information normally supplied when Windows starts a program rather than writing a payload directly into another process.
The research is not tied to an active malware family or confirmed campaign. Still, it matters because process injection is widely used by malware to blend into trusted programs and hide activity.
The technique could be adapted by attackers who already have a way to run code on a Windows machine.
Analysts behind the GitHub project noted that the loader bypassed detection mechanisms in tests against four leading endpoint detection and response, or EDR, products.
The findings point to a blind spot when defenses focus mainly on familiar memory-writing and process-creation behaviors.
Orange Cyberdefense said in a report shared with Cyber Security News (CSN) that the approach stages shellcode in a new process’s startup data, then changes its main thread so it begins running that code.
The public project, P-Shellcode Loader, is presented as security research rather than a weaponized tool.
New Windows Process Injection Technique
Traditional process injection usually follows a recognizable path. A program opens or launches a target, reserves memory inside it, writes code there, marks the memory executable, and starts or redirects a thread.
Security products often flag calls associated with those steps, including VirtualAllocEx, WriteProcessMemory, and CreateRemoteThread.
The new method takes a different route. When Windows creates a process through CreateProcessW, it copies command-line data, environment variables, and startup settings into internal structures called the Process Environment Block, or PEB.
The loader places its payload in one of these copied values, a move the researchers call poisoning a process parameter.
It can use the command line, an environment block, or the lpReserved startup field, which Windows maps to ShellInfo.
After the program starts, the loader reads the target process’s PEB and finds the stored data with memory-read functions. It avoids the usual remote-memory allocation and writing calls that many EDR detections prioritize.
The technique then changes the stored memory permissions so the payload can run. Instead of creating a remote thread, it alters the instruction pointer of the new process’s main thread using NtSetContextThread.
This directs normal program execution to the injected code and avoids several routine indicators linked to classic injection.
Tests also found that the loader does not need to create the target in a suspended state or suspend its thread later. Those actions are often associated with process hollowing and similar tricks.
The smaller number of conspicuous operations can reduce the trail available to behavior-based defenses, though it does not make the activity invisible.
Detection Needs Broader Context
The research shows why defenders should not rely only on alerts for memory allocation, remote writes, or remote-thread creation.
Monitoring should also examine unusual CreateProcessW inputs, especially unexpectedly long command lines, abnormal environment data, and unusual values supplied through STARTUPINFO structures.
.webp)
Correlating process creation with rapid thread-context changes can reveal the broader sequence.
Security teams can look for a process whose startup parameters contain data that does not fit its expected role, followed by NtQueryInformationProcess and reads of the PEB.
A later protection change from readable and writable memory to readable and executable memory, combined with NtSetContextThread, deserves scrutiny.
These events may be legitimate alone, but their timing and combination are significant.
The proof of concept has limits. Process parameters are null-terminated strings, so raw shellcode containing zero bytes cannot be copied intact by the simple method.
The researchers address this by generating code without null bytes and using a staged routine that rebuilds arbitrary payloads later, including DLL loading or content retrieved from an HTTPS location.
For defenders, the practical response is to validate detections against this pattern, extend telemetry around process startup data and thread-context manipulation, and investigate anomalous parent-child process relationships.
Application allowlisting, least-privilege controls, and prompt patching will not eliminate this technique, but they can reduce the chance that an attacker gains the code execution needed to use it.
Prevent critical incidents and financial loss with stronger proactive defense. Integrate a live threat feed from 15K SOC Teams.
