Elastic EDR 0-day: Part 2 – Technical Details and the Trigger
The Vulnerability and its Trigger:
When I was working on Process Injection bypass techniques for SIEM Detection Rules, I was experimenting with in-memory compilation using libtcc.dll combined with NtMapViewOfSection inside an Oracle VirtualBox VM; Some of my other approaches included testing Syscall based injection, reflective code loading, VirtualAllocEx usage etc. By this time I was already able to consistently bypass Elastic’s EDR, from a low privileged compiled executable (by padding ~250MB of NULL Bytes) to conduct my testing unhindered.
During the course of my testing, I encountered multiple crashes (BSODs) on reboot on my host system (both VM and host are Elastic protected). I initially attributed these to some random hardware error on my laptop, but I decided to investigate the crashes after a 3rd BSOD, realising that all my work is at stake.
Analyzing the crash dumps revealed that it was actually Elastic’s EDR driver which was crashing my host system on reboots. elastic-endpoint-driver.sys was crashing at the offset 0x120DD, which contained the instruction: call cs:ExFreePoolWithTag. A pointer (r15) was being sent into this kernel function, when it was referencing invalid memory, which was causing the crash.
Looking at the crashing function and functions around it revealed that it was related to my Process Injection bypass testing (analyze the crashing function and trace the flow into r15). This occurred when Elastic’s EDR was attempting to block my Process Injection bypass attempts. The pointer on the host machine could be controlled using user mode input inside an Oracle VirtualBox Virtual Machine.
The PoC:
For impact an attacker could manipulate it to reference attacker-controlled memory. This opens the door not only for persistent endpoint denial of service but also the possibility of turning it into a local privilege escalation (LPE) or even a stepping stone for remote code execution (RCE) in chained scenarios.
Naturally, this is an edge case scenario, Process Injection inside a VM is unlikely to occur in day-to-day Corporate/Enterprise scenarios. I am not a Red Teamer, my goal now was to prove that this could be exploited in real-world scenarios, not build the most impactful PoC/exploit. I decided to write a custom driver (with no inherent malicious behaviour) to interact with the vulnerable driver. The driver makes an ExAcquireFastMutex call to the vulnerable offset, resulting in Elastic’s Endpoint Driver crashing the host system. I chained it with the EDR Bypass I had earlier to load the driver using bash commands, make it persist using the Windows Registry and start on every boot. None of these actions were blocked by Elastic’s EDR, though Elastic’s SIEM generated ~4 alerts but the affected host was no longer usable for remediation actions due to recurring persistent BSOD. Note that I ran the executable as administrator here since I didn’t have a Local Privilege Escalation Exploit.
Misc: Between my first post on Aug 16th, 2025 and now, all PoCs and full technical details of the flaw have already been shared with Elastic’s Security Team. Elastic has pushed out 1 update during this time (9.1.3); While I don’t think the 0-day is patched yet, there is a high chance that they have silently pushed a patch for the EDR Bypass without revealing it on their security release notes page (though I could be wrong here). (Elastic Security release notes | Elastic Docs)
Final Coordination attempts with Elastic’s Security Team were ineffective and inconclusive. Their final stance was that, the flaw I’m disclosing had already been patched on April 29th, 2025 https://www.elastic.co/guide/en/security/8.19/release-notes-header-8.17.0.html#bug-fixes-8.17.6
Avoids an IRQL_NOT_LESS_EQUAL bugcheck in the Elastic Defend driver due to an interaction with Trellix Access Protection (mfehidk.sys). This issue can occur when elastic-endpoint-driver.sys calls FwpmTransactionBegin0 to initialize its network driver. FwpmTransactionBegin0 performs a synchronous RPC call to the user-mode Base Filtering Engine service.
Source: Elastic response to blog ‘EDR 0-Day Vulnerability’ | Elastic Blog
However, this bug they previously patched has nothing to do with the Process Injection triggered flaw that I’m trying to disclose, I don’t have any Trellix software on my system (these are 2 different things). They claimed that my PoC driver has a bug, which is incorrect and also irrelevant;
I had also already made it clear to Elastic, that I wasn’t looking for a bounty for any of my deliverables (their Behaviour Rule bounty program my Process Injection Bypass research was targeting, has ‘0 resolved reports’), I was only looking at Elastic to acknowledge the flaw, patch it, formally disclose and credit the researcher, however they refused.
Interestingly, Elastic is also a CNA (CVE Numbering Authority), but it is edge cases like these, or new classes of flaws which ultimately reveal how effective these security companies’ responses are (because they don’t have predefined playbooks for new scenarios). I am only researching and disclosing, Elastic chose to attack the messenger instead of addressing the flaw; they seem to be more focused on controlling the narrative.
An offer to co-ordinate with a 3rd party was rejected, because Elastic decided to choose the 3rd party on their own and call it ‘neutral’.
Closing Statements:
I will include 3 crash dumps with this post, the PoC is not being shared publicly, but it has been privately shared with the vendor.
Elastic claimed to be the best EDR and also claimed 100% malware coverage in a recent blog post, though I had already informed them of EDR bypasses before.
https://www.elastic.co/blog/elastic-security-av-comparatives-business-security-test-2025
During this entire ordeal nothing illegal was performed, no security boundaries were breached, nothing unethical was done. Elastic has already been informed that this article was going to be published on August 29th, 2025 (in fact this date was chosen by them).
Please stay tuned for a possible non-technical Part 3, where I will go through the rationale behind my decision-making process detailing why I decided to go for these disclosure steps and a brief overview on how everything started with Elastic.
Disclaimer: Ashes Cybersecurity is committed to responsible disclosure and is sharing this information in good faith to raise awareness of a flaw that the vendor has chosen not to acknowledge. Any collateral impact resulting from the vendor’s decision to not address this issue remains their responsibility.