- Elastic Security Labs says Microsoft's preview endpoint platform reports process starts to a user-mode client, but its client library appears to lack a way to reply with a block decision.
- Blocking process creation is a power only the kernel has. If the platform cannot pass it on, security vendors may keep their own kernel drivers.
- Ask your security vendor which functions will move to Microsoft's platform, and whether blocking will be among them.
Moving risk out of the Windows kernel is not the same as moving power out of it. Microsoft is building a platform to take security software out of the part of Windows where one fault can halt a whole machine. Elastic Security Labs examined the early files. Its summary says the preview driver reports process starts to a user-mode client. The researcher found no sign in the imports that the client can stop that program.
What Microsoft is building
Elastic reports that the Windows Endpoint Security Platform, or WESP, is in early Windows Insider builds. Two binaries are visible. One is a kernel driver, wesp.sys. The other is a user-mode library, espclient.dll, that a security product's service would call.
The motive is the July 19, 2024 CrowdStrike incident. Elastic says a bad update to that vendor's kernel driver crashed 8.5 million machines. Today every endpoint detection and response (EDR) vendor ships its own kernel driver. Microsoft wants one driver it maintains itself, so there is only one to test and debug.
Elastic notes that WESP is not publicly documented. Its analysis comes from the binaries and Microsoft's public symbols, and it may change.
How the design works
A typical EDR product has two halves. A kernel driver registers for events such as a process starting or a file being written. It passes them to a service running in ordinary user mode. That service can send data to a server, check rules that may block the action, or ask the user.
The kernel half matters because a mistake there can stop the machine. A coding error in a driver halts Windows, and a restart is the only way back. WESP keeps a kernel driver, but it is Microsoft's, and vendors would stop writing their own.
The researcher worked out the driver's type from several clues. It depends on FltMgr.Sys, the Windows Filter Manager, and it appears in the built-in fltmc tool. That makes it a file system mini-filter, a driver type that plugs into the file system stack. Elastic lists its altitude, its place in that stack, as 329500. The driver creates no device objects, so the usual driver call, DeviceIoControl, is not available. It talks to user mode through a communication port named ESPFilterPort. The client library exports many functions starting with Esp, including ones for rules and filters. That fits the need to drop noisy events, such as constant registry and file reads, at the source rather than flood the user-mode service.
The missing reply
Blocking is the hard part. Elastic explains that only certain kernel notifications let a driver stop an action. Process creation is the classic case. A driver using PsSetCreateProcessNotifyRoutineEx can set a failure status while the process is being created. In user mode you can be told a process started, but you cannot veto it.
Elastic says WESP's clients must be given that power. Ideally the user-mode service could run custom code, then reply to the driver with allow or block.
The researcher found no sign of it. espclient.dll imports three functions for the communication port: FilterConnectCommunicationPort, FilterGetMessage and FilterSendMessage. It does not import FilterReplyMessage, which lets a client answer a message directly. Elastic concludes that communication looks one-way. A user-mode decision to block process creation is, in its words, "probably not implemented, at least not yet."
This is an inference from imports in a preview build. It is not a statement of Microsoft's plans.
Why this matters beyond the engineering
If the preview's design holds, a tool that sees but cannot stop is a detection product, not a prevention product. That is the lesson here. The difference shapes what your security team can promise after an incident.
Elastic is plain about the adoption risk. If features EDR products need are missing, it says, adoption and migration will be "partial at best." Vendors would then keep kernel drivers with less code in them. The kernel-fault risk would shrink without disappearing.
Elastic is also not a neutral party. It says Elastic Defend is preparing to support WESP. Its post also carries the usual disclaimer that Elastic's own unreleased features may not ship on time or at all.
Questions to put to your security vendor
Nothing here calls for changing a deployment today. These are Insider-build findings. They do give leaders four concrete questions.
First, does the vendor plan to adopt WESP, and which functions would stay in its own kernel driver? Second, will blocking a process from starting work through WESP, or only alerting? Third, what does the vendor say about Elastic's inference, from the imports, that the client library has no way to reply to the driver? Fourth, is the vendor's service ready to run as a Protected Process Light, which Elastic says WESP clients will likely need?
Microsoft can remove vendor code from the kernel. The test of the new platform is whether the power to say no moves out with it.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Elastic Security Labs.
