New Windows Process Injection Technique Evades Four Leading EDR Products

Security researchers have disclosed a Windows process injection technique that hides shellcode inside a new process’s startup parameters and avoids several behaviors commonly monitored by endpoint detection and response tools.

The method, called Process Parameter Poisoning, reportedly bypassed detection during tests against four leading EDR products. However, the researchers did not identify the vendors, and the results apply only to the tested configurations.

The public P-Shellcode Loader proof of concept is security research rather than evidence of an active attack campaign. An attacker would already need the ability to execute code on a Windows device before using the technique.

Process Parameter Poisoning avoids common injection steps

Traditional process injection often requires one process to allocate memory inside another process, write a payload into that memory and create or redirect a thread to execute it.

Security products commonly monitor APIs such as VirtualAllocEx, WriteProcessMemory and CreateRemoteThread because malware frequently uses them during process injection.

Process Parameter Poisoning follows a different path. It places shellcode inside data that Windows copies into a process during creation, reducing the need for a separate remote memory write.

Traditional injection behavior	Process Parameter Poisoning approach
Allocates a new remote memory region	Uses memory already created for process parameters
Writes a payload with WriteProcessMemory	Supplies the payload during process creation
Creates a remote thread	Redirects the new process’s main thread
May create the target suspended	Can operate without a suspended-process flag
Generates familiar injection telemetry	Produces a less common combination of events

Windows copies startup data into the new process

When an application calls CreateProcessW, Windows creates a process and copies information such as its command line, environment variables and startup settings into the target process.

Microsoft’s CreateProcessW documentation explains that the caller can supply command-line text, an environment block and a STARTUPINFO structure when launching a program.

The kernel and Windows runtime store this information in internal structures connected to the Process Environment Block, commonly called the PEB.

• The command-line buffer can carry encoded shellcode.
• The environment block can contain attacker-controlled data.
• The lpReserved field can place data in startup-related structures.
• Windows copies these values into the new process automatically.

The loader abuses this normal behavior by placing its payload inside one of the copied values. The researchers describe this step as poisoning a process parameter.

The loader locates the payload through the PEB

After creating the target process, the loader needs to find where Windows placed the startup data in the target’s address space.

It calls NtQueryInformationProcess to obtain information about the target process, including the location of its PEB. It can then read the relevant structures and locate the command line, environment data or reserved startup value containing the payload.

Microsoft documents NtQueryInformationProcess as an internal API that can return process details, including basic information used to find the PEB.

1. Create a legitimate Windows process with attacker-controlled startup data.
2. Query the new process to locate its PEB.
3. Read process parameters from the target’s address space.
4. Find the buffer containing the staged shellcode.
5. Prepare that existing memory for execution.

The loader may use memory-reading functions to inspect the target, but it avoids the classic operation of copying shellcode into a newly allocated remote buffer.

The technique changes existing memory permissions

Startup parameters normally reside in readable and writable memory because Windows and the application may need to access or modify them.

Processor protections usually prevent code from running directly from writable data pages. The loader therefore changes the permissions on the memory containing the poisoned parameter so that the payload can execute.

The operation may use VirtualProtectEx or a lower-level equivalent to change the protection of memory inside another process.

Memory stage	Typical protection	Purpose
Process creation	Read and write	Stores command-line or environment information
Payload preparation	Read and execute	Allows the processor to run the staged instructions
Thread redirection	Executable payload address	Transfers execution to the poisoned parameter

A remote protection change remains a useful detection signal. However, defenders may miss it when rules expect it to follow remote allocation and memory-writing events.

NtSetContextThread redirects the main thread

The loader does not need to create a new remote thread. Instead, it modifies the execution context of the target process’s existing main thread.

The technique changes the thread’s instruction pointer so that execution begins at the shellcode stored in the process parameters.

Microsoft’s NtSetContextThread documentation states that the function changes context information for a specified thread.

• The loader obtains a handle to the target’s main thread.
• It reads or prepares the thread context.
• It replaces the instruction pointer with the payload address.
• The target thread begins executing the staged shellcode.

This avoids CreateRemoteThread, one of the strongest and most familiar indicators associated with classic process injection.

The target does not need to start suspended

Many process hollowing techniques create a target with the CREATE_SUSPENDED flag. The attacker modifies the process before resuming its main thread.

The researchers reported that Process Parameter Poisoning can work without creating the target in a suspended state. It also does not need to call SuspendThread later.

Avoiding those actions can reduce the number of suspicious events available to EDR products. Security tools often correlate suspended process creation with memory modification and thread resumption.

Common process hollowing signal	Required by the new technique?
CREATE_SUSPENDED	No
SuspendThread	No
VirtualAllocEx	No separate allocation required
WriteProcessMemory for the payload	No
CreateRemoteThread	No
Thread-context modification	Yes
Remote memory-protection change	Usually required

The EDR bypass claim has important limits

The researchers said their loader avoided detection mechanisms in four leading EDR products. The public findings did not name the products or disclose every configuration used during testing.

EDR detection depends on product versions, enabled modules, cloud analytics, local policies and custom detection rules. A technique that succeeds in one test may trigger alerts in another environment.

The proof of concept also does not make injection invisible. It still creates a process, accesses another process’s memory, changes memory permissions and manipulates a thread context.

• The attacker must already execute code on the endpoint.
• The target EDR configuration affects the outcome.
• Memory-protection changes may remain visible.
• Thread-context manipulation can generate telemetry.
• Unusual process parameters may reveal the staged payload.

The tests identify a potential detection gap rather than a universal method for disabling or defeating endpoint security.

Null bytes limit payloads stored in process parameters

Windows process parameters often use null-terminated strings. A zero byte marks the end of a string and can truncate raw shellcode before Windows copies the complete payload.

The simple form of the technique therefore requires null-free shellcode. The payload must avoid instructions or data containing zero bytes.

The researchers addressed this limit with staged payloads. A small null-free loader can reconstruct or retrieve a more complex second-stage payload after execution begins.

Payload method	Purpose
Null-free shellcode	Fits inside a null-terminated process parameter
Decoder stub	Reconstructs bytes that could not appear in the original string
DLL loader	Loads a more capable payload after initial execution
HTTPS downloader	Retrieves a later stage from a remote server

This staging approach increases complexity and creates more detection opportunities, including network connections, additional memory operations and module-loading activity.

Defenders should inspect unusual startup parameters

Security teams should expand detection beyond VirtualAllocEx, WriteProcessMemory and CreateRemoteThread. Those APIs remain valuable, but they cover only part of the process injection landscape.

Defenders can inspect unusually long command lines, oversized environment blocks and unexpected data in STARTUPINFO fields. Binary-like or encoded content inside these parameters deserves additional scrutiny.

The CreateProcessW reference shows the range of caller-controlled information supplied during process creation. Telemetry that records only the image path may miss important details.

• Long command lines with no clear connection to the target application
• Environment variables containing encoded or high-entropy data
• Unexpected use of reserved STARTUPINFO fields
• Startup values that resemble executable machine code
• Unusual parent and child process combinations

Organizations should establish normal parameter sizes and formats for important applications. An application that normally starts with a short command line should not suddenly receive several kilobytes of opaque data.

Process creation should be correlated with PEB access

Individual Windows API calls often have legitimate uses. Detection improves when defenders correlate several events occurring in a short time.

A newly created process followed by NtQueryInformationProcess, remote memory reads, a protection change and NtSetContextThread creates a stronger signal than any action alone.

Monitoring NtQueryInformationProcess activity can help identify a process that immediately locates another process’s PEB after launching it.

1. Record the parent process and newly created child.
2. Capture command-line, environment and startup parameter telemetry.
3. Detect queries for the child process’s PEB.
4. Identify reads from the child’s process-parameter memory.
5. Alert on a rapid change from writable to executable memory.
6. Detect a thread-context update targeting the same memory region.

The short timing between these actions can separate suspicious injection from debugging tools and other legitimate software.

Writable-to-executable transitions remain valuable signals

Even without remote allocation or payload writing, the technique usually needs to make the parameter memory executable.

Security tools should alert when one process changes another process’s data page from readable and writable to readable and executable. The risk increases when that page belongs to command-line or environment storage.

The VirtualProtectEx reference confirms that the function changes protections on committed pages in another process’s address space.

• Track which process requested the protection change.
• Identify the target memory region and its original purpose.
• Check whether the region contains startup parameters.
• Correlate the change with later thread-context manipulation.
• Review whether the parent application has a legitimate reason for the action.

Attackers may call a lower-level system service instead of VirtualProtectEx, so telemetry should cover native API and kernel-level memory-protection changes where possible.

Thread-context changes require additional scrutiny

Debuggers, compatibility tools and security products may legitimately modify thread contexts. Defenders should avoid treating every NtSetContextThread call as malicious.

The important question is where the new instruction pointer leads. Redirecting a thread into memory holding process parameters is highly unusual for ordinary software.

The NtSetContextThread API gives software the ability to alter a thread’s register state. That capability can redirect execution without creating a new thread.

Observed behavior	Detection value
Thread context changed by an unrelated process	Moderately suspicious
Instruction pointer redirected into private memory	Highly suspicious
Instruction pointer points to process parameters	Strong indicator of this technique
Protection changed immediately before redirection	Strengthens the injection hypothesis
Unexpected parent-child relationship	Adds useful context

Organizations should validate EDR coverage

Security teams should test whether their endpoint products detect the sequence in a controlled lab. They should not deploy the proof of concept on production systems.

Testing can reveal whether an EDR records full process parameters, PEB reads, remote memory protection changes and thread-context updates.

Detection engineers can then create correlation rules that cover the full sequence rather than relying on one high-profile API.

• Confirm that EDR telemetry captures complete process command lines.
• Check whether environment block data is available for investigation.
• Validate alerts for remote memory-protection changes.
• Review visibility into NtSetContextThread or equivalent system calls.
• Create rules for execution from process-parameter memory.
• Test detections after every major EDR update.

Organizations should also submit the research pattern to their EDR vendor. Vendors may already detect related activity through behavior models not visible to local administrators.

Least privilege can limit who uses the technique

Process Parameter Poisoning does not provide initial access by itself. The attacker must first run a loader on the target Windows computer.

Application allowlisting can block unknown executables and scripts before they start the injection chain. Least-privilege controls may also prevent a compromised process from opening higher-privileged targets.

Prompt operating system and application updates reduce the number of vulnerabilities attackers can use to gain the first foothold required for the technique.

1. Block unapproved executables and scripts with application control.
2. Remove local administrator rights from ordinary users.
3. Use attack surface reduction rules where compatible.
4. Restrict interpreters and development tools on sensitive endpoints.
5. Patch internet-facing and frequently exploited applications quickly.
6. Investigate unusual process access before it leads to injection.

These controls will not directly prevent every parameter-poisoning attempt, but they can stop the attacker before the loader reaches the process-injection stage.

The research exposes a wider process-monitoring gap

Process injection detection often focuses on APIs strongly associated with older techniques. Attackers continue to find ways to reuse legitimate process initialization and management features.

Process Parameter Poisoning demonstrates that malicious code does not always need a conventional remote write. Windows may copy attacker-controlled data into the target as part of normal process creation.

Defenders should examine the complete chain, including process startup inputs, PEB access, memory protections and changes to the main thread’s instruction pointer.

The public proof of concept has not been linked to active malware. However, its release gives both defenders and attackers a clear description of the technique, making detection validation a priority for organizations that rely on EDR products.

FAQ