Loading story…
Researchers disclosed Process Parameter Poisoning, a Windows process-injection technique that stores shellcode in process-initialization parameters propagated to a newly created process's Process Environment Block (PEB). Rather than relying on heavily monitored cross-process memory functions such as WriteProcessMemory and VirtualAllocEx, the technique uses those parameter buffers and thread-execution hijacking to run the payload.
Flashpoint validated the method with a Rust proof of concept in a laboratory environment and reported no alerts from tested EDR/XDR products when additional evasion measures were applied. The researchers stressed that this is not evidence of in-the-wild exploitation; defenders should monitor for anomalous or high-entropy process parameters, manipulated thread contexts, execution originating from PEB parameter buffers, and memory-protection changes that render such regions executable.
Get the actors, campaigns, and ATT&CK mapping behind it.
1 event from the most recent confirmed update back to the earliest known activity.
Researchers Max Hirschberger and Ogulcan Ugur disclosed Process Parameter Poisoning, a Windows process-injection and EDR-evasion technique that stores payloads in process-initialization data and uses thread execution hijacking. Flashpoint validated the technique with a Rust proof of concept in laboratory testing, reporting no alerts after combining it with additional evasion measures.
Get the adversaries, campaigns, and ATT&CK mapping behind this technique, with detections ready to deploy.
3 references tracked. Mallory keeps watching after this page renders.
flashpoint.io
Open sourcelearn.microsoft.com
Open sourcelearn.microsoft.com
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Researchers disclosed **Process Parameter Poisoning (P³)**, a Windows code-injection technique that stages malicious payloads inside a newly created process by abusing data copied during `CreateProcessW`, including the command line, environment block, and `STARTUPINFO.lpReserved` fields. Instead of relying on heavily monitored APIs such as `WriteProcessMemory` and `VirtualAllocEx`, the technique locates attacker-controlled data through the target process’s **PEB** and `RTL_USER_PROCESS_PARAMETERS`, then prepares it for execution inside the remote process. A public proof of concept, **`p3-loader`** from Orange Cyberdefense, demonstrates redirecting the target process’s main thread with `NtSetContextThread` after changing memory protections, avoiding classic remote-thread creation and reducing common process-injection telemetry. SensePost reported that its implementation executed without alerts across four major EDR products even when process-injection protections were enabled, while both disclosures noted defender opportunities such as monitoring executable protections on process-parameter memory, anomalous process-creation parameters, remote reads of process parameters, and thread-context changes following protection updates.
Jul 8, 2026
Security researchers published a proof-of-concept for **remote function stomping**, a Windows process-injection method that overwrites an existing exported API function inside another process and then runs the injected payload with a remote thread. The demonstration used `notepad.exe` as the target and selected `CallMsgFilterA` from `user32.dll`, resolving the function locally before modifying the remote process with `VirtualProtectEx`, writing shellcode through `WriteProcessMemory`, and triggering execution via `CreateRemoteThread`. The write-up said the technique depends on the target DLL already being loaded in the remote process and noted that **ASLR** can affect DLL base addresses across processes. The authors presented the material as educational for malware researchers, red teams, and defenders, but the compiled sample was reportedly flagged as **suspicious** in an ANY.RUN sandbox, underscoring the detection and abuse potential of the method.
Jul 16, 2026
Multiple public research reports detailed how attackers can evade Windows security monitoring by abusing native APIs, loader behavior, and application logging. White Knight Labs and XPN documented techniques to suppress or bypass **Event Tracing for Windows (ETW)** visibility in .NET and Windows processes, while separate research showed that access-mask-based detections can be defeated with `DuplicateHandle` by first requesting only `PROCESS_DUP_HANDLE` and then cloning a more privileged handle to targets such as **LSASS** or **winlogon**. Microsoft documentation for `CreateProcessA` also appeared in the reference set because process creation remains central to many payload chains, including shellcode that ultimately launches command shells or follow-on tooling. Additional reports showed how attackers can blend execution into legitimate Windows behavior and trusted software. iPurple described **EntryPoint Hijacking**, in which a loaded DLL's entry point is overwritten so malicious code runs during normal thread creation or loader activity, reducing obvious injection signals and complicating EDR detection. NVISO separately analyzed Metasploit reverse-shell shellcode that walks the **PEB** and resolves APIs such as `LoadLibraryA`, networking functions, and `CreateProcessA`, while Hunt & Hackett showed that **ConnectWise Control/ScreenConnect** can be used for intrusion activity and that its own event logging can be disabled by patching `ScreenConnect.Core.dll`. Together, the reports underscore that defenders must validate loader integrity, monitor low-visibility handle requests and memory writes, and avoid relying on a single telemetry source such as ETW or application-generated event logs.
Aug 15, 2026