Opens in a new tab

Process Parameter Poisoning: Why Combining EDR Evasion Methods Makes Detection Harder

  • Home
  • Blog
  • Process Parameter Poisoning: Why Combining EDR Evasion Methods Makes Detection Harder
Glowing cylindrical containment chamber illustrating process parameter poisoning of injected code
Updated October 25, 2026 at 9:30 AM ET

Businesses running Windows may want to talk with their IT team about how their endpoint detection tools watch what processes do. Security firm Flashpoint published research on process parameter poisoning, a technique that hides malicious code inside the structures Windows uses to launch a process, and found that pairing it with other bypass methods can stop some endpoint tools from alerting at all. For a small-business setup, detection built only around a short list of monitored Windows APIs can be sidestepped, so the answer is to watch what a process does, not just which APIs it calls.

What happened

According to Dark Reading, Flashpoint published research on an EDR evasion technique called process parameter poisoning, first described in July by researchers Max Hirschberger and Ogulcan Ugur. The method plants a payload inside the standard process initialization structures Windows transfers into a newly created process, so it avoids the memory allocation and write APIs that endpoint detection and response (EDR) tools usually monitor. Flashpoint built and tested its own implementation in Rust and reported that the technique became significantly harder to detect once combined with additional evasion measures.

Are you affected?

Process parameter poisoning is an evasion technique designed to cheat endpoint detection and response (EDR) in Windows. An attacker already executing code on a Windows system can create a sacrificial process and abuse the startup parameters Windows automatically transfers into that new process.

Flashpoint says it has not found the technique in public malware samples so far. Paul Daubman, senior analyst at Flashpoint, told Dark Reading the firm hasn’t identified evidence of it in public samples to date, "but there’s nothing really stopping the threat actors from using it."

What to do now

  1. Ask your IT team or EDR provider how they watch for evasion techniques like this one.
  2. Have them keep an eye on unusual process behavior on your Windows machines.
  3. Enable detection of code running from abnormal memory locations rather than expected image-backed regions.
  4. Watch for memory permissions being changed to executable at unusual times.
  5. Broaden endpoint telemetry to cover what a process actually does, not only the Windows API calls tied to classic process injection.

How process parameter poisoning works

Most process injection detection leans on a small set of Windows APIs. Tools watch calls such as VirtualAllocEx(), WriteProcessMemory(), and MapViewOfFile2() because attackers have historically used them to write code into a running process. Process parameter poisoning sidesteps those calls. An attacker who already has code execution creates what researchers call a "sacrificial process" and tucks malicious content into the routine startup parameters Windows passes into it, so the code runs during a normal process launch and the suspicious API calls never appear.

Hirschberger and Ugur tested the approach against four unspecified market-leading EDR products in July and wrote in their blog post that "code injection succeeded in all cases and no alerts were created, even though the EDRs were configured to detect, block and remediate."

What combining evasion methods changed

Flashpoint ran its Rust proof of concept against a commonly used open source EDR platform with an extended detection and response (XDR) component. Flashpoint reported: "The EDR platform itself failed to produce any alerts from executing the malicious binary. However, the XDR component blocked on the initial creation of a new process and COM interactions by the second stage payload."

Flashpoint then added two more evasion methods. DLL unhooking restores Windows library functions that security software has modified, which can undo parts of user-mode EDR monitoring. A policy to block non-Microsoft DLLs can keep some third-party monitoring components from loading at all. After applying both during creation of the sacrificial process, the researchers wrote that "Analysts observed no blocks from the XDR during execution and observed no alerts on the platform."

How likely is real-world use?

Daubman compared it to an older method, saying "It’s similar to process parameter spoofing, which is a well-known technique yet still not often used in samples." He added, "As such, we don’t expect it to be widely used outside of dedicated red teams or sophisticated threat actors."

FAQ

What is process parameter poisoning?

It is a Windows EDR evasion technique that hides a malicious payload inside the standard process initialization structures used during process startup, avoiding the memory allocation and write APIs that endpoint security tools typically monitor.

How does the technique slip past EDR products?

It abuses the startup parameters Windows automatically transfers into a newly created process, and this is done without using some of the memory allocation and write operations that EDR products traditionally monitor for process injection.

How can defenders detect process parameter poisoning?

Flashpoint recommends inspecting process parameters for anomalous data, monitoring for thread execution hijacking, detecting code that runs from abnormal memory locations, and watching for memory permissions being changed to executable, rather than relying only on classic process injection API calls.

This article reports on publicly available information from the sources listed below. We have no reason to believe it is inaccurate, but we have not independently verified every claim, and details may change as the story develops.

Sources

← All Articles