Skip to content

Response, New York. Noah Park: Check Point Patches Actively Exploited Management Server Path Traversal. Detection, Dallas. Ava Okello: Report Finds Nearly Half of Deployed Detections Need Attention Before SOCs Can Trust Them.

SOCtember

Always First. Fast SOC News.

Elastic Security Labs diagram of how endpoint detection and response software works today: user processes sit above a user-mode service, a red line marks the boundary between user mode and kernel mode, and below it the Windows executive and kernel connect to the security vendor's own kernel driver.
Diagram: Elastic Security Labs, "Kernel eviction notice: What wesp.sys reveals about the Windows Endpoint Security Platform," Oct. 26, 2026 (fair use). Today's EDR model: a vendor kernel driver feeding a user-mode service.

Tools

Elastic Looks Inside wesp.sys, Microsoft's Driver for Moving EDR Out of the Windows Kernel, and Finds No Sign Yet That Security Tools Using It Can Stop a Process From Starting

Preview binaries in Windows Insider builds show a Microsoft-built file system mini-filter that passes events to a user-mode client library, espclient.dll. That library imports no function for replying to the driver, which suggests the channel is one-way for now and a security product cannot yet veto what it sees.

James Whitford, ToolsAustin5 min read

AUSTIN - For years, endpoint security products have earned their power by running code inside the Windows kernel, where they can see a process being created and stop it. Microsoft wants most of that code out. The first pieces of its replacement are already sitting in preview builds of Windows, and Elastic has taken a look inside.

Elastic Security Labs published an analysis on Monday of the Windows Endpoint Security Platform, or WESP, Microsoft's framework for running EDR products outside the kernel. Two of its binaries ship in Windows Insider builds: a kernel driver, wesp.sys, and a user-mode API library, espclient.dll. The platform is undocumented, but Microsoft's public symbol server carries symbols for both files, which let Pavel Yosifovich, the Elastic researcher who wrote the analysis, get a long way with a kernel debugger.

The motive is reliability. Elastic ties the effort directly to July 19, 2024, when a bad configuration update made CrowdStrike's kernel driver crash 8.5 million machines. Under WESP, Microsoft would maintain a single kernel driver in place of the one every security vendor now ships, so there is one driver to test and debug instead of one per vendor.

What wesp.sys turned out to be

The driver lives in System32\Drivers under the name wesp. Elastic found that it registers no dispatch routines of its own; every major function points to the kernel's default handler, IopInvalidDeviceRequest, and it creates no device objects. That rules out the classic way a user-mode program talks to a driver, opening a device and sending it control codes. The driver object sits in the \FileSystem directory, and the registry marks it as a file-system driver.

Screenshot of Windows Registry Editor open to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\wesp, showing values including DependOnService FltMgr, Group FSFilter Anti-Virus, ImagePath system32\drivers\wesp.sys and Type 2.
Screenshot: Elastic Security Labs, "Kernel eviction notice," Oct. 26, 2026 (fair use).The wesp service key, registered as a file-system driver that depends on the Filter Manager.

Its imports confirm the picture. wesp.sys depends on FltMgr.sys, the Windows Filter Manager, which makes it a file system mini-filter. Running the built-in fltmc tool lists it at altitude 329500, just above WdFilter at 328010. A mini-filter's altitude decides the order in which it sees file operations, and higher filters see them first.

Screenshot of the Total PE tool showing the imports of wesp.sys, with modules FLTMGR.SYS, ntoskrnl.exe and a third library, and a list of imported kernel functions that includes process, thread and image-load notification routines.
Screenshot: Elastic Security Labs, "Kernel eviction notice," Oct. 26, 2026 (fair use).wesp.sys imports from the Filter Manager and kernel notification routines.

Mini-filters have their own channel to user mode, the filter communication port, and wesp.sys imports FltCreateCommunicationPort to open one. In the Windows object manager, Elastic found a port named ESPFilterPort in the root directory.

Screenshot of Sysinternals WinObj showing the Windows object manager root directory, with EspFilterPort listed as a FilterConnectionPort alongside other filter ports.
Screenshot: Elastic Security Labs, "Kernel eviction notice," Oct. 26, 2026 (fair use).The ESPFilterPort that user-mode clients connect to.

The missing reply

On the other side, espclient.dll in System32 exports a long list of functions that start with Esp, among them functions for rules and filters. Elastic reads that as confirmation that events can be filtered at the source, inside the driver, before they are sent to user mode. The API is plain C, not COM.

The library imports three functions from FltLib.dll: FilterConnectCommunicationPort, FilterGetMessage and FilterSendMessage. What it does not import is FilterReplyMessage, the call a user-mode program uses to answer a message from the driver. Elastic's conclusion is that the channel is one-way for now. A security service built on the current preview can be told that a process is starting, but it apparently cannot run its own checks and reply with a decision to block it. Elastic says that capability is probably not implemented, "at least not yet."

That matters because blocking is the power that today's EDR products get from the kernel. A kernel driver registered for process creation can fail the operation, for example after inspecting a malicious command line. Plain user-mode code can be notified that a process was created but cannot veto it.

What vendors and SOC teams should watch

Elastic sets out what the platform will need before EDR vendors can rely on it. It has to cover the event types products now gather through separate kernel mechanisms: process, thread, image and handle callbacks, registry callbacks, file system mini-filters and network filtering through the Windows Filtering Platform. It needs flexible filtering in the driver, because registry and file reads arrive in enormous volume. It needs a way for user-mode clients to block operations. And clients will likely have to run elevated, probably as Microsoft-signed Protected Process Light services, as most EDR services already do.

Elastic says Elastic Defend, its endpoint product, is preparing to support WESP. The platform is not broadly available or documented, and Elastic gives no date for its general release.

For SOC teams the practical point is timing. Prevention that depends on blocking a process at launch still comes from vendor kernel drivers, and the preview shows no replacement for it yet. When endpoint vendors begin moving to WESP, teams will want to know which of their detections and blocking rules depend on kernel callbacks, and to test them again on the new platform rather than assume they behave the same.

Sources:


James Whitford covers SOC tooling, SIEM, SOAR, and detection platforms for SOCtember from Austin.

Related stories

Tools desk