On 6 July, two researchers published a code injection technique and tested it against four market-leading EDRs configured to detect, block and remediate. The injection worked on all four. No alert was created. On 22 September, another team reproduced it and their EDR said nothing either. The useful question is not whether your EDR catches that particular technique. It is what you are left with when nothing fires.
An injection that never writes into another process
Classic code injection always does the same thing: allocate memory inside another process and write the code there. Those two operations go through a handful of system calls every EDR has been watching for over a decade, and on which a good chunk of the industry's detection rules are written.
Process Parameter Poisoning does not write. It puts the payload into the parameters a new process is started with: the command line, the environment variables block, and a poorly documented field of the startup structure, lpReserved, which Windows deposits into the process environment block (the PEB) under an entry called ShellInfo. The process is born with the material already inside, placed there by the normal process-creation machinery, and all that is left is to redirect the thread's execution into that region.
There is one sentence in Flashpoint's analysis that explains the silence better than any summary. Because the technique invokes no explicit thread suspension or resumption, they write, "specific detection rules that depend on those parameters will fail to trigger". The EDR is looking at the right door of a house that has another way in.
A detection catalogue is a collection of descriptions of how something was done. Change the how and the description stops matching. That is how anything detecting by known behaviour works, whatever you paid for it.
What the two publications say, and what they do not
The first is from SensePost, by Max Hirschberger and Ogulcan Ugur, dated 6 July 2026. The sentence that got picked up everywhere is this one, verbatim: "Code injection succeeded in all cases and no alerts were created, even though the EDRs were configured to detect, block and remediate." Four market-leading products, they say. They do not say which, so nobody gets to look at their own console and conclude theirs was not among them.
The second is from Flashpoint, dated 22 September, and this is where the headline loses altitude. They tested the technique against "a commonly-used open source EDR platform" —one platform, and an open-source one. The EDR raised no alerts, true. But in that same test, "the XDR component blocked on the initial creation of a new process and COM interactions by the second stage payload". In other words: it did stop it. Only after adding DLL unhooking and creating the sacrificial process —the one started purely to host the payload— with the policy that blocks non-Microsoft DLLs —which, incidentally, keeps the EDR's own DLL out— did the analysts observe, in their own words again, "no blocks from the XDR during execution and observed no alerts on the platform".
And the researchers themselves close by hitting the brakes: "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". That is not "EDRs are useless". It is one layer going quiet on its own, plus two more evasions stacked on top for the rest to go quiet as well.
There is one nuance neither publication underlines, and it changes your order of priorities completely: this is post-exploitation. To place a payload into a process's parameters you have to be running code on the machine already. Neither text presents the technique as a way in. If somebody needs to dodge your EDR, they have already walked past three other things that are cheaper to fix.
The primitive is not new
SensePost's own post says so, in a note added after publication: researcher X-C3LL pointed out that the same primitive had already been presented by modexp in a blog post that is now deleted. SensePost gives no date for it, so we do not know how long this has been circulating; we do know it was publicly described before anybody put it in a headline.
That is the real clock defence gets planned on, not the week something goes viral. What ages is how long an idea takes to travel from a deleted blog post to a tool anybody can run: first the authors' C++ proof of concept, then its reimplementation in Rust. If your security plan moves headline by headline, you will be late for what matters.
Four checks you can ask for this week
Both publications close with detection recommendations. We have merged them into four questions you can pass as-is to whoever runs your platform:
- 1Entropy of startup parameters. Flashpoint suggests inspecting initialisation strings inside process structures for unusually high entropy, a common sign of obfuscated code or raw binary. SensePost puts it from the other side: when the entropy of the command line approaches that of shellcode, or departs from that of a normal value. This maps to MITRE ATT&CK technique T1564.010.
- 2Execution outside the normal executable section. Specifically, code running inside the PEB's parameter buffers. It is the most specific of the four signals, because nothing should ever execute there. Technique T1055.
- 3The sequence, not the isolated call. SensePost points at the pattern: a call that makes a memory region executable followed by thread context manipulation. And, separately, reading another process's parameter structure through the pointer in its PEB. On their own, both are noise; together and in that order, they are not.
- 4Memory permission changes to executable. Auditing when a region becomes executable reveals payload staging. It is the noisiest of the four and the hardest to live with without context; that is why it goes last and not first.
None of the four is a button. All four are queries over telemetry, and whether they can be run at all depends on three conditions rarely checked at signing time: that the agent emits those events, that they are kept long enough, and that somebody queries them.
The question that is not on the product sheet
How many days of raw telemetry does your console keep? If the answer is seven, the four checks above are worth nothing against access that began three weeks ago — which is the normal case: what you investigate is rarely from today. And if the agent has not sent anything in days, the dashboard can still say everything is protected —we wrote it up here from what Akamai showed at DEF CON 34.
The second question is the uncomfortable one: who writes the query? A platform with nobody looking at it is an expensive antivirus with a nice dashboard. That is where buying an EDR and hiring managed EDR/MDR part ways: in the second case there is someone on duty who has to go looking for what did not fire. And if the hunt finds something, the response has to be written in advance too: isolating a machine is one click and putting it back on the network has to have been thought through calmly.
When to do nothing about this
If your company still has users with local administrator rights, email does not enforce a second factor and backups live on a share everybody can see, this is not your October priority. Nor your November one. A post-exploitation technique matters once you have closed off the way in, and nobody is using exotic injections to get in: they use somebody's reused password.
We say this knowing which side we get paid on. We sell managed EDR/MDR and consulting, and an article that opens with "four EDRs and no alerts" is the perfect door to sell you a platform swap. We are not going to: switching products because a lab dodged yours is the expensive, wrong reaction. None of them catches everything. Anyone promising otherwise is selling you something, and the expensive part of the budget should go to telemetry retention and to the on-call rota before it goes to the licence.
What we are not claiming
- ✗We have not reproduced the technique. Everything above comes from two public publications, cited below, read at source rather than in anybody's summary.
- ✗This result does not transfer to your estate. A lab is not an endpoint with its own policy, its own age and its own tuning. And nobody can tell you whether your product was among the four, because SensePost does not name them.
- ✗There is no CVE and no patch. This is not a product vulnerability: it is abuse of a normal Windows mechanism. Next Patch Tuesday brings nothing that fixes it.
Sources (verified on 29 September 2026): the test against four market-leading EDRs configured to detect, block and remediate, the mechanism over the command line, the environment block and lpReserved/ShellInfo, the detection recommendations (command-line entropy, the executable-permission-then-thread-context sequence, remote reading of the parameter structure) and the note on modexp's earlier, undated work pointed out by X-C3LL — SensePost, "Process Parameter Poisoning", 6 July 2026, Max Hirschberger and Ogulcan Ugur; the test against a commonly-used open source EDR platform, the XDR component blocking on process creation and COM interactions, the result after adding DLL unhooking and a non-Microsoft block DLL policy, the sentence about rules that depend on thread suspension and resumption, the four detection avenues with their MITRE ATT&CK techniques (T1564.010, T1055.003, T1055) and the warning about multiple opportunities for detection — Flashpoint, "Process Parameter Poisoning: Inside a Novel EDR Evasion Technique", 22 September 2026.
How many days of telemetry does your console keep?
We look at which events your agent actually emits, how long they are kept, and who can query them at three in the morning on a Tuesday. If your setup already survives the four checks above, we tell you so and that is the end of it.
Talk to everyWAN
Microsoft 365
ES 
CAT 
EN