Détection - Réponse - Sécurité des endpoints - Red Team
Les EDR sont devenus le principal obstacle que les pentesters et les attaquants doivent contourner sur chaque endpoint Windows. Comment fonctionnent-ils réellement ? Quels mécanismes de détection activent-ils ? Comment nos équipes les testent et les évaluent en mission ? Guide complet par les experts offensifs PIIRATES.
Qu’est-ce qu’un EDR ?
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 : postes de travail, serveurs, machines virtuelles. 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 en temps réel sur une machine, même lorsqu’aucun malware connu n’est présent sur le disque.
Le terme « EDR » a été introduit en 2013 par Anton Chuvakin (Gartner) pour décrire une nouvelle catégorie de solutions capables de combler le vide entre la détection statique des antivirus et la capacité de réponse aux incidents. Depuis, les EDR sont devenus le composant central de la sécurité des endpoints dans les organisations de toutes tailles.
Concrètement, un EDR est capable de surveiller :
- La création de processus et de threads, et leurs relations parent/enfant.
- Les chargements de bibliothèques en mémoire (DLL injection, process hollowing).
- Les accès aux processus sensibles comme LSASS (cible des attaques de vol de credentials).
- Les modifications du registre Windows (persistance, désactivation de protections).
- Les connexions réseau sortantes (C2, exfiltration de données).
- Les opérations sur le système de fichiers (création, modification, chiffrement de fichiers).
- L’exécution de scripts PowerShell, WMI et d’autres LOLBins (Living Off the Land Binaries).
Ces événements sont collectés en continu, envoyés à une plateforme centralisée et analysés par des moteurs de corrélation pour détecter des comportements caractéristiques d’une attaque : injection de code, tentative d’extraction d’identifiants, mouvement latéral, établissement d’un canal C2 ou ransomware.
EDR vs Antivirus : pourquoi l’antivirus ne suffit plus
La différence fondamentale entre un antivirus et un EDR tient à leur philosophie de détection. L’antivirus compare des fichiers à une base de signatures connues : si la signature du fichier correspond à un malware répertorié, l’alerte est déclenchée. Cette approche est efficace contre les malwares connus et distribués en masse, mais échoue face aux menaces modernes.
| Critère | Antivirus traditionnel | EDR |
|---|---|---|
| Méthode de détection | Signatures statiques | Comportement en temps réel |
| Menaces fileless (en mémoire) | Aveugle | Détectées |
| LOLBins (outils Windows détournés) | Aveugle | Détectés par comportement |
| Zero-days | Aveugle | Partiellement détectés (comportement) |
| Historique des événements | Absent | Journal complet (investigation forensique) |
| Réponse automatique | Quarantaine fichier uniquement | Isolation réseau, kill process, rollback |
| Visibilité post-compromission | Nulle | Complète (timeline d’attaque reconstituée) |
Architecture interne d’un EDR : user-mode et kernel-mode
Un agent EDR moderne n’est pas un simple exécutable. Il se compose de deux couches distinctes qui communiquent en permanence, chacune ayant une responsabilité spécifique dans la chaîne de détection.
Couche User-Mode (Ring 3)
Le composant user-mode est la première couche d’observation de l’EDR. Il se présente généralement sous la forme d’une DLL injectée dans les processus en cours d’exécution sur le système. Son rôle principal est d’intercepter les appels API sensibles avant qu’ils n’atteignent le noyau, via des techniques d’API Hooking.
En pratique, l’EDR modifie les premières instructions des fonctions critiques de ntdll.dll (comme NtAllocateVirtualMemory, NtWriteVirtualMemory, NtCreateThread) pour rediriger les appels vers ses propres routines d’inspection. Avant que l’appel ne soit transmis au noyau, l’EDR peut lire les arguments, logger l’événement, ou bloquer l’appel si le comportement est jugé malveillant.
Un service en arrière-plan centralise la télémétrie collectée, l’envoie à la console d’administration cloud et exécute les actions de réponse : alerte, suspension de processus, quarantaine, isolation réseau.
Couche Kernel-Mode (Ring 0)
Le composant kernel-mode est le cœur du système de surveillance. Exécuté sous forme d’un driver noyau signé avec les privilèges les plus élevés du système (Ring 0), il bénéficie d’une visibilité sur des événements inaccessibles depuis l’espace utilisateur.
Contrairement aux hooks user-mode, contournables par un attaquant qui syscalle directement le noyau en évitant ntdll.dll, les mécanismes kernel offrent une visibilité plus fiable. C’est à ce niveau que s’enregistrent les Kernel Callbacks, les abonnements ETW-Ti (Event Tracing for Windows - Threat Intelligence) et les drivers Minifilter pour le système de fichiers.
Les Kernel Callbacks : le système nerveux de l’EDR
Le noyau Windows met à disposition des drivers un mécanisme de notification appelé callbacks. Ces points d’ancrage permettent au driver EDR d’être automatiquement notifié quand un événement système spécifique se produit, en temps réel.
Process Creation Callbacks
Ces callbacks notifient le driver EDR à chaque création ou terminaison de processus. Ils sont stockés dans le tableau noyau nt!PspCreateProcessNotifyRoutine et les drivers s’y enregistrent via PsSetCreateProcessNotifyRoutineEx.
Lorsqu’un processus est créé (via NtCreateUserProcess), le noyau appelle PspCallProcessNotifyRoutines qui exécute tous les callbacks enregistrés. L’EDR reçoit immédiatement : PID, PPID, chemin de l’exécutable, arguments de lancement, contexte de création.
C’est via ce mécanisme que l’EDR détecte par exemple cmd.exe ou powershell.exe lancés depuis winword.exe ou excel.exe (indicateur fort d’exploitation de macro malveillante).
Thread Creation Callbacks
Les Thread Callbacks s’enregistrent via PsSetCreateThreadNotifyRoutine et notifient l’EDR à chaque création de thread. Ils permettent notamment de détecter les remote thread injections : quand un processus A crée un thread dans le contexte d’un processus B, c’est un indicateur classique d’injection de code (DLL injection, shellcode injection).
Image Load Callbacks
Ces callbacks (PsSetLoadImageNotifyRoutine) sont déclenchés à chaque fois qu’une image (exécutable ou DLL) est chargée en mémoire. Ils permettent à l’EDR de détecter le chargement de DLL malveillantes, de DLL non signées, ou de bibliothèques chargées depuis des emplacements non standards (technique DLL side-loading).
Registry Operation Callbacks
Via le framework CmRegisterCallbackEx, l’EDR surveille toutes les opérations sur le registre Windows en temps réel. Cela permet de détecter les techniques de persistance classiques comme l’ajout de clés Run/RunOnce, la modification des services Windows, ou la désactivation des protections (DisableAntiSpyware, DisableRealtimeMonitoring).
Object Operation Callbacks
Ces callbacks (ObRegisterCallbacks) permettent à l’EDR d’intercepter les tentatives d’accès aux objets noyau, en particulier les processus et les threads. C’est le mécanisme qui permet de détecter et bloquer les tentatives d’accès à LSASS (exécutables comme Mimikatz, ou techniques de dumping via MiniDumpWriteDump). L’EDR peut réduire les droits demandés (PROCESS_VM_READ) avant de les accorder.
Minifilter Callbacks (Filesystem)
Un driver minifilter s’insère dans la pile d’I/O du système de fichiers Windows et intercepte toutes les opérations (création, lecture, écriture, suppression de fichiers). C’est ce mécanisme qui permet aux EDR de détecter les comportements de ransomware (chiffrement massif de fichiers), de dropper de malwares (exécutables créés dans des emplacements inhabituels) ou d’exfiltration vers un support amovible.
Votre EDR est-il vraiment efficace contre une attaque ciblée ?
Nos pentesters testent la résistance des EDR déployés chez nos clients lors de chaque mission d’audit interne et de Red Team. Nous évaluons ce que votre EDR voit, ce qu’il ne voit pas, et comment un attaquant réel l’aborderait.
Mécanismes de détection avancés : ETW-Ti, AMSI et analyse mémoire
ETW-Ti : Event Tracing for Windows Threat Intelligence
ETW-Ti est l’une des sources de télémétrie les plus puissantes disponibles pour les EDR modernes. Il s’agit d’un canal ETW privilégié, accessible uniquement aux processus Protected Process Light (PPL), qui fournit des événements de sécurité à haute granularité directement depuis le noyau.
Les événements ETW-Ti couvrent notamment :
- Allocations mémoire exécutables : détection de shellcodes injectés en mémoire (RWX pages, suspicious regions).
- Remote thread injection : création de threads dans des processus distants avec des adresses de départ suspectes.
- Accès LSASS : toute tentative de lecture de la mémoire de
lsass.exeest logée avec le handle demandé. - Suspicious API chains : séquences d’appels API typiques de l’injection de code (VirtualAllocEx → WriteProcessMemory → CreateRemoteThread).
ETW-Ti est particulièrement difficulté à contourner car il fonctionne indépendamment des hooks user-mode. Même si un attaquant contourne les hooks ntdll.dll via des syscalls directs, ETW-Ti continue de logger les événements depuis le noyau.
AMSI (Antimalware Scan Interface)
AMSI est une interface Windows qui permet aux applications (PowerShell, WScript, Office, .NET) de soumettre du contenu à analyser aux solutions de sécurité installées avant son exécution. C’est le mécanisme qui permet aux EDR de voir le contenu déchiffré et désobfusqué des scripts PowerShell, là où un scan statique ne verrait qu’un payload chiffré.
Quand PowerShell exécute un script, il appelle AmsiScanBuffer() pour soumettre le contenu en clair à l’EDR avant d’effectivement exécuter les instructions. L’EDR peut alors analyser le script, détecter des patterns malveillants (appels Win32 API suspects, encodage Base64 multiple, appels à des fonctions de téléchargement) et bloquer l’exécution.
AMSI couvre aujourd’hui : PowerShell, Windows Script Host (VBScript/JScript), Office VBA macros, .NET assemblies (depuis .NET 4.8), et WMI.
Détection réseau
Les EDR modernes intègrent également une visibilité sur les communications réseau des processus. En combinant inspection DNS, surveillance des connexions TCP/UDP et analyse des certificats TLS (via inspection du SNI), ils peuvent détecter :
- Connexions vers des domaines C2 connus (threat intelligence).
- Connexions inhabituelles depuis des processus système (
lsass.exe,svchost.exequi initient des connexions sortantes vers Internet). - DNS over HTTPS non autorisé (tentative de contourner l’inspection DNS).
- Beaconing régulier à intervalles fixes (pattern typique d’un implant C2 comme Cobalt Strike).
Détection mémoire
Les attaques fileless (sans fichier sur le disque) sont entièrement en mémoire. Les EDR modernes analysent périodiquement l’état de la mémoire des processus pour détecter :
- Des régions mémoire exécutables non associées à un fichier sur disque (anomalie typique d’un shellcode injecté).
- Des artefacts Cobalt Strike Beacon (
MZheader en mémoire, patterns de configuration). - Des stack de thread pointant vers des régions mémoire anormales (indicateur d’un thread injecté).
- Signatures de Mimikatz ou de ses variantes en mémoire.
EDR et pentest : la perspective offensive de PIIRATES
Du point de vue d’un pentester ou d’un attaquant réel, l’EDR est le principal obstacle à surmonter sur chaque machine Windows cible. Comprendre son fonctionnement interne est une prérequis pour mener des missions de pentest interne et de Red Team crédibles.
Ce que nos pentesters font face à un EDR
Lors d’un test d’intrusion interne, la première étape après avoir obtenu un premier accès sur une machine est d’identifier la solution EDR déployée. Cette identification se fait par des moyens passifs : liste des processus en cours, services Windows, drivers chargés, clés de registre associées.
Quelques indicateurs visibles sans privilège :
tasklist /svc | findstr -i "sentinel crowdstrike defender cylance carbon"
Ou via PowerShell :
Get-Process | Where-Object {$_.Name -match "sense|csagent|mssense|csc|carbonblack"}
Les techniques de contournement d’EDR en contexte de pentest
En Red Team et en pentest boite blanche, nos pentesters évaluent la capacité de l’EDR à résister aux techniques d’évasion modernes. Voici les approches les plus courantes que nous testons.
Direct Syscalls (contournement des hooks user-mode)
Plutôt que d’appeler NtAllocateVirtualMemory via ntdll.dll (où l’EDR a posé ses hooks), un outil peut appeler directement l’instruction syscall du CPU avec le numéro SSN (System Service Number) correspondant. Les hooks user-mode de l’EDR sont court-circuités. Outils : SysWhispers2/3, HellsGate, Tartarus’ Gate.
AMSI et ETW patching
Des techniques en mémoire permettent de neutraliser AMSI en écrasant les premières instructions de AmsiScanBuffer() pour qu’elle retourne toujours « clean ». De même, EtwEventWrite() peut être parchée pour éviter que les événements soient envoyés aux fournisseurs ETW. Ces techniques sont détectées par les EDR modernes via ETW-Ti (qui surveille les modifications de mémoire dans les processus système).
Process Hollowing et Process Doppelgänging
Ces techniques créent un processus légitime suspendu, remplacent son code par un payload malveillant, puis le reprennent. L’EDR voit un processus avec un nom légitime. Les EDR modernes contrent cela via les Image Load Callbacks et l’analyse mémoire (détection d’une région mémoire exécutable dont le contenu ne correspond pas à l’image sur disque).
LOLBins et Living Off The Land
Plutôt que de déposer un outil malveillant sur le disque, l’attaquant utilise des binaires légitimes Windows : certutil.exe pour télécharger des fichiers, mshta.exe pour exécuter du code, rundll32.exe pour charger des DLL arbitraires. Les EDR modernes détectent ces abus via les Process Creation Callbacks (corrélation contexte parent + arguments) et leur base de règles comportementales.
Indirect Syscalls et Shellcode Obfuscation
Variante des Direct Syscalls : l’adresse de retour du syscall est falsifiée pour pointer vers une région légitime de ntdll.dll, contournant certaines vérifications de stack ETW-Ti. Les techniques d’obfuscation de shellcode (XOR, AES, segmentation) retardent la détection à l’analyse statique mais ne trompent pas l’analyse comportementale après déchiffrement en mémoire.
Dans nos missions de Red Team et de pentest interne, nous testons systématiquement la capacité de l’EDR déployé à détecter les techniques d’accès LSASS, les injections de code et les mouvements latéraux. Les résultats varient très significativement selon la solution, sa version, et sa configuration. Un EDR déployé avec les règles par défaut est généralement beaucoup moins efficace qu’un EDR configuré et maintenu activement par une équipe SOC.
EDR, XDR, MDR, NDR : comprendre les différences
Le marché de la sécurité des endpoints est riche en acronymes qui désignent des approches distinctes mais complémentaires. Voici le comparatif structuré pour les RSSI et DSI qui doivent choisir ou combiner ces solutions.
| Solution | Périmètre | Sources de données | Réponse | Exploitation humaine |
|---|---|---|---|---|
| EDR | Endpoints (postes, serveurs) | Télémétrie agent local | Automatisée sur endpoint | Equipe interne (RSSI/SOC) |
| XDR | Endpoint + réseau + cloud + email | Multi-sources corrélées | Automatisée multi-vecteurs | Equipe interne (SOC) |
| MDR | Variable (selon prestataire) | EDR + SIEM + CTI | Automatisée + humaine (SOC externalisé) | SOC externalisé 24/7 |
| NDR | Réseau uniquement | Flux réseau (NTA, DPI) | Alerte + corrélation | Equipe réseau/SOC |
Ce qu’un EDR ne remplace pas
Même le meilleur EDR du marché a des angles morts que nos missions de pentest révèlent régulièrement :
- Les vulnérabilités applicatives : l’EDR surveille les comportements au niveau OS mais ne voit pas une injection SQL dans une application web. Un pentest applicatif reste indispensable.
- Les erreurs de configuration Active Directory : les chemins d’éscalade de privilèges via Kerberoasting, délégation non contrainte ou ACL mal configurées passent souvent sous le radar des EDR. Un audit BloodHound complète cette couverture.
- Les attaques physiques et les vecteurs humains : l’ingénierie sociale et les accès physiques ne génèrent pas nécessairement d’alertes EDR.
- Les systèmes non couverts : les équipements OT, les systèmes industriels SCADA et de nombreux systèmes IoT ne peuvent pas exécuter un agent EDR. C’est ce que couvrent nos missions de pentest industriel.
Indépendance totale
Expertise offensive
Professionnalisme
Nos coordonnées
- 04 28 49 00 25
- contact@piirates.fr
- 6 Rue Denis Papin
07130 Saint Peray
Envoyez nous un ping
EDR : fonctionnement interne, kernel callbacks, ETW-Ti, AMSI, comparatif XDR/MDR, panorama des solutions et perspective offensive de nos pentesters. Guide complet PIIRATES.
