Modern Endpoint Detection and Response (EDR) platforms have made traditional malware injection techniques significantly harder to execute. In most cases, if a threat actor attempts to write malicious code into a process, an alert will fire. However, that sense of security is being actively challenged as cybercriminals and red teams find new ways to blend malicious payloads into standard operating system routines.

Flashpoint’s Intelligence team built and tested a proof-of-concept for a newly disclosed technique known as Process Parameter Poisoning. By compiling a custom payload and layering evasion mechanics, our analysts demonstrated how easily traditional API hooks can be rendered blind in a laboratory environment—achieving zero alerts across tested EDR/XDR controls.

What is Process Parameter Poisoning?

Process Parameter Poisoning is a novel endpoint detection and response (EDR) evasion technique that combines process parameter spoofing and thread execution hijacking to inject code into foreign processes without triggering standard security detection mechanisms.

Discovered by researchers Max Hirschberger and Ogulcan Ugur, Process Parameter Poisoning is designed to inject code in foreign processes without relying on the conventional memory-manipulation workflows that modern security tooling monitors.

To execute process injection, historically security tools and threat actors alike have focused on a small set of well-known Windows application programming interfaces (APIs). Process Parameter Poisoning shifts away from these heavily watched routines entirely. Instead of calling memory-accessing APIs to allocate and write into a target process, the technique hides the malicious payload directly inside standard process initialization structures during the initial creation of a process. The result is a fundamental shift in defense evasion that effectively blinds traditional, API-hooking EDR agents during the initial stages of code execution.

How Does Process Parameter Poisoning Work?

Process Parameter Poisoning allows attackers to bypass suspicious memory-accessing Windows APIs, such as VirtualAllocEx(), WriteProcessMemory(), and MapViewOfFile2(). Security products heavily monitor these specific APIs due to their high rate of abuse in traditional process injection techniques. However, by avoiding these calls, an attacker effectively bypasses the initial primary triggers used by endpoint agents to flag malicious cross-process memory activity.

When using the Windows application programming interface (API), CreateProcessA/W(), the developer can specify parameters such as the command-line to be executed by the new process, environment variables for the new process, current working directory for the process, window title if it is a console application, create a hidden window, create the process in a suspended state, etc. Many of these parameters are passed into CreateProcessA/W() via the STARTUPINFOA/W structure.

Some entries are undocumented and labeled “reserved” by Microsoft. The discovering researchers found that data stored in STARTUPINFO->lpReserved ends up in the Process Environment Block once the new process is initialized in an entry called “ShellInfo.” Below is an example of placing data into the STARTUPINFOW->lpReserved entry in a test application and the data stored in ShellInfo while debugging the newly created process.

†

Validating Process Parameter Poisoning in Rust

Flashpoint analysts created a proof-of-concept (POC) in Rust to test this technique based on the POC C++ source code provided by the researchers:

1. First the necessary data structures are initialized and the shellcode is passed into the STARTUPINFO->lpReserved field.
2. The target process is created with the infected STARTUPINFO and then a short wait to let the program initialize.
3. NtQueryInformationProcess() is used to acquire PROCESS_BASIC_INFORMATION about the newly created process.
4. The PROCESS_BASIC_INFORMATION structure has an entry called PebBaseAddress that provides the location of the process’s Process Environment Block.
5. NtReadVirtualMemory() is used to read the memory address provided by PebBaseAddress to get the PEB for that process.
6. The PEB has an entry called ProcessParameters that holds the structure RTL_USER_PROCESS_PARAMETERS and is where the ShellInfo entry mentioned earlier is stored.
7. NtReadVirtualMemory() needs to be used again to read the RTL_USER_PROCESS_PARAMETERS structure and get the address of the ShellInfo.Buffer entry.

Flashpoint confirmed that after changing the memory to have executable permissions, the threat actors can perform thread hijacking by using GetThreadContext() to acquire information about the current running thread, change the instruction pointer to point to the ShellInfo.Buffer address, and then SetThreadContext() to apply the changes and execute the shellcode.

Flashpoint analysts further confirm that this technique also works with the WindowTitle entry, CommandLine entry using the same series of steps.

The technique also works with the Environment entry but requires additional steps. Environment blocks require a variable name and the variable data separated by an “=.” Environment blocks can contain multiple variable entries in which each entry is ended with a null terminator. Two null terminators are necessary to denote the end of the environment block. This means the payload needs to be embedded in a longer string with a “{NAME} = {VALUE}” format.

Flashpoint analysts note that four null terminators were appended to the shellcode bytes to denote the end of an environment block in Unicode. The resulting payload buffer is then passed into the lpEnvironment variable of CreateProcessW() along with the CREATE_UNICODE_ENVIRONMENT creation flag.

The rest of the process remains the same as reading the PEB and RTL_USER_PROCESS_PARAMETERS structure. The Environment entry is read, but at the offset of the embedded shellcode within the poisoned environment block string. Because four bytes were added to the beginning of the shellcode to make the Unicode environment block, execution needs to begin after four bytes from the beginning of the buffer to begin executing at the shellcode.

Flashpoint notes that the shellcode requires no NULL bytes, and, if using the PAGE_EXECUTE_READ flag, it cannot overwrite itself. This means automated shellcode generators such as MSFVenom might not work either because they contain NULL bytes or use encoders that perform memory writes during execution. Flashpoint analysts wrote custom shellcode to further test this technique. The shellcode downloads and executes an additional payload. The combination of this technique, custom shellcode, and the use of Rust as the programming language proved successful in minimizing initial static detections by security software.

Flashpoint tested this technique with a commonly-used open source EDR platform. 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 analysts then combined this technique with the DLL unhooking technique and applied the non-Microsoft block DLL policy during the creation of the sacrificial process. Analysts observed no blocks from the XDR during execution and observed no alerts on the platform.

Associated MITRE ATT&CK

Security teams can leverage several detection strategies to identify Process Parameter Poisoning, though each approach carries distinct limitations:

• Analyzing Parameter Entropy and Argument Spoofing (MITRE ATT&CK T1564.010): Security tools can inspect initialization strings within process structures for unusually high entropy, which often indicates the presence of obfuscated or raw binary shellcode embedded within parameters.
• Monitoring Thread Execution Hijacking (MITRE ATT&CK T1055.003): Analysts can monitor for thread context manipulation; however, because Process Parameter Poisoning does not invoke explicit thread suspension or resumption APIs, specific detection rules that depend on those parameters will fail to trigger.
• Detecting Code Execution in Abnormal Memory Locations (MITRE ATT&CK T1055): Detections can flag execution attempts taking place outside the standard executable section, particularly when code executes directly within Process Environment Block (PEB) parameter buffers.
• Auditing Memory Permission Modifications: Tracking instances where memory region permissions are altered to executable states can reveal payload staging. However, enterprise security controls often tune down or avoid these specific alerts due to high volumes of false positives in normal software operations.

Stay Ahead of Process Parameter Poisoning Using Flashpoint

Process Parameter Poisoning demonstrates another advancement in stealthy process injection and the constantly evolving research into evading security products. By using the previously unknown purpose of the lpReserved field within the STARTUPINFOW structure to house shellcode, this technique bypasses standard security product triggers associated with common memory-allocation APIs. While this proof-of-concept was proven successful in lab testing, the technique has multiple opportunities for detection and will most likely require a combination of additional evasion techniques to achieve a higher success rate.

As threat actors continue to refine technique-stacking and exploit overlooked Windows internals, relying on traditional API hooks is no longer enough to protect your enterprise. Staying ahead of modern evasion mechanics requires proactive intelligence and deep visibility into emerging adversary TTPs.

Request a demo today to see how best-in-class threat intelligence can help security teams detect, prepare for, and neutralize advanced defense evasion techniques before they impact your network.