ASHES-2025-001: Elastic Endpoint Kernel Driver 0-Day

Summary

AshES Cybersecurity has identified a kernel-level vulnerability in Elastic's Endpoint Detection and Response (EDR) driver elastic-endpoint-driver.sys. Under specific conditions, user-influenced data can cause an invalid or uninitialized pointer to be passed into a kernel free routine, resulting in a reliable Blue Screen of Death (BSOD) and persistent endpoint denial of service.

The vulnerable driver is Microsoft-signed and ships as part of Elastic Defend / Elastic Agent. In our research lab, this flaw was used as part of a four-stage attack chain:

• EDR bypass
• Low-Privelege Remote code execution (RCE) under reduced visibility
• Persistence via a cooperating kernel driver
• Privileged, repeatable denial of service (BSOD on demand)

This advisory documents the driver-level vulnerability and impact on system stability. The end-to-end attack chain and exploitation context are described in detail in our blog posts:

• Elastic EDR 0-day: Part 1 – Breaking a Microsoft-Signed EDR Driver
• Elastic EDR 0-day: Part 2 – Technical Details and the Trigger

Technical Description

The vulnerability resides in the driver's handling of a memory-related enforcement path inside elastic-endpoint-driver.sys. When a specific internal code path is reached, a pointer derived from earlier logic is eventually passed into the Windows pool allocator without being validated for NULL or correctness.

In the function we refer to as sub_140012560 (name based on disassembly), the crash occurs at an offset where the driver executes:

mov edx, 52534E53h ; Tag
mov rcx, r15 ; P
call cs:ExFreePoolWithTag

In the vulnerable path, r15 may hold a NULL, invalid or otherwise corrupted pointer. In our testing, this pointer could be influenced from user-mode activity inside an Oracle VirtualBox virtual machine, as described in Part 2 of the blog series. When this bad pointer is freed, Windows detects the problem and halts the system with a BSOD that references elastic-endpoint-driver.sys as the faulting module.

In practice, this produces an immediate crash. In our lab, we were able to repeatedly trigger the crash from a custom kernel driver that synchronizes with the vulnerable offset (for example, via a mutex operation reaching the same code path), and in some scenarios, the affected host would repeatedly crash on boot until Elastic's driver was disabled or removed.

Vulnerability Characteristics

Impact

On affected systems, successful triggering of the vulnerable path allows a local process or malware (via a cooperating driver) to:

• Crash Windows on demand via the Elastic endpoint driver
• Cause repeated BSODs during boot until the driver is removed or disabled
• Disrupt Elastic's EDR visibility and protection on that endpoint
• Potentially combine this with additional steps (described in Part 1 & 2) to bypass detection, run code with reduced EDR visibility, and maintain persistence

While the underlying bug is a kernel stability flaw (not a classic arbitrary code execution primitive by itself), the fact that it exists in a widely-deployed, Microsoft-signed security driver makes it operationally severe in real environments.

Exploitation Requirements

In our research environment, triggering the bug required:

• Local code execution on the target endpoint (initially at low privilege after EDR bypass, as shown in Part 1)
• A cooperating kernel driver under attacker control, which was loaded once from an administrator context to reach the vulnerable code path and pass the pointer in r15 into ExFreePoolWithTag
• After this setup step, no further manual administrator interaction was required to repeatedly trigger crashes from the lab environment

The blog series shows how this primitive was integrated into a broader 4-step chain (EDR bypass → low-privilege RCE → persistence → DoS) to demonstrate real-world impact inside a lab network.

Affected Versions

Based on our testing and third-party reporting, the vulnerable logic is present in the Elastic endpoint driver version shipped around mid-2025 (for example, builds corresponding to Elastic Defend / Elastic Agent 8.17.x), and no public patch had been identified at the time of writing.

Organizations can verify the presence of the driver at:

C:\Windows\System32\drivers\elastic-endpoint-driver.sys

Mitigations and Workarounds

Until Elastic ships an official fix, organizations concerned about this issue can:

• Restrict driver interface exposure — Ensure only trusted, Elastic-controlled processes and trusted kernel components can influence the driver's internal enforcement paths.
• Harden local privilege boundaries — Limit which users and services can load additional kernel drivers or interact with EDR components.
• Monitor for BSOD patterns — Watch for repeated crashes that reference elastic-endpoint-driver.sys as a possible indicator of driver instability or exploitation attempts.
• Plan for emergency disablement — In cases of persistent crash loops, be prepared to safely disable the driver on affected endpoints while maintaining layered defenses.

Timeline

Internal Research Timeline (AshES Lab)

Public & Disclosure Timeline

Credits

Researcher: Pradheesh S
Organization: AshES Cybersecurity Pvt. Ltd.
Role: Founder & Lead Researcher

Limitations of the PoC

The proof-of-concept referenced in the blog series is an internal lab demonstration and is not publicly released. The PoC uses a cooperating kernel driver that is loaded once from an administrator context to reach the vulnerable code path inside elastic-endpoint-driver.sys. This setup step is not part of the vulnerability itself.

The vulnerability originates from a pointer influenced by low-privilege user-mode memory being passed into ExFreePoolWithTag without validation. This advisory does not claim a standalone low-privilege to kernel privilege escalation exploit chain.

References

• Elastic EDR 0-day: Part 1 – Breaking a Microsoft-Signed EDR Driver
• Elastic EDR 0-day: Part 2 – Technical Details and the Trigger
• Independent coverage by multiple security news outlets referencing AshES Cybersecurity's research.

Contact

For verification, coordination, or further technical discussion regarding ASHES-2025-001:

Email: security@ashes-cybersecurity.com
Website: https://ashes-cybersecurity.com