Cybersécurité : comment un EDR se protège des attaques

L’EDR fait partie des solutions qui permettent d’assurer la protection des postes de travail et des serveurs, et pour des raisons évidentes, les attaquants vont chercher à le contourner voire le “tuer” pour parvenir à leurs fins (demande de rançon, vol de données, espionnage...).

De quelles façons ? Et comment un EDR s’auto-protège ? Explications.

Les espaces dans lesquels les attaquants peuvent intervenir pour mettre un EDR hors service

L’espace utilisateur

C’est dans cet espace que la majorité des actions des utilisateurs se déroulent, et c’est aussi l’espace le plus accessible pour les attaquants.

L’espace noyau

Le noyau est beaucoup plus protégé que l’espace utilisateur. Il est ainsi plus difficile à atteindre car il nécessite d’avoir beaucoup de droits pour y accéder, et les systèmes d’exploitation (OS), notamment Windows, ne permettent pas d’y charger n’importe quels éléments.

“Le marché de l'EDR et des solutions de cybersécurité en général se développe, de plus en plus d'entreprises et d’organisations sont équipées. Etant donné qu’il est de plus en plus rare de tomber sur des parcs informatiques non protégés, le taux de réussite des attaques chute. Et comme les attaquants veulent parvenir à leurs fins, le noyau est de plus en plus souvent visé.”
Benoit Maïzi, Ingénieur en Cybersécurité - HarfangLab

Comment un attaquant peut tenter de passer outre un EDR

Un EDR permet de détecter des événements sur un système grâce à des sondes qui les remontent dans les moteurs de détection, et sur la base desquels des règles peuvent être établies en vue de déclencher une alerte ou bloquer un processus. Si l’attaquant parvient à bloquer ces sondes en espace utilisateur ou noyau, les événements ne peuvent pas remonter ni générer d’alerte.
Ainsi, un attaquant peut chercher à empêcher un EDR de détecter les événements susceptibles de déclencher une alerte, en bloquant les sondes.

Dans un espace utilisateur, les événements peuvent être interceptés par exemple en contournant le hooking userland.

Le hooking userland est la méthode employée par les solutions de sécurité pour intercepter les événements système en espace utilisateur. En contournant hooking userland, l’attaquant va chercher à empêcher les solutions de sécurité d'intercepter les événements qui permettent de faire de la détection.

Sur Windows, les attaquants peuvent aussi tenter de contourner l'AMSI (Antimalware Scan Interface) ou l’ETW (Event Tracing for Windows), voire auditd sur Linux et Endpoint Security pour macOS. Mais cette tactique est risquée car ils peuvent être repérés du fait que le code à exécuter dans ce cas est très spécifique, et il peut être détecté par des règles à base de signatures (telles que YARA) si le fichier effectuant l'action est déjà connu, ou des règles comportementales (telles que Sigma).

“Depuis le début des années 2020, les attaques visent de plus en plus les noyaux – Windows en particulier -, et ces attaques ne sont plus seulement perpétrées par des attaquants avancés. Des attaquants plus basiques se tournent aussi vers ces tactiques, obligeant les éditeurs à se renforcer dans ce sens.”
Benoit Maïzi, Ingénieur en Cybersécurité - HarfangLab

Comme nous l’avons indiqué plus tôt, l’espace noyau est beaucoup plus protégé que l’espace utilisateur et donc plus difficile à atteindre, mais cela étant dit, si un attaquant parvient à s’y introduire, son champ d’action est très étendu.

Il peut alors tenter de :

désactiver l'EDR – mais avec un risque très élevé d’être repéré, d’autant qu’un EDR est conçu pour redémarrer automatiquement ;
empêcher l'EDR d'intercepter les événements du système (création de processus, de threads, modification dans le registre, sur le système de fichiers...).
Le fait d'empêcher l'EDR d'intercepter les événements du système est particulièrement sournois car contrairement à une attaque marquée par un incident (endpoints hors service, message de demande de rançon...), le SI va continuer à fonctionner, donnant l'impression à l'organisation que tout est "normal".

Dans tous les cas, quelle que soit la stratégie employée par l’attaquant, l’EDR doit être en mesure de se protéger pour rester actif et assurer la sécurité d’un parc informatique.
Voyons maintenant comment fonctionne l’auto-protection de l’agent pour l’EDR d’HarfangLab.

EDR : comment fonctionne l’auto-protection de l'agent

La protection de l’EDR d’HarfangLab est assurée via son propre driver qui intercepte tous types d'accès à son processus et aux fichiers associés à l’EDR, et qui vérifie si ce processus est légitime ou non.
Pour une protection optimale, le cas où l’utilisateur est administrateur de sa propre machine est prévu : même administrateur de son poste, un utilisateur ne peut pas supprimer l'EDR.

Pour sécuriser le noyau, des sondes sont déployées afin d’identifier la présence éventuelle de composants tiers qui essaieraient d’altérer les capacités de détection, et alerter le cas échéant.

Comme nous l'avons souligné précédemment, un OS ne permet pas d’exécuter tout et n’importe quoi dans le noyau, l’exécutable doit préalablement être reconnu. C’est un frein pour les attaquants qui ne sont pas censés pouvoir créer leur propre code et le charger où ils le souhaitent, contrairement à Linux, par exemple.
Mais là encore, ils cherchent la faille, ce qui nous amène au sujet des drivers vulnérables.

Les drivers vulnérables : à la base des attaques de noyaux

Composant important dans un noyau, le driver est un binaire qui peut être l’objet d’attaques s’il est identifié comme vulnérable. Pour faire face à cette menace, des listes de drivers vulnérables sont maintenues par les éditeurs de solutions de sécurité et la communauté Open Source, afin d’adapter les politiques et bloquer ce qui a besoin de l’être.

Etant donné que les attaquant ne peuvent pas charger leur propre driver, ils utilisent les vulnérabilités comme moyen accès au noyau, pour tenter d'attaquer les solutions de sécurité et charger leur propre code. Ainsi, le driver vulnérable reste un chemin bien connu et volontiers emprunté. En effet, s’ils arrivent à identifier un driver qui n’est pas présent dans la liste de blocage, ou si la liste n’est pas configurée en bloquante, ils tenteront une attaque dite “Bring Your Own Vulnerable Driver”.

Concrètement, les attaquants qui auront accédé à une machine via un binaire malveillant qu’ils auront exécuté, vont ensuite chercher à charger un driver qui va permettre d'augmenter leurs privilèges sur le système infecté, et de mettre en défaut les solutions de sécurité présentes. Ce procédé devient de plus en plus populaire, et le développement de l’écosystème Open Source permet par ailleurs à des attaquants moins avancés d’accéder à ces méthodes contre lesquelles les EDR se protègent également.

En conclusion, les attaquants peuvent tenter d’intervenir dans deux espaces : utilisateur et noyau, pour tenter de supprimer des fichiers, tuer le processus de l'EDR, altérer ses communications avec son manager, l’empêcher d’assurer ses fonctions de détection et d’alerte...
Dans tous les cas, l’agent est prévu pour s’auto-protéger :