Les antivirus traditionnels sont aujourd’hui confrontés à des techniques d’évasion de plus en plus efficaces. Obfuscation de payloads, chiffrement de shellcodes ou encore utilisation d’outils légitimes du système (LOLBins) : les attaquants disposent de nombreuses méthodes pour contourner les mécanismes de détection statiques.
Face à cette évolution des menaces, les solutions Endpoint Detection and Response (EDR) se sont imposées comme un composant essentiel. Leur capacité à surveiller l’activité d’un système en temps réel leur permet de détecter des comportements suspects bien au-delà des simples signatures de malwares.
Mais comment un EDR parvient-il à observer ce qu’il se passe sur une machine Windows ? Quels mécanismes lui permettent de détecter une injection de code, une tentative de vol d’identifiants ou l’exécution d’un shellcode en mémoire ? Pour répondre à ces questions, nous allons explorer l’architecture interne des EDR et les différentes sources de télémétrie sur lesquelles ils s’appuient pour identifier les activités malveillantes.
Un EDR (Endpoint Detection and Response) est une solution de sécurité conçue pour surveiller en continu l’activité des terminaux d’un système d’information. Contrairement aux antivirus traditionnels qui reposent principalement sur la détection de signatures connues, les EDR adoptent une approche comportementale. Leur objectif n’est plus uniquement d’identifier un fichier malveillant, mais de détecter les actions suspectes réalisées sur une machine afin d’identifier une compromission, même lorsqu’aucun malware connu n’est présent sur le disque.
Cette évolution est devenue nécessaire face aux techniques modernes utilisées par les attaquants. Les payloads sont fréquemment chiffrées ou obfusquées, les outils légitimes de Windows sont détournés à des fins malveillantes (LOLBins) et de nombreuses attaques s’exécutent exclusivement en mémoire afin de limiter les traces laissées sur le système. Dans ce contexte, la simple analyse de fichiers ne suffit plus. Les EDR collectent alors une grande quantité de télémétrie provenant du système d’exploitation afin d’observer ce que font réellement les processus au moment de leur exécution.
Concrètement, un EDR est capable de surveiller la création de processus et de threads, les chargements de bibliothèques en mémoire, les accès aux processus sensibles, les modifications du registre Windows, les connexions réseau ou encore les interactions entre applications. Ces événements sont ensuite corrélés afin d’identifier des comportements caractéristiques d’une attaque, comme une injection de code, une tentative d’extraction d’identifiants depuis LSASS, un mouvement latéral ou l’établissement d’un canal de commande et de contrôle (C2).
Au-delà de la détection, les EDR intègrent également des capacités de réponse permettant de limiter l’impact d’une compromission. Selon la solution déployée, il est par exemple possible d’isoler une machine du réseau, de suspendre ou terminer un processus malveillant, de mettre un fichier en quarantaine ou encore de fournir un historique détaillé des événements ayant conduit à un incident.
Un agent EDR moderne ne se résume pas à un simple exécutable. Il est divisé en deux composants majeurs qui communiquent en permanence : un en mode utilisateur (user-mode) et un en mode noyau (kernel-mode).
Le composant user-mode constitue la première couche d’observation de l’EDR. Il prend généralement la forme d’une DLL injectée dans une grande partie des processus exécutés sur le système. Son objectif principal est de surveiller les interactions entre les applications et le système d’exploitation en interceptant certains appels sensibles.
Pour cela, les EDR s’appuient fréquemment sur des techniques d’API hooking. Les fonctions critiques de Windows, souvent au niveau de « ntdll.dll », sont détournées afin que l’EDR puisse inspecter les arguments transmis avant que l’appel système ne soit envoyé au noyau. Cette visibilité permet notamment d’observer des opérations telles que l’allocation de mémoire, l’écriture dans un processus distant ou le chargement de bibliothèques dynamiques.
En parallèle, un service exécuté en arrière-plan centralise la télémétrie collectée, l’envoie à la console d’administration et applique les éventuelles mesures de remédiation. Selon la politique définie, il peut par exemple générer une alerte, suspendre ou terminer un processus, mettre un fichier en quarantaine ou isoler la machine du réseau.
Le composant kernel-mode constitue le cœur du mécanisme de surveillance d’un EDR. Exécuté sous la forme d’un driver noyau avec les privilèges les plus élevés du système (Ring 0), il bénéficie d’une visibilité privilégiée sur les événements critiques du système d’exploitation.
Contrairement au composant user-mode, qui observe principalement les interactions au niveau des processus, le driver noyau peut s’abonner directement aux mécanismes de notification fournis par Windows. Il est ainsi informé de la création de processus et de threads, du chargement d’images en mémoire, des accès aux objets sensibles ou encore des opérations réalisées sur le système de fichiers et le registre.
Cette position privilégiée permet à l’EDR de collecter une télémétrie plus fiable et plus difficile à contourner que les simples hooks userland. C’est notamment grâce à ce composant que les solutions EDR peuvent détecter des comportements suspects même lorsqu’un attaquant tente de contourner les mécanismes de surveillance présents dans l’espace utilisateur.
Le noyau Windows met à disposition des drivers un mécanisme de notification appelé callbacks. Ces points d’ancrage permettent à un composant exécuté en mode noyau, comme le driver d’un EDR, d’être automatiquement informé lorsqu’un événement système spécifique se produit.
En s’enregistrant auprès de ces mécanismes, un EDR peut observer en temps réel de nombreuses activités critiques du système d’exploitation, telles que la création de processus, le chargement d’images en mémoire, les accès à des objets sensibles ou encore les modifications du registre Windows.
Il existe plusieurs types de callbacks, chacun étant dédié à une catégorie particulière d’événements. Ensemble, ils constituent l’une des principales sources de télémétrie exploitées par les EDR modernes pour détecter les comportements malveillants.
Ces callbacks notifient le driver EDR à chaque création ou terminaison de processus sur le système. Ils sont stockés dans le tableau noyau « nt!PspCreateProcessNotifyRoutine » et les drivers peuvent s’y enregistrer via les APIs :
PsSetCreateProcessNotifyRoutine »PsSetCreateProcessNotifyRoutineEx »PsSetCreateProcessNotifyRoutineEx2 »Lorsqu’un processus est créé depuis l’espace utilisateur (par exemple via « NtCreateUserProcess » ou « NtCreateProcessEx »), le noyau appelle la fonction « PspCallProcessNotifyRoutines », qui parcourt l’ensemble des callbacks enregistrés et les exécute.
Ce mécanisme permet à un EDR d’obtenir immédiatement des informations sur le nouveau processus : identifiant du processus, processus parent, chemin de l’exécutable, contexte de création ou encore arguments de lancement. Ces informations constituent une source de télémétrie essentielle pour détecter des comportements suspects, comme l’exécution d’un interpréteur de commandes depuis une application Office ou le lancement d’un processus enfant inattendu.
Les callbacks de création de processus sont également utilisés par certains EDR pour injecter leur composant user-mode dans les nouveaux processus qu’ils souhaitent surveiller, afin d’y mettre en place leurs mécanismes de hooking et de collecte de télémétrie.
Similaires aux callbacks de création de processus, ces routines sont notifiées à chaque création ou terminaison de thread sur le système. Elles sont stockées dans le tableau noyau « nt!PspCreateThreadNotifyRoutine » et sont enregistrées via les APIs « PsSetCreateThreadNotifyRoutine » et « PsSetCreateThreadNotifyRoutineEx ».
Alors que les Process Creation Callbacks permettent d’observer l’apparition de nouveaux processus, les Thread Creation Callbacks offrent une visibilité plus fine sur les activités se déroulant à l’intérieur de ceux-ci. Ils permettent notamment à l’EDR de surveiller la création de threads dans des processus sensibles ou de détecter des comportements anormaux impliquant plusieurs processus.
Cette télémétrie est particulièrement utile pour identifier certaines techniques d’injection de code. Par exemple, lorsqu’un processus crée un thread dans un autre processus via « NtCreateThreadEx », l’EDR peut être notifié de cet événement et le corréler avec d’autres actions suspectes, comme une allocation mémoire distante ou un appel à « WriteProcessMemory ». Ce type de séquence est fréquemment observé lors de l’injection de shellcode ou de l’exécution de charges utiles dans un processus légitime.
Ces callbacks sont déclenchés à chaque chargement d’une image PE en mémoire, qu’il s’agisse d’un exécutable (.exe), d’une bibliothèque dynamique (.dll) ou d’un driver (.sys). Ils sont stockés dans le tableau noyau « nt!PspLoadImageNotifyRoutine » et sont enregistrés via l’API « PsSetLoadImageNotifyRoutine ».
Lorsqu’une image est chargée par les mécanismes standards de Windows, par exemple via « LdrLoadDll » ou « NtMapViewOfSection », le noyau appelle « PsCallImageNotifyRoutines » afin de notifier l’ensemble des callbacks enregistrés.
Cette télémétrie permet à l’EDR d’obtenir des informations précieuses sur les modules chargés par les processus : chemin du fichier, adresse de chargement, type d’image ou encore contexte d’exécution. Les solutions EDR peuvent ainsi identifier le chargement de DLLs non signées, de bibliothèques provenant d’emplacements inhabituels ou de modules chargés dans des processus sensibles.
Les Image Load Callbacks constituent également une source de visibilité importante pour détecter certaines techniques d’évasion ou d’injection reposant sur le chargement de bibliothèques malveillantes. Ils sont souvent corrélés avec d’autres sources de télémétrie afin d’identifier des comportements suspects au sein des processus surveillés.
Ces callbacks permettent au driver EDR d’être notifié des opérations réalisées sur le registre Windows, qu’il s’agisse de lectures, d’écritures, de suppressions ou de requêtes. Les routines sont enregistrées via les APIs « CmRegisterCallback » ou « CmRegisterCallbackEx » et sont stockées dans une liste chaînée dont la tête est « nt!CallbackListHead ».
Les événements surveillés sont déclenchés par de nombreuses APIs du noyau, comme « NtOpenKeyEx », « NtCreateKey », « NtSetValueKey » ou encore « NtDeleteKey ». À chaque opération, le callback reçoit des informations sur la clé concernée et le processus à l’origine de l’action.
Cette télémétrie est particulièrement intéressante pour les EDR, car le registre Windows est fréquemment utilisé par les attaquants pour établir une persistance ou modifier la configuration du système. Les solutions de détection peuvent ainsi surveiller les modifications de clés sensibles telles que les emplacements « Run » et « RunOnce », les services Windows ou certains paramètres de sécurité du système.
En corrélant ces événements avec d’autres sources de télémétrie, l’EDR peut détecter des comportements suspects révélateurs d’une compromission ou d’une tentative de maintien d’accès sur la machine.
Ces callbacks permettent à l’EDR d’être notifié lorsqu’un processus tente d’ouvrir ou de dupliquer un handle vers un processus ou un thread. Ils sont stockés dans les listes « nt!PsProcessType->CallbackList » et « nt!PsThreadType->CallbackList » et sont enregistrés via l’API « ObRegisterCallbacks ».
Les notifications sont déclenchées lors d’opérations telles que « NtOpenProcess », « NtOpenThread » ou encore la duplication de handles. Avant que l’accès ne soit accordé, le noyau appelle les routines enregistrées via « ObpCallPreOperationCallbacks », offrant ainsi à l’EDR la possibilité d’observer, modifier ou bloquer l’opération.
Ce mécanisme est particulièrement important pour la protection des processus sensibles. Il permet par exemple de détecter ou d’empêcher les tentatives d’ouverture d’un handle vers « lsass.exe » avec des droits permettant la lecture de sa mémoire, une étape fréquemment observée lors des attaques visant à extraire des identifiants. Les Object Callbacks jouent également un rôle clé dans la détection des techniques d’injection de code à distance, en signalant les accès suspects à des processus tiers avant même que les opérations d’écriture mémoire ou de création de thread ne soient réalisées.
Grâce à leur capacité à intervenir avant l’attribution effective des droits d’accès, ces callbacks constituent l’un des mécanismes de protection les plus efficaces exploités par les EDR modernes.
Contrairement aux callbacks précédents, qui reposent sur différents mécanismes de notification du noyau Windows, la surveillance du système de fichiers s’appuie généralement sur des drivers minifilters. Enregistrés auprès du Filter Manager via l’API « FltRegisterFilter », ces composants permettent à l’EDR de s’interposer sur les opérations réalisées sur le système de fichiers.
Les minifilters peuvent définir des routines de pré- et post-traitement pour de nombreuses opérations d’entrée/sortie (I/O), telles que la création, la lecture, l’écriture, le renommage ou la suppression de fichiers. Cette position privilégiée leur offre une visibilité complète sur les interactions entre les processus et les données stockées sur le disque.
Cette télémétrie est particulièrement utile pour détecter les comportements caractéristiques de certaines menaces. Un EDR peut par exemple identifier un ransomware en observant un grand nombre d’opérations de chiffrement réalisées en peu de temps, ou détecter l’écriture d’un exécutable suspect dans un répertoire sensible du système. Certains produits utilisent également ces mécanismes pour bloquer ou mettre en quarantaine des fichiers avant leur exécution.
Les minifilters constituent ainsi une source de visibilité essentielle pour surveiller l’activité du système de fichiers et compléter les informations collectées par les autres mécanismes de télémétrie du noyau.
Les callbacks noyau offrent une excellente visibilité sur les événements système, mais ils ne permettent pas toujours d’accéder facilement au contexte complet d’une opération. Pour enrichir leur télémétrie, les EDR s’appuient également sur des mécanismes de surveillance exécutés directement dans l’espace utilisateur.
La technique la plus répandue est le userland hooking (ou inline hooking) :
Le principe consiste à modifier les premières instructions de certaines fonctions sensibles de « ntdll.dll », comme « NtAllocateVirtualMemory », « NtWriteVirtualMemory » ou « NtProtectVirtualMemory », afin d’insérer un saut vers le code d’analyse de l’EDR.
Lorsqu’un processus appelle l’une de ces fonctions, l’exécution est redirigée vers le hook. L’EDR peut alors inspecter les arguments transmis, collecter des informations complémentaires sur l’opération en cours et alimenter ses mécanismes de détection avant que l’appel système ne soit transmis au noyau.
Cette approche présente un avantage majeur : elle permet d’observer les données telles qu’elles existent réellement dans la mémoire du processus. Un shellcode chiffré ou un script fortement obfusqué doit nécessairement être déchiffré avant d’être exécuté. En surveillant les opérations mémoire à ce stade, l’EDR peut analyser le contenu après sa phase de déchiffrement, réduisant ainsi considérablement l’efficacité des techniques d’obfuscation statique.
Cette visibilité reste toutefois limitée à l’espace utilisateur. Un attaquant peut par exemple contourner certains hooks en invoquant directement les appels système (Direct Syscalls), ce qui explique pourquoi les EDR combinent généralement cette technique avec les mécanismes de surveillance présents dans le noyau Windows.
L’ETW (Event Tracing for Windows) est un mécanisme de journalisation intégré nativement à Windows permettant de collecter des événements provenant du noyau, des drivers et des applications. Conçu pour être performant et peu intrusif, il est largement utilisé par les outils d’administration, de diagnostic et de sécurité afin d’obtenir une visibilité détaillée sur l’activité du système.
L’architecture ETW repose sur quatre composants principaux :
logman.exe).De nombreuses solutions de sécurité exploitent ETW pour collecter de la télémétrie sans avoir à instrumenter elles-mêmes chaque composant du système. Cependant, l’ETW classique présente une limite importante : un attaquant disposant de privilèges élevés peut potentiellement désactiver certains providers ou perturber leur collecte afin de réduire la visibilité des mécanismes de détection.
Pour répondre à cette problématique, Microsoft a introduit le provider Microsoft-Windows-Threat-Intelligence (ETW-Ti). Sa particularité est d’être protégé par le mécanisme Protected Process Light (PPL). Seuls les processus exécutés avec le niveau de protection PS_PROTECTED_ANTIMALWARE_LIGHT peuvent consommer les événements qu’il génère.
L’accès à ce niveau de protection nécessite l’utilisation d’un certificat ELAM (Early Launch Anti-Malware) délivré par Microsoft aux éditeurs de solutions de sécurité validés. En pratique, un processus exécuté avec les privilèges SYSTEM ne peut pas simplement s’abonner à ce provider ni le désactiver depuis l’espace utilisateur, ce qui en fait une source de télémétrie particulièrement fiable pour les EDR.
Contrairement aux providers ETW classiques, ETW-Ti est directement instrumenté dans le noyau Windows. Microsoft a intégré au sein de ntoskrnl.exe plusieurs fonctions spécialisées appelées lors d’opérations sensibles :
| Fonction EtwTi | Opération surveillée | Syscall associé |
| EtwTiLogAllocExecVm | Allocation de mémoire exécutable | NtAllocateVirtualMemory |
| EtwTiLogProtectExecVm | Modification des permissions mémoire (RWX) | NtProtectVirtualMemory |
| EtwTiLogReadWriteVm | Lecture ou écriture dans un processus distant | NtRead/WriteVirtualMemory |
| EtwTiLogQueueUserApc | Injection via APC | NtQueueApcThread |
| EtwTiLogSetContextThread | Modification du contexte d’un thread | NtSetContextThread |
Ces événements correspondent précisément aux primitives utilisées par de nombreuses techniques d’injection de code. Lorsqu’un processus modifie la mémoire d’un autre processus ou tente d’exécuter du code à distance, l’EDR bénéficie d’une visibilité détaillée sur l’opération réalisée et peut corréler ces informations avec d’autres sources de télémétrie afin d’identifier un comportement malveillant.
Cette approche est particulièrement efficace contre les attaques s’appuyant sur des shellcodes, des loaders ou des techniques d’injection avancées. Là où un hook userland peut être contourné par l’utilisation de Direct Syscalls, les événements ETW-Ti sont générés directement depuis le noyau et restent donc visibles pour les solutions de sécurité autorisées.
Contourner ETW-Ti nécessite généralement d’obtenir une exécution en mode noyau (Ring 0). Les attaquants s’appuient alors fréquemment sur des techniques de type BYOVD (Bring Your Own Vulnerable Driver) afin de charger un driver vulnérable et modifier les mécanismes de télémétrie du système. Cette contrainte illustre parfaitement la philosophie des EDR modernes : multiplier les couches de détection afin d’augmenter progressivement le coût et la complexité des techniques d’évasion.
Pour ne laisser aucun angle mort, un EDR s’appuie sur trois piliers complémentaires.
Introduit par Microsoft afin de renforcer l’analyse des contenus exécutés en mémoire, AMSI (Antimalware Scan Interface) n’est pas un moteur de détection à proprement parler. Il s’agit d’une interface standardisée permettant aux applications de transmettre du contenu à la solution de sécurité enregistrée sur le système pour analyse.
L’intérêt principal d’AMSI est de lutter contre les techniques d’obfuscation couramment utilisées par les attaquants.
amsi.dll » via des fonctions telles que « AmsiScanBuffer » ou « AmsiScanString » afin de soumettre le contenu à la solution de sécurité.Cette approche est particulièrement efficace car elle permet à l’EDR d’observer le contenu après sa phase de déchiffrement ou de désobfuscation. Même lorsqu’un script a été fortement transformé pour échapper aux mécanismes de détection classiques, sa logique réelle doit nécessairement apparaître en clair avant son exécution.
Aujourd’hui, AMSI est intégré nativement dans plusieurs composants majeurs de l’écosystème Windows, notamment PowerShell, VBScript, JScript, VBA (macros Office) et le framework .NET, ce qui en fait une source de télémétrie particulièrement précieuse pour les solutions EDR.
Les EDR surveillent également les communications réseau initiées par les processus exécutés sur la machine. Cette visibilité permet d’établir un lien direct entre une activité réseau et le processus qui en est à l’origine, offrant ainsi un contexte précieux pour la détection des menaces.
Au-delà de la simple observation des connexions TCP ou UDP, les solutions EDR analysent de nombreux indicateurs tels que les requêtes DNS, les domaines contactés, les adresses IP distantes, les ports utilisés ou encore la fréquence des communications. Ces informations sont ensuite corrélées avec la télémétrie collectée sur le système.
Cette approche permet d’identifier des comportements anormaux qui passeraient inaperçus dans une analyse réseau classique. Par exemple, un processus comme « notepad.exe » établissant une connexion TCP sortante vers Internet, ou un processus PowerShell réalisant des communications périodiques vers une infrastructure distante, peuvent constituer des indicateurs d’un canal de commande et de contrôle (C2).
En combinant les événements réseau avec les informations issues des callbacks noyau, de l’API hooking ou d’ETW-Ti, l’EDR est capable de reconstituer la chaîne complète d’une attaque et d’attribuer précisément une activité réseau suspecte au processus responsable.
Au-delà de l’analyse des événements système, les EDR inspectent également l’état de la mémoire des processus à la recherche d’IoC (Indicators of Compromise). Cette approche permet d’observer directement les artefacts laissés par une attaque une fois celle-ci en cours d’exécution.
Les solutions EDR peuvent ainsi identifier des régions mémoire suspectes, des modules injectés, des threads exécutant du code en dehors de modules légitimes ou encore des piles d’appels présentant des incohérences. Ces indicateurs sont fréquemment associés à des techniques d’injection de code, d’exécution de shellcode ou de chargement de bibliothèques malveillantes en mémoire.
Cette visibilité est particulièrement précieuse car elle porte sur l’état réel du processus au moment de son exécution. Contrairement aux mécanismes de détection reposant sur l’analyse de fichiers, les détections mémoire s’intéressent au résultat final de l’attaque : le code qui s’exécute effectivement dans le processus, indépendamment de la manière dont il a été déployé ou dissimulé.
Pour cette raison, les analyses mémoire figurent parmi les mécanismes de détection les plus sophistiqués des EDR modernes et constituent souvent l’une des dernières lignes de défense face aux techniques d’évasion avancées.
Malgré leur niveau de visibilité avancé, les EDR ne constituent pas une protection infaillible. Comme tout mécanisme de sécurité, leurs capacités de détection peuvent être contournées ou dégradées par des attaquants disposant des connaissances et des privilèges suffisants.
Les techniques modernes d’évasion visent généralement les différentes sources de télémétrie exploitées par les EDR. Parmi les approches les plus connues figurent l’utilisation de Direct Syscalls pour contourner les hooks userland, les attaques de type Bring Your Own Vulnerable Driver (BYOVD) permettant d’obtenir une exécution en mode noyau, ou encore les mécanismes de désactivation ciblant certains composants de sécurité.
Toutefois, la force des EDR modernes réside précisément dans la multiplication des couches de détection. Contourner un mécanisme de surveillance ne suffit généralement pas : l’attaquant doit neutraliser plusieurs sources de télémétrie simultanément pour réduire significativement les capacités de détection de la solution.
Pour une analyse détaillée des principales techniques de contournement des antivirus et des EDR, consultez notre article dédié : Techniques de contournement d’antivirus et d’EDR.
Auteur : Alexis PARET – Pentester @Vaadata
