New Windows Process Injection Technique Evades 4 EDR Solutions

Key Takeaways

• A novel Windows process injection technique, “Process Parameter Poisoning,” has been discovered that evades detection by multiple leading EDR solutions.
• The method leverages legitimate Windows process startup parameters to inject malicious code, bypassing traditional EDR hooks designed to detect direct memory manipulation.
• While not currently linked to active malware campaigns, this proof-of-concept highlights a blind spot in conventional endpoint security and could be adopted by attackers with initial access.
• Defenders must broaden their telemetry and detection logic to include unusual process startup parameters and correlated thread-context changes.

New Windows Process Injection Technique

A recently unveiled proof-of-concept for Windows demonstrates a sophisticated method for injecting malicious code into legitimate processes, successfully circumventing several common detection mechanisms employed by endpoint security tools. This technique, dubbed “Process Parameter Poisoning,” deviates from typical process injection strategies by utilizing the standard information passed during Windows program initialization rather than directly writing a payload into another process’s memory space. This research, while not yet tied to active malware or ongoing campaigns, is significant because process injection remains a favored tactic for malware to mask its operations within trusted applications. Threat actors who have already established a foothold on a Windows system could readily adapt this technique.

Analysts behind the Orange Cyberdefense project stated in a report shared with Cyber Security News (CSN) that their loader successfully bypassed detection by four prominent Endpoint Detection and Response (EDR) products during testing. These findings underscore a critical gap in current defense strategies, which often prioritize the detection of well-known memory-writing and process-creation behaviors.

Traditional process injection typically follows a predictable sequence: a malicious program initiates or targets another process, allocates memory within it, writes the malicious code to that memory, modifies memory permissions to allow execution, and then either starts a new thread or redirects an existing one to execute the injected code. Security products are generally configured to flag API calls associated with these steps, such as VirtualAllocEx, WriteProcessMemory, and CreateRemoteThread.

The Process Parameter Poisoning technique, however, operates differently. When Windows creates a new process via the CreateProcessW function, it populates internal data structures known as the Process Environment Block (PEB) with command-line arguments, environment variables, and startup configuration settings. The new loader strategically embeds its payload within one of these copied values, effectively “poisoning” a process parameter. This can involve using the command line itself, an environment block, or the lpReserved field within the STARTUPINFO structure, which Windows maps to ShellInfo.

Once the target program has started, the loader then accesses the target process’s PEB to retrieve the stored malicious data using standard memory-read functions. This approach deliberately avoids the remote memory allocation and write operations that many EDR solutions are designed to detect. Subsequently, the technique modifies the memory permissions of the stored payload to enable execution. Instead of creating a remote thread, it manipulates the instruction pointer of the new process’s main thread using NtSetContextThread. This redirects the legitimate program’s execution flow to the injected code, sidestepping several routine indicators associated with conventional injection methods. The researchers also found that the loader does not require the target process to be created in a suspended state or for its thread to be suspended later, actions often linked to process hollowing and similar evasion tactics. This reduction in conspicuous operations limits the forensic trail available to behavior-based defenses, though it does not render the activity entirely invisible.

Detection Needs Broader Context

This research highlights the imperative for security teams to move beyond relying solely on alerts for specific memory allocation, remote writes, or remote thread creation. Enhanced monitoring should encompass unusual inputs to CreateProcessW, specifically scrutinizing abnormally long command lines, atypical environment data, or unexpected values supplied within STARTUPINFO structures.

Correlating process creation events with rapid changes in thread context can help uncover the full attack sequence. Defenders should look for processes whose startup parameters contain data inconsistent with their expected function, especially when followed by NtQueryInformationProcess calls and reads of the PEB. A subsequent change in memory protection from readable/writable to readable/executable, combined with a NtSetContextThread call, warrants immediate investigation. While each of these actions may be legitimate in isolation, their combination and timing can be highly indicative of malicious activity.

The proof-of-concept does have certain limitations. Since process parameters are typically null-terminated strings, raw shellcode containing null bytes cannot be directly copied using this simple method. The researchers addressed this by developing null-byte-free code and employing a staged routine capable of reconstructing arbitrary payloads, including DLL loading or content fetched from HTTPS, at a later stage.

What You Should Do

• Enhance Telemetry: Expand logging and monitoring to capture detailed information about process startup parameters (command lines, environment variables, STARTUPINFO structures) and thread context changes (e.g., NtSetContextThread calls).
• Refine EDR Detections: Update EDR rules to identify anomalous patterns involving unusual CreateProcessW inputs, particularly excessively long or malformed parameters, followed by PEB reads and rapid thread context modifications.
• Correlate Events: Implement correlation rules to link seemingly benign individual events (e.g., a process creation with an unusual parameter, followed by a memory protection change and thread redirection) into a suspicious sequence.
• Investigate Parent-Child Process Relationships: Closely monitor and investigate any unusual parent-child process relationships, especially when combined with the aforementioned indicators.
• Implement Application Allowlisting: While not a direct countermeasure, strict application allowlisting can prevent the initial execution of unauthorized code, thereby reducing the attacker’s ability to leverage this technique.
• Apply Least Privilege: Enforce the principle of least privilege to limit the impact of any successful initial compromise, making it harder for attackers to perform process injection or other lateral movement.
• Maintain Patching Schedules: Promptly apply all security patches and updates to operating systems and applications to mitigate other vulnerabilities that attackers might exploit to gain the initial code execution necessary for this technique.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.