Process parameter poisoning exposes a blind spot in EDR evasion

At a glance

What this is: This is a technical analysis of Process Parameter Poisoning, a Windows endpoint evasion method that hides payloads in process parameters and can bypass standard EDR triggers.

Why it matters: It matters because endpoint and identity-adjacent defenders cannot rely on memory-write telemetry alone when execution is staged through less-monitored process creation fields and thread hijacking.

Context

Process Parameter Poisoning is an endpoint evasion technique, not a new malware family. It matters because modern EDR products still depend heavily on watching a limited set of API calls and memory-manipulation patterns, which creates a blind spot when attackers move staging into process creation internals. The primary security gap is not visibility into every process, but reliance on a narrow set of expected abuse patterns.

From an NHI perspective, the article is relevant because defenders increasingly protect workloads, agents, and service processes that behave like machine identities at runtime. When malicious code rides inside ordinary process parameters, the control problem shifts from simple detection of suspicious writes to governance of how execution is initiated, inherited, and trusted inside the process boundary.

Key questions

Q: What breaks when EDR only watches classic process-injection APIs?

A: Controls that rely on a narrow API set miss payloads staged inside process parameters before the suspicious write ever happens. In practice, that means the detection boundary is too late and too specific, so an attacker can use ordinary process creation fields, then hijack execution from a location the product never treated as dangerous.

Q: Why does process parameter poisoning increase endpoint risk even without obvious malware APIs?

A: It shifts the abuse point from memory-writing calls to process initialization internals, which many tools treat as benign. That matters because the malicious code inherits the legitimacy of a normal process launch, so the security decision is made before the usual injection telemetry is available.

Q: How do attackers use Thread Execution Hijacking?

A: Attackers use Thread Execution Hijacking to redirect an existing thread inside a running process so malicious code executes in a trusted context. That can evade simple process-launch detections and complicate attribution. Defenders should look for suspicious memory manipulation, remote thread activity, and process anomalies that do not fit the application’s normal behaviour.

Q: How should teams combine endpoint prevention with threat intelligence for evasion techniques?

A: Use threat intelligence to identify emerging injection variants, then translate those behaviours into detections that cover process creation, memory staging, and thread manipulation together. The best outcome is not more alerts, but correlated telemetry that can distinguish legitimate software from execution hidden inside trusted process structures.

Technical breakdown

Process parameter spoofing hides payloads before execution starts

Process Parameter Poisoning abuses process startup metadata rather than the familiar memory-allocation path. Instead of calling APIs such as VirtualAllocEx or WriteProcessMemory, the payload is placed into fields like STARTUPINFO.lpReserved and later surfaced inside process structures such as the PEB and RTL_USER_PROCESS_PARAMETERS. Because the malicious bytes are present at creation time, endpoint tools that key on post-launch memory writes can miss the staging step entirely. The technique is effective precisely because it exploits what looks like normal process initialization.

Practical implication: defenders need telemetry that inspects process creation fields and parameter content, not only memory-write events.

Thread execution hijacking turns hidden parameters into code execution

After the payload is embedded, the technique uses thread context manipulation to redirect execution into the hidden buffer. The attacker reads the target process state, identifies the parameter buffer location, then changes the instruction pointer so the thread runs code stored in the poisoned parameter area. This is a form of process injection, but it avoids the conventional sequence of obvious memory APIs and may not require the thread-suspension patterns many detections expect. That makes signature-based or hook-based monitoring materially less reliable.

Practical implication: monitor thread context changes and unexpected execution from non-standard memory locations.

EDR blind spots appear when controls overfit to known API abuse

The article shows why controls that watch only classic injection APIs can be bypassed by technique-stacking. Once the payload is hidden in process parameters, the attacker can combine thread hijacking, executable permission changes, and DLL unhooking to reduce both static and runtime detections. In practice, this exposes a broader endpoint security problem: detections tuned to high-volume false positives often become blind to novel abuse paths that still achieve the same effect. Good defensive logic has to look for impossible combinations of normal process behavior and abnormal execution outcomes.

Practical implication: add behavioural detections for abnormal execution paths and reduce dependence on API-hook-only coverage.

Threat narrative

Attacker objective: The attacker’s objective is to execute code inside a foreign process while avoiding endpoint detection long enough to stage and run additional payloads.

1. Entry begins when the attacker creates a process with poisoned startup parameters, embedding shellcode in fields that appear operationally normal.
2. Credential access is not the core objective here; instead, the attacker abuses thread context manipulation and process internals to gain execution inside a foreign process without classic memory-write APIs.
3. Escalation occurs when the payload becomes executable and can launch a second-stage downloader or additional tooling while evading common EDR triggers.
4. Impact is achieved when the endpoint security stack fails to alert, allowing stealthy code execution and follow-on payload delivery inside the target environment.

Breaches seen in the wild

• CircleCI breach 2023: Malware stole a CircleCI engineer's SSO session; attackers exfiltrated customers' CI/CD secrets and keys, forcing a platform-wide rotation.
• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

API-hook dependence is now a governance weakness, not just a detection gap: when endpoint controls only watch a small set of familiar injection APIs, attackers can move into process-init fields and bypass the policy assumption those controls rely on. The article demonstrates that the issue is not only evasion technique quality, but a control model that equates known API abuse with meaningful coverage. Practitioners should treat this as a detection-design failure and broaden telemetry beyond the calls their tools were built to watch.

Process initialization is becoming part of the attack surface: the use of STARTUPINFO, PEB structures, and thread context manipulation shows that execution provenance now matters as much as code provenance. For defenders, that means the boundary between ordinary operating-system behaviour and malicious staging is narrower than many EDR policies assume. Endpoint governance should account for how payloads are introduced, not only whether a process later looks suspicious.

Technique stacking is the real lesson: process parameter poisoning becomes more dangerous when combined with DLL unhooking, alternate payload delivery, and memory permission changes. This is a named example of detection-response latency, where each individual control may appear adequate but the combined attacker path remains unbroken. The practical conclusion is that layered controls must correlate process creation, thread manipulation, and execution location together.

Stealthy process injection remains fundamentally an identity and privilege problem at the workload level: the malicious process borrows the legitimacy of another process context to run code that would not be trusted on its own. That is conceptually similar to misuse of workload identity, where execution inherits trust from the surrounding context rather than proving its own legitimacy. Practitioners should connect endpoint defence to workload trust assumptions, not just malware signatures.

Process Parameter Poisoning sharpens the case for behaviour-led endpoint policy: controls must look for where execution starts, how it is redirected, and whether the memory location matches the intended trust boundary. MITRE ATT&CK mapping is useful here because the technique spans process injection, thread execution hijacking, and argument spoofing. The practitioner takeaway is simple: if detection logic cannot see beyond one API family, it will eventually be outpaced.

What this signals

Process Parameter Poisoning is a reminder that endpoint governance must move upstream to process-creation telemetry and not stop at visible memory-write behaviour. If defenders only monitor the actions they already expect, they will continue to miss payload staging that occurs inside normal operating-system fields.

Attackers increasingly win by blending execution into trusted runtime structures, which means the practical control question is no longer whether a binary looks malicious at rest. The question is whether the endpoint stack can explain why code is executing from a buffer that should never have been executable in the first place.

For practitioners

• Harden detections around process creation metadata Inspect STARTUPINFO and related process creation fields for high-entropy or binary-like content that does not belong in normal launcher parameters.
• Correlate thread context changes with execution location Alert when a thread’s instruction pointer is redirected into parameter buffers, PEB-derived regions, or other non-standard execution memory.
• Expand EDR coverage beyond memory-write APIs Do not rely on VirtualAllocEx, WriteProcessMemory, or similar hooks as your primary injection detector because this technique avoids them by design.
• Review false-positive tuning on executable memory changes Validate which executable-permission events are suppressed in your environment and confirm they are still available for high-confidence suspicious staging.

Key takeaways

• Process Parameter Poisoning shows that modern endpoint evasion can bypass API-hook-based detection by hiding payloads in ordinary Windows process parameters.
• The technique matters because execution can be redirected through thread hijacking after process creation, leaving standard injection telemetry blind until too late.
• Defenders need process-creation inspection, thread-context monitoring, and execution-location checks together if they want coverage against this class of evasion.

Key terms

• Process Parameter Poisoning: A stealthy Windows process injection method that hides payloads inside process creation parameters instead of using obvious memory-write APIs. It abuses normal startup structures so endpoint products that watch standard injection calls can miss the malicious staging step.
• Thread Execution Hijacking: A technique that redirects an existing thread so it executes attacker-controlled code rather than the program’s intended instructions. In endpoint security, it is important because the process may already look legitimate while its execution flow has been silently altered.
• Process Environment Block: A Windows data structure that stores runtime process information, including flags and loader state. Malware often reads it directly to avoid obvious detection APIs, which is why endpoint controls need behavioural correlation rather than simple API monitoring.
• Argument Spoofing: A deception technique that makes process arguments or startup fields appear normal while carrying malicious content. It matters when detections rely on visible command lines or standard parameters, because the payload can be hidden in fields that security tools do not inspect closely enough.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the broader security decisions that govern runtime trust.