Microsoft is building a way for endpoint detection and response (EDR) products to run without their own kernel drivers, and the first pieces are already sitting in Windows Insider builds. Pavel Yosifovich of Elastic Security Labs has taken those binaries apart in a new analysis, and his headline finding is that the preview can tell a security product a process is starting, but shows no way yet for that product to stop it.
The project is called the Windows Endpoint Security Platform (WESP). It is undocumented, but Microsoft publishes symbols for its binaries, which let Yosifovich get a long way with a kernel debugger.
One Microsoft driver instead of one per vendor
Today a typical EDR product is two pieces: a kernel driver that registers for events such as process creation, registry changes and file writes, and a user-mode service that decides what to do about them. The kernel half is the risky half. A bad pointer in a kernel driver crashes the whole machine, which is what happened on July 19, 2024, when a faulty CrowdStrike configuration update took down what Elastic puts at 8.5 million machines, along with airports and banks.
WESP keeps a kernel driver, because something in the kernel still has to generate those events, but Microsoft writes it. Security vendors would connect from user mode through a client library. In Elastic's framing, that leaves one driver to test and debug properly instead of every vendor shipping its own.
What the preview binaries actually show
The platform is two files: wesp.sys in System32\Drivers and espclient.dll in System32. Yosifovich's findings:
- wesp.sys is a file system mini-filter, registered at altitude 329500 (the filter manager uses altitude to decide which filter sees an operation first). In the fltmc listing he captured it sits just above the WdFilter entry at 328010.
- The driver exposes no device objects and no dispatch handlers of its own, so the classic DeviceIoControl channel is off the table. Instead it creates a filter communication port, visible in the object manager as ESPFilterPort.
- espclient.dll exports a C-style API of functions prefixed Esp, including rules and filters. That fits the expectation that noisy events will be filtered inside the driver rather than shipped wholesale to user mode.
The missing reply call
The detail that matters most is an absence. espclient.dll imports three functions from FltLib.dll: FilterConnectCommunicationPort, FilterGetMessage and FilterSendMessage. It does not import FilterReplyMessage, the call a user-mode client would use to answer the driver directly.
Yosifovich reads that as one-way communication, and concludes that letting a user-mode service inspect a new process and reply "block it" is "probably not implemented, at least not yet". That matters because vetoing an operation, such as refusing a malicious process launch, is precisely the power EDR products get today from kernel callbacks like PsSetCreateProcessNotifyRoutineEx, and it is not available to ordinary user-mode code. He also expects WESP clients will need to run elevated and likely as Microsoft-signed Protected Process Light services, as most EDR services already do.
Nothing to patch, but vendors should watch the reply path
This is a preview of an unfinished platform, not a flaw, and there is nothing for defenders to deploy today. Security teams evaluating their EDR roadmap should track two things as WESP matures: whether Microsoft adds a blocking path for process creation and other preventable operations, and how much filtering the driver supports before events reach user mode. Elastic says its own Elastic Defend product is preparing to support WESP.
Moving vendors out of the kernel also changes the attacker's picture. Recent intrusions such as the one where ShinyHunters brought a CrowdStrike off-switch show how much effort goes into silencing EDR today. A single Microsoft-owned driver could make crashes rarer, but it will also become the one component every security product depends on, and the one every evasion technique will study first.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.