EN PT-BR
← Voltar ao feed
low

Microsoft's Windows Endpoint Security Platform: wesp.sys mini-filter driver analysis shows no user-mode block capability yet

1 fonte(s) · 1 atualização(ões) · publicado 25/10/2026 21:00 · coletado há 6 dias

Elastic Security Labs analyzed the Windows Endpoint Security Platform (WESP), Microsoft's undocumented framework for moving EDR products out of the Windows kernel, whose binaries already ship in Windows Insider builds. The initiative follows the July 19, 2024 CrowdStrike update that crashed about 8.5 million machines. The platform consists of the Microsoft-maintained kernel driver wesp.sys and the user-mode API espclient.dll. Static and kernel-debugger analysis suggests user-mode clients can currently receive notifications but cannot reply to the driver, so they probably cannot veto process creation yet. Elastic Defend is preparing to support WESP. This is platform research, not a threat or vulnerability.

Detalhes técnicos

  • wesp.sys is a file system mini-filter (Type 2, depends on FltMgr.sys) at altitude 329500, loaded from System32\Drivers. It sits above WdFilter (328010) in fltmc output.
  • The driver object lives in \FileSystem\wesp, has no device objects, and every IRP major function points to nt!IopInvalidDeviceRequest, so DeviceIoControl is not used.
  • Communication runs over a filter communication port, ESPFilterPort, created with FltCreateCommunicationPort.
  • espclient.dll exports many Esp* functions, including rules and filters for dropping events at the source. The API is C-based, not COM.
  • It imports FltLib.dll and uses FilterConnectCommunicationPort, FilterGetMessage and FilterSendMessage, but not FilterReplyMessage. The author infers that communication is one-way and that blocking decisions such as vetoing process creation (the capability of PsSetCreateProcessNotifyRoutineEx) are probably not implemented yet.
  • Clients must run elevated and will likely need to run as Protected Processes Light (PPL).
  • Symbols are available from the Microsoft public symbol server.

Remediação

No defensive action is required. EDR vendors should track WESP development, and the author expects Microsoft to add the missing capabilities (comprehensive notifications, source-side filtering, blocking) over time.

Linha do tempo

  1. elastic.co ↗ · pub. 25/10/2026 21:00 · coletado 26/10 14:01 primeiro registro

    Microsoft's Windows Endpoint Security Platform: wesp.sys mini-filter driver analysis shows no user-mode block capability yet

    ler a análise desta fonte

    Elastic Security Labs analyzed the Windows Endpoint Security Platform (WESP), Microsoft's undocumented framework for moving EDR products out of the Windows kernel, whose binaries already ship in Windows Insider builds. The initiative follows the July 19, 2024 CrowdStrike update that crashed about 8.5 million machines. The platform consists of the Microsoft-maintained kernel driver wesp.sys and the user-mode API espclient.dll. Static and kernel-debugger analysis suggests user-mode clients can currently receive notifications but cannot reply to the driver, so they probably cannot veto process creation yet. Elastic Defend is preparing to support WESP. This is platform research, not a threat or vulnerability.

    Technical Details

    • wesp.sys is a file system mini-filter (Type 2, depends on FltMgr.sys) at altitude 329500, loaded from System32\Drivers. It sits above WdFilter (328010) in fltmc output.
    • The driver object lives in \FileSystem\wesp, has no device objects, and every IRP major function points to nt!IopInvalidDeviceRequest, so DeviceIoControl is not used.
    • Communication runs over a filter communication port, ESPFilterPort, created with FltCreateCommunicationPort.
    • espclient.dll exports many Esp* functions, including rules and filters for dropping events at the source. The API is C-based, not COM.
    • It imports FltLib.dll and uses FilterConnectCommunicationPort, FilterGetMessage and FilterSendMessage, but not FilterReplyMessage. The author infers that communication is one-way and that blocking decisions such as vetoing process creation (the capability of PsSetCreateProcessNotifyRoutineEx) are probably not implemented yet.
    • Clients must run elevated and will likely need to run as Protected Processes Light (PPL).
    • Symbols are available from the Microsoft public symbol server.

    Remediation

    No defensive action is required. EDR vendors should track WESP development, and the author expects Microsoft to add the missing capabilities (comprehensive notifications, source-side filtering, blocking) over time.