Endpoint Detection and Response (EDR)
EDR, EPP, JPP
L’Endpoint Detection and Response (EDR) est une solution de sécurité informatique dont l’objectif est de détecter et de répondre aux menaces ciblant les postes de travail et serveurs. Ces menaces peuvent inclure des logiciels malveillants, des attaques sur des services exposés en réseau, des actions d’utilisateurs malveillants, etc. Cet article vise à proposer une première approche du fonctionnement des EDR.
Un EDR est un antivirus
On peut aisément dire qu’un EDR est un antivirus, cependant l’inverse n’est pas vrai. Cette affirmation peut paraître tranchée, mais les fonctionnalités de détection de logiciels malveillants sont communes. Certains éditeurs ne parlent plus d’« antivirus », mais de EPP (Endpoint Protection Platform pour une nouvelle génération d’antivirus). Au fil du temps, les antivirus ont évolué, passant du simple scan de signatures à des techniques d’analyse comportementale, heuristique et de réputation. Par exemple, ClamAV, un antivirus open source, repose exclusivement sur les signatures, tandis que des logiciels comme Avast, AVG, ESET, Bitdefender ou Kaspersky intègrent pare-feux, surveillance des fichiers utilisateurs, analyse comportementale et envoi d’échantillons pour analyse distante.
La flexibilité de certains EDR permet de désactiver des composants. Le moteur antiviral (soit l’antivirus intégré) en fait partie. Dans ce cadre, il est possible d’installer un antivirus. Un EDR et une solution antivirale peuvent coexister.
Analyse statique et analyse dynamique
On distingue deux catégories d’analyse :
L’analyse statique qui s’appuie sur une source sous forme de bloc de données. Grâce à divers algorithmes, cette analyse rapporte des anomalies statistiques, de réputation ou trouve directement des schémas connus de logiciel malveillant.
L’analyse dynamique obtient de la télémétrie : un ensemble d’événement provenant du système d’exploitation ou des programmes. Un événement regroupe l’usage de fonctionnalité du système, des applications, du réseau et du matériel. Ils sont retranscrits sous forme de journaux. Par défaut, très peu d’événements sont collectés, c’est à la solution de sécurité de maintenir ses fonctionnalités de télémétrie. À partir de cette télémétrie, des jeux de règles s’appliquent pour identifier des actions suspectes et malveillantes.
La réponse à la détection
Lorsqu’une analyse détecte une menace, les solutions de sécurité peuvent entreprendre diverses actions :
-
Bloquer la menace, par un ensemble de réponse pré-configuré : isolation du poste, isolation du compte utilisateur, arrêt/suspension du processus, blocage d’exécution du programme, etc. Les options de configuration peuvent être activées ou désactivées dans les EDR.
-
Alerter les équipes de sécurité et l’utilisateur.
-
Déclencher des actions personnalisées par les équipes de sécurité. Ce sont souvent des programmes écrits par les équipes de sécurité. Cela peut aller à l’automatisation de collecte de preuve de l’incident de sécurité, de l’analyse du logiciel malveillant, etc.
Analyse statique
La détection par signature
Un antivirus repose d’abord sur un scanner de signatures. Ces signatures sont des règles de détection définies sur des séquences d’octets caractéristiques. Le scanner analyse les fichiers du système à la recherche de ces motifs. Voici un exemple de règle au format YARA :
rule Windows_Trojan_CobaltStrike_c851687a {
meta:
author = "Elastic Security"
id = "c851687a-aac6-43e7-a0b6-6aed36dcf12e"
fingerprint = "70224e28a223d09f2211048936beb9e2d31c0312c97a80e22c85e445f1937c10"
creation_date = "2021-03-23"
last_modified = "2021-08-23"
description = "Identifies UAC Bypass module from Cobalt Strike"
threat_name = "Windows.Trojan.CobaltStrike"
severity = 100
arch_context = "x86"
scan_context = "file, memory"
license = "Elastic License v2"
os = "windows"
strings:
$a1 = "bypassuac.dll" ascii fullword
$a2 = "bypassuac.x64.dll" ascii fullword
$a3 = "\\\\.\\pipe\\bypassuac" ascii fullword
$b1 = "\\System32\\sysprep\\sysprep.exe" wide fullword
$b2 = "[-] Could not write temp DLL to '%S'" ascii fullword
$b3 = "[*] Cleanup successful" ascii fullword
$b4 = "\\System32\\cliconfg.exe" wide fullword
$b5 = "\\System32\\eventvwr.exe" wide fullword
$b6 = "[-] %S ran too long. Could not terminate the process." ascii fullword
$b7 = "[*] Wrote hijack DLL to '%S'" ascii fullword
$b8 = "\\System32\\sysprep\\" wide fullword
$b9 = "[-] COM initialization failed." ascii fullword
$b10 = "[-] Privileged file copy failed: %S" ascii fullword
$b11 = "[-] Failed to start %S: %d" ascii fullword
$b12 = "ReflectiveLoader"
$b13 = "[-] '%S' exists in DLL hijack location." ascii fullword
$b14 = "[-] Cleanup failed. Remove: %S" ascii fullword
$b15 = "[+] %S ran and exited." ascii fullword
$b16 = "[+] Privileged file copy success! %S" ascii fullword
condition:
2 of ($a*) or 10 of ($b*)
}
Créée par la société Elastic, cette règle détecte un cheval de Troie (ici Cobalt Strike, utilisé pour prendre le contrôle à distance d’un ordinateur). Elle s’active si au moins deux chaînes comme “bypassuac.dll”, “bypassuac.x64.dll” ou “.\pipe\bypassuac” sont présentes. L’attaque visée ici est un bypass UAC, c’est-à-dire le contournement du User Account Control, une fonctionnalité qui empêche les processus de bénéficier automatiquement de privilèges administrateurs. En contournant cette protection, un malware peut élever ses privilèges sans autorisation utilisateur.
Dans la section “condition”, la syntaxe 2 of ($a*) signifie qu’au moins deux chaînes définies par les variables commençant par $a doivent être détectées. 10 of ($b*) en exige dix parmi celles de $b. Le or signifie qu’au moins un de ces deux groupes doit correspondre. Cette logique permet une détection souple et puissante, caractéristique des moteurs de signature modernes.
Avec cette compréhension, vous réalisez qu’une signature est une règle codifiée, téléchargée régulièrement par l’antivirus depuis les serveurs de l’éditeur. Ce dernier doit donc rester en veille constante pour identifier de nouvelles menaces et enrichir sa base. Plus les moyens de recherche d’un éditeur sont importants, plus la base de signatures est complète, ce qui améliore l’efficacité de la protection. C’est pourquoi certains antivirus envoient automatiquement à leur éditeur des fichiers inconnus, souvent sans consentement explicite de l’utilisateur.
L’analyse de l’entropie
L’entropie de Shannon : une mesure statistique qui attribue un score entre 0 et 8 à un bloc de données. Plus ce score est élevé, plus le contenu est aléatoire. Ce qui est souvent un indice de chiffrement ou de compression, le programme malveillant camoufle ses fonctionnalités maîtresses au sein du programme, un score élevé est potentiellement révélateur. lien
| bruits ou entropie d’un fichier dll | crédit : ImHex |
Les programmes de confiance (la réputation)
Un programme de confiance est un binaire dont l’origine est garantie cryptographiquement. On peut parler de réputation du logiciel. Cela repose sur une infrastructure à clés publiques (PKI). Un fichier signé contient une signature cryptographique qui prouve que son émetteur détient une clé privée correspondant à une autorité reconnue. Ce système est utilisé par les éditeurs pour évaluer automatiquement la confiance d’un programme.
| signature de systeminformer |
Analyse Dynamique
L’analyse comportementale
L’analyse comportementale repose sur l’observation de l’activité du système d’exploitation. Le système fournit des services qui permettent de manipuler fichiers, réseau, privilèges, etc. Ces services diffèrent selon l’OS (Windows, Linux, macOS), et une connaissance approfondie du système est indispensable.
Sous Windows, comprendre les processus et la mémoire est essentiel. Un processus est une entité qui isole les tâches, la mémoire et les privilèges. Il ne peut lire la mémoire d’un autre processus sans passer par des mécanismes système. De même, il ne peut utiliser directement toutes les instructions du processeur.
Les antivirus doivent pouvoir inspecter la mémoire des processus. Pour cela, ils utilisent à la fois des mécanismes offerts par l’OS et des techniques personnalisées, parfois intrusives. Certains vont jusqu’à modifier à la volée des fonctions critiques du système. Une pratique que Microsoft tente d’endiguer, mais qui subsiste, parfois au prix de graves dysfonctionnements (cf. l’incident CrowdStrike ayant causé un plantage massif).
Deux composants principaux assurent cette analyse :
Une bibliothèque (le fichier .DLL) injectée dans chaque processus, chargée d’intercepter certains appels système. Sur Windows, ntdll.dll gère les appels système (syscalls). L’antivirus détourne ces appels vers son propre code pour analyse.
Un driver (pilote, le fichier .SYS) tournant dans le noyau, ayant un accès complet au système. Il surveille des événements comme la création de processus, accès fichier ou le chargement de bibliothèques via des fonctions natives de Windows (ex : PsSetCreateProcessNotifyRoutineEx, PsSetLoadImageNotifyRoutine).
| Schema des composants de l’analyse comportementale | Mafilus (BY-CC-NC) |
Certaines solutions vont encore plus loin, en installant un hyperviseur via le processeur pour contrôler les appels Système vers le noyau (ex : Avast avec KiSystemCall64 intercepté via une opération VM-exit).
La protection anti-ransomware
La protection anti-ransomware varie selon les éditeurs, mais repose souvent sur deux techniques : l’analyse des fichiers sensibles et le honeypot. Parfois, une stratégie de sauvegarde automatique complète le tout.
Le système surveille les opérations sur des fichiers critiques (images, vidéos, documents, etc.), mais rarement sur des fichiers techniques (ex. .json). Le driver de l’antivirus utilise souvent des minifilters pour notifier les accès. Si un processus suspect tente de modifier ces fichiers, l’antivirus peut bloquer l’opération ou demander une validation utilisateur.
| Avast agent anti-ransomware | Source Mafilus |
Le honeypot, ou “pot de miel”, place volontairement de faux fichiers appâts (on attrape un ours avec un pot de miel). Toute tentative de modification déclenche une alerte et une réponse : isolation du processus, restauration des fichiers, etc. Ces fichiers sont invisibles aux programmes de confiance. Les composants comportementaux sont ici essentiels pour différencier une menace d’un comportement légitime.
| Fichier Honeypot de l’EDR Cortex | source : metabaseq.com |
Le pare-feu
Certains antivirus intègrent une analyse réseau, utilisant l’infrastructure de filtrage natif de Windows via Windows Filtering Platform (WFP). Ce module noyau permet, grâce à des fonctions comme FwpmFilterAdd, de bloquer ou d’autoriser des paquets réseau, sortants ou entrants, selon les règles de l’éditeur.
L’analyse sandboxing ou bac à sable
Il faut différencier la sandbox de l’anti-virus local et celle qui est employée chez l’éditeur. Au niveau local, la sandbox est une analyse sur un laps de temps court de l’exécution du programme. La sandbox simule sans pour autant donner un accès directement au système. Pendant cette analyse, l’antivirus va renforcer son analyse comportementale.
L’analyse d’échantillon
L’analyse d’échantillons se déroule généralement chez l’éditeur de la solution de sécurité. Elle est appelée analyse heuristique, sandboxing, cloud, IA, etc. En réalité, chaque éditeur déploie ses propres techniques : analyse automatisée, manuelle, ou hybride (avec escalade humaine si l’analyse automatique est incertaine).
Parmi les techniques utilisées, l’analyse heuristique et le sandboxing sont les plus établies, ils ne sont pas toujours les plus efficaces. L’heuristique s’appuie sur l’analyse comportementale, parfois via des modèles de graphes. Avec le sandboxing, elle consiste à exécuter l’échantillon dans un environnement isolé pour observer son comportement. Contrairement à la sandbox de l’antivirus, l’environnement simulé est beaucoup plus large et exécuter sur un laps de temps plus long. Certains éditeurs intègrent de l’intelligence artificielle pour juger du caractère malveillant, ou encore utilisent des techniques de rétro-ingénierie combinées à des IA génératives pour analyser le code. Certaines de ces analyses sont difficiles à reproduire localement (ex : IA).
| source Microsoft | crédit Microsoft |
Une fois l’analyse terminée, si l’échantillon est jugé malveillant, l’éditeur crée une signature. Dans l’option où la détection par signature est inefficace, c’est un jeu de règles comportementales qui sera adopté.
Composants additionnels
De nombreux éditeurs commerciaux ajoutent des fonctionnalités complémentaires : coffres-forts à mots de passe, VPN, navigation sécurisée, etc. Bien qu’utiles pour la vie privée, ces fonctions dépassent le cadre de la réponse aux logiciels malveillants. Elles relèvent davantage de la prévention que de la détection ou de la correction.
EDR
En quoi un EDR va plus loin
À ce niveau, un EDR possède les mêmes briques techniques qu’un antivirus. Mais il va plus loin : il analyse les journaux d’événements système, les actions utilisateur, les modifications système, et centralise toutes ces données sur un serveur d’administration.
L’analyse en mémoire vive
L’analyse de signatures par un EDR peut également se faire en mémoire vive, ce qui permet de détecter des charges utiles injectées ou des malwares sans fichier (fileless malware) actifs dans les processus.
L’analyse des événements
L’EDR lit les journaux d’événements pour détecter des comportements suspects. Par exemple, une série d’échecs d’authentification (1000 en 10 secondes) sur un compte administrateur indique une attaque par force brute. L’EDR peut alors bloquer l’IP source via le pare-feu.
L’analyse de l’utilisateur
Si une menace est liée à l’activité d’un utilisateur, l’EDR peut fermer sa session, bloquer son accès réseau, voire désactiver son compte temporairement. Cela permet d’isoler la source de l’attaque de manière proactive.
L’analyse du système
L’EDR détecte les modifications suspectes de configuration système (comme le registre Windows). Il journalise aussi les opérations sur les fichiers, les créations de processus, etc., enrichissant ainsi l’investigation en cas d’incident.
Le serveur EDR
Le cœur de la solution EDR est souvent son serveur centralisé. Il collecte et corrèle les événements, permettant aux équipes SOC (Security Operations Center) de mener des investigations. Ce serveur peut être intégré à un SIEM pour générer des alertes, enrichir la supervision, ou automatiser certaines réponses. Il permet également de déployer, ajuster ou désactiver les règles de détection à distance. Une autres des fonctionnalités permet le traçage des événements passées. Le serveur EDR conserve un historique permettant une analyse rétrospective. L’analyste est en mesure d’obtenir l’activité du poste. Le serveur peut être capable de corréler une attaque sur divers postes (endpoint) et donner des solutions de remédiation automatique : (isolement du réseau, suppression de fichier malveillant, restauration de fichier si sauvegardes)
| dashboard elasticsearch | crédit Elasticsearch |
Conclusion
Tous les EDR ne se valent pas, et leur fonctionnement différe selon l’éditeur. Avec cet article, vous avez de quoi définir des critères qui vous renseignent sur état de l’art. Vous pouvez retrouver des fonctionnalités décrites au niveau de la section EDR de l’article dans des solutions antivirales. Il n’y a pas de norme pour définir une différence entre une solution antivirale, un EPP ou un EDR. Par contre, vous pouvez être sûr que suivant l’accronyme les prix changent.
Certains logiciels comme Wazuh ou OpenEDR, bien que se revendiquant comme EDR, ne sont pas suffisamment matures dans leur distribution pour être considérés comme tels.
Anecdote : les développeurs de Wazuh ont reclassé leur logiciel comme SIEM (outil de corrélation et d’agrégation d’événements de sécurité). Quant à OpenEDR, il est loin d’être réellement “open” : il nécessite un logiciel serveur (payant et fermé) pour activer toutes ses capacités de détection. La documentation évoque une intégration avec Filebeat vers Elasticsearch, mais celle-ci est incorrecte à cause du format JSON multi-ligne non pris en charge (une obscure configuration existe). Enfin, le projet n’a pas reçu de mise à jour significative depuis trois ans. Cela illustre la fragilité de certains projets EDR open source.
La télémétrie est essentielle à un EDR. Sans détection, il n’y a pas de réponse. Trop de détection et les équipes de SOC subiront des investigations inutiles. La difficulté des solutions de sécurité basées sur la détection d’attaque est d’éviter qu’une alerte se déclenche là où il n’existe aucun incident. Les éditeurs de solution de sécurité ont pour objectif d’éviter le faux positif. Une mauvaise configuration, et l’EDR se retrouve décrier comme laxiste et autoritaire en même temps.
