📰 Source : Elastic Security Labs | Date : 26 octobre 2026 | Auteur : Pavel Yosifovich

Suite à l’incident CrowdStrike du 19 juillet 2024, où une mise à jour défectueuse d’un fichier de configuration a provoqué le crash de 8,5 millions de machines Windows (BSOD), Microsoft a lancé une initiative pour déplacer les produits EDR hors du noyau Windows. Ce framework s’appelle la Windows Endpoint Security Platform (WESP).

🔍 Composants identifiés dans les builds Windows Insider :

  • wesp.sys : driver noyau développé par Microsoft, mini-filtre système de fichiers à l’altitude 329500, communiquant avec l’espace utilisateur via un port de communication de filtre nommé ESPFilterPort
  • espclient.dll : DLL d’API en espace utilisateur exposant des fonctions préfixées Esp, destinée aux services EDR

⚙️ Architecture technique :

  • wesp.sys est enregistré comme mini-filtre (\FileSystem\wesp) et dépend de FltMgr.sys
  • La communication kernel/usermode s’effectue via FltCreateCommunicationPort (côté kernel) et FilterConnectCommunicationPort, FilterGetMessage, FilterSendMessage (côté client)
  • Aucun objet device n’est exposé, rendant DeviceIoControl inutilisable
  • Les imports de wesp.sys incluent des fonctions de notification noyau : PsSetCreateProcessNotifyRoutineEx, PsSetCreateThreadNotifyRoutine, PsSetLoadImageNotifyRoutine, CmRegisterCallback

⚠️ Limitation critique identifiée :

  • La fonction FilterReplyMessage est absente des imports de espclient.dll, ce qui implique que le client en espace utilisateur ne peut pas répondre au driver avec une décision de blocage
  • En conséquence, le blocage de création de processus depuis l’espace utilisateur n’est pas possible dans l’état actuel des binaires analysés
  • Cette capacité (veto sur la création de processus via PsSetCreateProcessNotifyRoutineEx) est pourtant essentielle pour les EDR

📋 Attentes des éditeurs EDR vis-à-vis de WESP :

  • Couverture complète : processus, threads, images, handles, registre, système de fichiers, réseau (WFP)
  • Capacités de filtrage à la source pour réduire le bruit
  • Possibilité de bloquer des opérations depuis l’espace utilisateur
  • Support des processus protégés (PPL - Protected Process Light)

🗂️ Type d’article : Analyse technique de reverse engineering de binaires système Windows non documentés, visant à évaluer les capacités actuelles et les lacunes du framework WESP pour la communauté EDR.

🧠 TTPs et IOCs détectés

IOC

  • Fichiers : wesp.sys
  • Fichiers : espclient.dll
  • Chemins : System32\Drivers\wesp.sys
  • Chemins : System32\espclient.dll

⚠️ À propos de ces IOC — ils sont extraits automatiquement de l’article original le 27 octobre 2026 et n’ont pas fait l’objet d’une vérification externe. Un indicateur peut avoir été réattribué depuis : une IP de C2 peut redevenir un service légitime, un domaine sinkholé peut changer de propriétaire. Aucune garantie d’exactitude ni d’actualité — contrôlez leur validité avant tout usage opérationnel, en particulier avant de les injecter dans une blocklist ou un SIEM.

🟡 Indice de vérification factuelle : 55/100 (moyenne)

  • ✅ elastic.co — source reconnue (liste interne) (20pts)
  • ✅ 15000 chars — texte complet (fulltext extrait) (15pts)
  • ✅ 4 IOCs (IPs/domaines/CVEs) (10pts)
  • ⬜ pas d’IOC vérifié (0pts)
  • ⬜ aucune TTP identifiée (0pts)
  • ✅ date extraite du HTML source (10pts)
  • ⬜ aucun acteur de menace nommé (0pts)
  • ⬜ pas de CVE à vérifier (0pts)

🔗 Source originale : https://www.elastic.co/security-labs/blog/windows-endpoint-security-platform-wesp