Comment fonctionne un EDR ?

Chaque jour, les attaques informatiques se font de plus en plus nombreuses et plus élaborées. Pour se défendre, les entreprises ont adopté un arsenal aussi diversifié que complexe. L’un des outils de ces dernières années à avoir fait son apparition dans cet arsenal est l’EDR (Endpoint Detection and Response). Nous allons dans cet article tenter de vous présenter le fonctionnement interne cet outil afin de comprendre pourquoi l’EDR est aujourd’hui devenu un indispensable.

/!\ Cet article aborde le fonctionnement général d’un EDR et non le fonctionnement d’une solution EDR en particulier

Introduction

Un EDR (Endpoint Detection and Response) est une solution de sécurité que l’on installe sur des points d’accès connectés à un réseau (postes de travail, serveurs, etc..) afin de détecter les menaces potentielles et y répondre en temps réel. Il est conçu d’une part pour détecter les activités suspectes et les anomalies d’exécution mais également pour bloquer les attaques et les tentatives de compromission.

Un EDR est généralement géré à distance via une console d’administration centralisée. Les alertes et les événements enregistrés par l’EDR sont envoyés à cette console et pourront servir à des fins d’investigation ou faire l’objet d’analyses complémentaires.

L’EDR permet de détecter des activités malveillantes qui peuvent ne pas être détectées par un antivirus. Contrairement à d’autres outils qui interviennent avant l’infection (pré-infection), l’EDR se distingue par sa capacité à réagir même après l’infection (post-infection). Il inclut généralement des outils d’analyse, de confinement et de réponse automatique ou manuelle (mise en quarantaine, annulation des modifications, restauration de fichiers, etc.).

Un EDR est souvent composé de plusieurs services et modules. Chaque composant ayant une fonction bien définie. Un composant peut par exemple servir à collecter des informations du système, faire tourner des algorithmes de détection ou encore à permettre la mise en place de mesures de blocage. À titre d’exemple, voici comment l’on pourrait schématiser les différents modules et services d’un EDR :

Parmi les composants de l’EDR, l’on va retrouver des moteurs de détection. Ce sont des services qui vont analyser différents événements en temps réel et déterminer grâce à des modèles mathématiques et logiques si les événements observés correspondent à la manifestation d’un comportement malveillant. Cette détection va généralement générer une alerte sur la console d’administration, accompagnée des informations nécessaires pour la contextualiser.

Dans la suite de cet article, nous allons donc essayer de comprendre comment fonctionne les différents moteurs de détection et les différent modules utilisés par un agent pour surveiller l’activité du système et répondre aux tentatives de compromission du point d’accès.

Moteurs de détection statiques

L’analyse statique consiste à retrouver des caractéristiques communes entre des fichiers malveillants d’une base virale avec un fichier inconnu à analyser. On peut distinguer 2 types d’analyse statique :

Analyse par signature

La détection basée sur la signature est l’une des techniques courantes et traditionnelles utilisées par les logiciels antivirus pour identifier les fichiers malveillants. L’analyse consiste à comparer le fichier analysé à une base de données de signatures connues. En cas de correspondance, la donnée est considérée comme malveillante.

Analyse heuristique

La détection basée sur l’heuristique utilise l’apprentissage automatique pour trouver des indicateurs de malveillance. Un indicateur de malveillance est un ensemble de caractéristiques qui permettent de conclure qu’une donnée ou un fichier est malveillant. L’objectif de l’analyse heuristique est donc de trouver des propriétés constantes et suspectes dans l’élément à analyser.

Analyse de fichiers

L’EDR possède généralement un service d’analyse de fichier qui va à la fois utiliser le moteur d’analyse par signature et le moteur d’analyse heuristique pour tenter d’évaluer la dangerosité du fichier :

Signature présente dans la base virale
Ligne de code suspecte
Suite d’octets malveillant
Entropie anormale
Présence de chiffrement
Usage de privilèges inhabituels
Usage de fonctionnalités inhabituels,
etc…

L’analyse de fichier peut être lancée à chaque manipulation de fichier sur le disque (création, ouverture, modification, suppression). Un logiciel EDR peut également donner la possibilité d’effectuer un scan de l’ensemble du système de fichiers de la machine.

Contrairement à un logiciel antivirus, un EDR n’a pas besoin d’effectuer des scans réguliers du système de fichier. En effet, une fois l’EDR installé, chaque manipulation de fichier sera analysée (ce qui inclus les téléchargements).

Analyse mémoire

Scanner la mémoire des processus à la recherche de signatures malveillantes est peut-être la technique la plus triviale utilisée pour contrer les logiciels malveillants résidant dans la mémoire. En analysant périodiquement la mémoire des processus, un EDR est capable de détecter des valeurs ou des structures caractéristiques de charges malveillantes. À noter néanmoins que cette approche devient très consommatrice de ressources à mesure que le nombre de processus augmente.

En parallèle, L’EDR peut également fournir aux applications une interface de scan mémoire en temps réel. Cette fonctionnalité permet à des processus de faire analyser de la données dynamiquement à la solution de sécurité. Ainsi le processus peut « s’assurer » de la non dangerosité des données qu’il manipule en mémoire. Cela permet également à l’EDR de récupérer des informations supplémentaires sur les traitements effectués par certaines applications et services.

Sur Windows, un EDR peut utiliser l’interface AMSI (Antimalware Scan Interface) pour permettre la mise en place de la fonctionnalité. AMSI est généralement utilisée par Powershell, Wscript, Cscript, JavaScript, VBScript et VBA. C’est notamment ce qui va permettre à l’EDR de voir les commandes exécutées dans les différents scripts malgré l’offuscation.

Moteurs de détection comportementale

L’analyse comportementale d’un programme consiste à analyser son fil d’exécution. C’est à dire les différentes actions et interactions que va entreprendre le programme dans le temps:

Modification de la configuration du système
Appels de fonction
Appels systèmes
Manipulation de fichiers
Connexions distantes suspectes
Événements
Etc…

Certains moteurs de détection comportementale ont été entraîné sur un ensemble de malwares via du machine learning pour identifier des suites d’événements malveillants.

Analyse des journaux d’événements

Par défaut, les systèmes d’exploitation enregistrent divers événements dans des journaux d’événements. Ces journaux permettent notamment aux administrateurs système de surveiller et analyser les événements importants.

Un EDR peut être amené à surveiller différents journaux d’événements afin de détecter des séries d’événements suspects qui pourraient être la manifestation d’une infection potentielle du système.

Sur Windows, ETW/ETW-Ti. (Event Tracing for Windows) fournit aux développeurs un ensemble de fonctionnalités de suivi des événements. Les processus fonctionnant avec le niveau de protection PPL-Antimalware (fournisseurs de sécurité reconnus par Microsoft et disposant des certificats de signature appropriés) peuvent intercepter les événements générés par le noyau. Ce type d’implémentation rend toute tentative de contournement assez difficile. En effet les opérations fondamentales de gestion de la mémoire (allocation/écriture dans la mémoire, modifications de masque de protection, etc…) requises pour tout type d’injection sont surveillées.

Mode Utilisateur | Hooking

Pour rendre possible l’analyse comportementale d’un programme, l’on peut faire appel au « hooking« .

Le « hooking » est une technique permettant d’intercepter les appels de fonction d’un programme. Le code qui intercepte et analyse ces appels de fonction est appelé un hook ou proxy. Il est généralement mis en œuvre en modifiant et injectant des DLLs dans un processus. Ils vont agir comme des passerelles entre les programmes et les APIs du Système d’exploitation.

La majorité des programmes utilisent des fonctionnalités du système d’exploitation accessibles via des DLLs. Chaque solution EDR injecte sa propre DLL (ex: EDR.dll) à chaque création de processus afin d’intercepter les appels API vers le système d’exploitation.

Pour effectuer cette interception, les EDR modifient la DLL d’origine en mémoire afin de rediriger les appels vers des fonctions proxy localisées dans EDR.dll. Les fonctions proxy à l’intérieur de EDR.dll sont chargées d’analyser les paramètres de la fonction d’origine pour juger de la malveillance de l’appel. La fonction proxy peut ensuite décider de poursuivre l’exécution de la fonction d’origine ou de tuer le processus et de générer une alerte.

Le chargement des DLLs de hooking dans les processus est possible grâce à l’injection. L’injection consiste à charger du code ou des dlls dans la mémoire d’un programme en cours d’exécution.

L’une des dlls les plus souvent « hooked » sur Windows est NTDLL ( Windows Native API ) :

Hooking de NTDLL.DLL via EDR.DLL sur Windows

Il existe plusieurs techniques pour passer au travers du mécanisme de hooking des EDRs. C’est pour cette raison que les EDR implémentent des méthodes pour surveiller ce qui se passe dans le noyau du système d’exploitation.

Mode Noyau | Hooking

Tout comme pour le mode utilisateur. Il est possible de faire du hooking en mode noyau. Pour cela 2 méthodes existe :

Hooking de la table d’appels système

Windows et Linux possèdent des tables situées dans la mémoire du noyau. Ils contiennent des informations sur les routines système disponibles pour les programmes et les pilotes. Lorsqu’un programme/pilote fait appel à une fonction système, le système d’exploitation consulte la table d’appels système pour trouver l’adresse de la fonction correspondante dans la mémoire du noyau.

Syscall Table — Mécanisme de table d’appels système

Un EDR peut modifier les entrées de la table d’appels système pour les rediriger vers une fonction proxy (hook) dans un pilote noyau (kernel driver). La fonction proxy va analyser les paramètres de l’appel d’origine pour juger de sa malveillance et peut ensuite décider de poursuivre l’exécution de la fonction d’origine ou d’appliquer des actions de blocage.

Syscall Table Hooking — Redirection d’appel système

Sur Windows le mécanisme de « table d’appels système » est appelé SSDT (System Service Dispatch Table), sur Linux il porte le nom de SCT (System Call Table).

Hooking direct du Noyau (Inline Hooking)

Une autre méthode pour intercepter les appels système consiste à modifier directement le code des appels système dans la mémoire du noyau. Cette technique consiste à trouver les adresses de chaque appel système en analysant le code binaire du noyau, puis de modifier le début de chaque fonction pour rediriger l’exécution vers une fonction proxy (hook) située dans un pilote de l’EDR.

Limites

Le hooking marche généralement bien pour les applications en mode utilisateur. En revanche, il peut être plus compliqué à utiliser en mode noyau. Sur Windows, il existe une fonctionnalité des éditions x64 appelé PatchGuard (PG) qui offre une protection contre la mise à jour du noyau du système d’exploitation et notamment la mise à jour de la SSDT. Cela peut compliquer l’implémentation de ces méthodes de surveillance.

À noter que ces 2 méthodes nécessitent de changer les permissions au niveau du noyau. La modification de la configuration du noyau engendre un risque élevé de crash et de BSODs. L’implémentation de ces méthodes nécessite également une grande expertise dans la programmation système. Pour ces raisons, un EDR n’implémentera pas obligatoirement ces méthodes de surveillance.

Mode Noyau | Pile d’appels

La pile (stack) est une structure de données qui est utilisée par les programmes pour stocker des informations sur les fonctions en cours d’exécution. Lorsqu’une fonction est appelée, de nouvelles entrées sont ajoutées sur la pile et sont « retirées » de la pile lorsque la fonction se termine.

L’état de la pile à un instant précis de l’exécution d’un programme est appelé pile d’appels (callstack). Un EDR est capable surveiller l’exécution d’un programme en analysant la variation des piles d’appels. Il peut ainsi en déduire quelles sont les fonctions qui ont été appelées, leurs adresses de retour dans la mémoire et certains des paramètres passés. Cette trace d’exécution est ensuite envoyée à différents moteurs de détection.

En outre, l’analyse de la pile d’appels est une complément au hooking (que l’EDR peut utiliser en mode utilisateur ou en mode noyau) pour détecter les appels système indirects ou les tentatives de contournements hooking de l’EDR. Il est ainsi possible de voir si le processus est arrivé à l’appel système en utilisant une API Windows de haut niveau (ex: CreateThread depuis KERNEL32 ) ou en utilisant directement les appels natifs (ex: NtCreateThreadEx depuis NTDLL).

– Si aucune trace dans la pile d’appels n’est située dans KERNEL32 avant d’arriver à NTDLL, on est potentiellement face à un appel système indirect.

– Si aucune trace dans la pile d’appels n’est située dans la DLL de l’EDR avant d’arriver à NTDLL, on est potentiellement face à un contournement du hooking mis en place par l’EDR.

Mode Noyau | Fonctions de rappel

Pour surveiller ce qu’il se passe au plus bas niveau du système d’exploitation, il est souvent possible d’utiliser des fonctions de rappel du noyau (kernel callbacks). Les fonctions de rappel fournies par le noyau permettent à des pilotes (drivers) d’être notifiés lorsque certaines actions se produisent dans le noyau.

Les fonctions de rappel peuvent être utilisées pour intercepter et modifier le retour des appels système ou les événements de périphériques. Ils peuvent notamment permettre de surveiller la réception de paquets réseau, l’accès aux fichiers ou la création de threads/processus.

Voici quelques fonctions de rappel Windows que l’on peut potentiellement utiliser pour surveiller l’activité du système :

PspCreateThreadNotifyRoutine // Création d"un thread
PspCreateProcessNotifyRoutine // Création d'un processus
PspLoadImageNotifyRoutine // Chargement d'une image
ObRegisterCallbacks  // Opération sur les objets/registres du système

À titre d’exemple, c’est grâce à PspCreateProcessNotifyRoutine que l’EDR est capable de détecter la création d’un nouveau processus et de déclencher le chargement de sa dll à l’intérieur.

Grâce aux fonctions de rappel du noyau il est possible de créer des pilotes spécifiques très utiles à l’EDR :

Pilote Minifiltre

Un pilote minifiltre en mode noyau (ou « minifiltre » en abrégé) est un type de pilote qui s’insère dans la pile de filtres du système de fichiers et qui permet de filtrer ou de modifier les opérations E/S avant qu’elles ne soient exécutées.

Les minifiltres sont utilisés par les EDRs pour implémenter des fonctions de sécurité et surveiller l’activité du système de fichiers. Par exemple, un minifiltre peut être utilisé pour surveiller les tentatives d’accès à des fichiers sensibles afin d’interdire certaines opérations.

Pilote de protocole

Un pilote de protocole un pilote permettant de surveiller le trafic réseau en temps réel. L’EDR peut utiliser ce type de pilote pour surveiller l’activité réseau du système d’exploitation ou bloquer certaines communications réseau.

Analyse bac à sable (sandbox)

Les moteurs de l’EDR ne sont parfois pas suffisants pour déterminer le caractère malveillant d’un programme. Il peut alors être intéressant d’exécuter le programme dans une machine virtuelle appelée sandbox (bac à sable) afin d’observer son comportement. La sandbox a pour but d’analyser et d’identifier les différentes interactions effectuées par le programme, telles que la modification de registres, la création de tâches, la modification de la configuration, les connexions à distance, etc.

L’avantage de la sandbox est que l’on peut suivre l’intégralité de l’exécution du programme sans avoir besoin de bloquer le programme pour protéger le système.

Néanmoins, cette analyse présente quelques inconvénients :

La machine virtuelle ne consacre qu’un temps limité à l’analyse des exécutables. Ainsi si l’exécution est trop longue, l’analyse échouera.
Il est souvent possible de détecter une analyse en sandbox. Un malware peut donc interrompre son exécution de lui même si il constate qu’il a été exécuté dans ce type d’environnement.
Certains appels d’API du système d’exploitation ne peuvent pas être virtualisés avec succès. Dans ce cas, la sandbox ne sera pas en mesure de poursuivre l’analyse du programme.

Mécanisme de mise en quarantaine

Lorsqu’un EDR détecte des fichiers ou des programmes malveillants, il devient nécessaire de les isoler du reste du système. L’EDR les déplace généralement dans un dossier spécifique du système de fichier et va procéder à certaines modifications pour les rendre inoffensifs. L’EDR peut par exemple changer l’extension des fichiers, les mettre dans des archives et/ou les chiffrer. La sortie de quarantaine correspondra alors au processus inverse.

Mécanisme d’exclusion

La surveillance d’un programme par l’EDR peut parfois l’empêcher de fonctionner ou conduire à une perte de performance. En effet, si les appels système sont surveillés et les fichiers manipulés analysés, cela peut ralentir grandement le traitement. Pour cette raison, il peut être intéressant d’indiquer à l’EDR que l’on fait confiance au programme et que l’on ne souhaite pas le surveiller.

Cela est généralement possible grâce à l’utilisation d’une liste d’exclusions (ou whitelist). Cette liste peut contenir un ensemble de fichiers, dossiers ou programmes pour lesquels l’on souhaite désactiver certaines fonctionnalités de l’EDR.

Bien sûr, ces exclusions créent un angle mort pour le logiciel EDR et seront donc une cible de choix pour les attaquants. En effet, en créant un exécutable se faisant passer pour un logiciel qui est dans la liste d’exclusions, ils pourront passer outre certains moteurs de détection de l’EDR.

Mécanisme de self-defense

Au cours de certaines cyberattaques, les acteurs malveillants essaient de désactiver les fonctions de sécurité du sytème. Tout naturellement l’EDR attire généralement l’attention. Désactiver l’EDR leur permettra d’accéder plus facilement aux ressources et de pouvoir lancer leurs logiciels malveillants. Il est donc primordial pour l’EDR de se prémunir des tentatives de désactivation ou de désinstallation. Pour ce faire, les EDRs font usage de mécanismes de protection contre l’altération (protection anti-sabotage) :

Certains systèmes d’exploitation, comme Windows, permettent à certains programmes de bénéficier de ce type de protection nativement. Mais il est également possible pour la solution EDR de mettre en place ses propres protections :

Protection des fichiers sources
Protection contre l’arrêt des processus de l’EDR
Algorithmes tolérants aux pannes
Surveillance de la modification de certaines structures internes du noyau (Kernel Callback, SSDT, PatchGuard)
Surveillance de l’installation de nouveau pilote dans le noyau (Kernel Drivers)
Test en continue de la chaîne de détection pour détecter une potentielle interférence. Par exemple, l’EDR peut lancer périodiquement un programme test pour s’assurer qu’il reçoit bien le callback au niveau kernel et qu’il arrive bien à s’injecter dedans.

Fonctionnalité Anti-ransomware

Les ransomwares font beaucoup parler d’eux ces dernières années. Ces logiciels malveillants ont pour but de chiffrer les données d’une machine le plus rapidement possible pour ensuite demander un rançon en échange de la clé de déchiffrement.

S’il arrive que ce type de logiciel parvienne à passer au travers des moteurs de détection, il pourra être détecté par l’EDR lorsqu’il débutera le chiffrement massif du disque dur. Pour ce faire, les EDR peuvent faire usage de fichiers leurre (decoy files). Ce sont des fichiers créés dans le but de tromper l’adversaire. Ils sont dispersés dans différents emplacements du système de fichier et l’accès à ces fichiers est surveillé. Si un logiciel malveillant vient à chiffrer un de ces fichiers, l’EDR saura immédiatement que ce logiciel tente d’initier un chiffrement massif sur la machine et le bloquera.

Pour améliorer la crédibilité de ces fichiers, leur propriétés et métadonnées peuvent être modifiées ( nom, hash, date de création/modification, taille, propriétaire, etc…).

Fonctionnalité Anti-leak

L’exfiltration des données est sans doute la menace la plus redoutée après le chiffrement des données. Certains EDR peuvent intégrer un mécanisme de détection d’exfiltration de données. Cela se fait généralement via l’usage de fichier canari (canary file).

Un fichier canari est un type de fichier leurre qui est placé parmi des documents réels afin d’aider à la détection d’accès, de copie ou de modification non autorisés. Certains de ces fichiers permettent de détecter de potentielle exfiltrations. En effet, lors de l’ouverture de ces fichiers, une requête sera effectuée vers un serveur central. En fonction de l’adresse IP qui a initié la requête, l’on pourra déduire si oui ou non c’est un accès légitime au fichier.

Le nom Canary vient des canaris, qui étaient utilisés dans les mines de charbon pour alerter les mineurs.

Automatisation & Threat Intelligence

L’un des éléments clé des EDR, c’est la possibilité d’utiliser de la Cyber Threat Intelligence (CTI) pour faciliter le processus de chasse des menaces (Threat Hunting). Grâce à tous les logs récoltés par l’EDR, il est possible de rechercher, sur les différents points d’accès, les traces d’une menace ou d’une potentielle infection (plus communément appelées IOCs). En effet chaque programme laisse des traces de son existence dans le système.

Un IOC (Indicator Of Compromise), soit Indicateur De Compromission en français, est un élément observable sur un point d’accès pouvant confirmer son infection.

Un IOC peut être la signature d’un fichier, une adresse IP, une localisation dans le système de fichier, une suite d’événements, etc..

Comme vous vous en doutez. Un EDR remonte une quantité de logs et d’alertes phénoménale. L’analyse humaine de toutes ces alertes n’est donc pas toujours envisageable. De plus certaines alertes sont bien connues et la réponse à adopter également. De ce fait, il est possible d’automatiser la réponse de l’EDR via des scripts (aussi appelés playbooks) et ainsi décharger les analystes de ces alertes. Cette automatisation de la réponse via des playbooks peut se faire avec un outil appelé SOAR (Security Orchestration Automation and Response). L’acronyme SOAR désigne une technologie servant à optimiser la gestion de solutions de sécurité informatique. Il permet par exemple de prioriser certaines alertes par rapport à d’autres afin d’améliorer l’efficacité des équipes d’analyse. Un SOAR peut s’interfacer avec plusieurs produits de sécurité (EDR, SIEM, pare-feu, base virale, etc..)

Les limites de l’EDR

Bien qu’ils soient très utiles pour protéger les systèmes contre les cyberattaques, les EDR présentent également certains inconvénients, notamment :

Pas tout puissant : Il est malheureusement possible pour des attaquants de contourner les protections des EDR. Cela nécessite néanmoins des prérequis très avancés en programmation système.
Faible couverture : les EDR ne couvrent qu’un certains types de terminaux informatiques. Certains appareils ne seront donc pas compatibles et seront donc des angles morts pour les équipes de sécurité.
Réduction des performances : les EDR peuvent avoir un impact sur les performances des machines sur lesquelles ils sont installés, car ils surveillent en permanence l’activité du système et analysent le comportement de tous les processus. Cela peut ralentir les performances du système, en particulier sur des machines plus anciennes ou des machines qui effectuent beaucoup de traitements à la seconde. À noter également que certains programmes ne supportent pas l’injection et peuvent donc dysfonctionner à cause de l’EDR.
Coût élevé : les EDR peuvent être coûteux, en particulier pour les petites entreprises, car ils nécessitent souvent des licences coûteuses pour chaque périphérique et peuvent également nécessiter des frais de maintenance et de mise à niveau supplémentaires.
Forte complexité : les EDR peuvent être assez complexes à mettre en place et à gérer, nécessitant souvent des compétences spécialisées en cybersécurité pour configurer et maintenir correctement le système.
Confidentialité : les EDR génèrent souvent une grande quantité de données à caractère privée (historique de navigation, historique d’activité système, noms de fichier, etc…). Cela peut représenter un risque pour la confidentialité des données de l’entreprise.
Dépendance à la console : certains EDR nécessitent une connexion Internet active pour fonctionner, car ils communiquent avec la console d’administration pour stocker et analyser les données collectées sur les terminaux. Dans le cas où l’agent EDR n’a pas accès à Internet, cela peut affecter la capacité de l’EDR à fournir une protection efficace. Cependant, certains EDR modernes sont conçus pour fonctionner en mode hors ligne ou en mode dégradé en cas de perte de connectivité Internet.

Sources

icons by https://www.flaticon.com/authors/vectorslab