Teknik - Importance des standards ouverts et présentation d'Open XDR Architecture (OXA)
19 novembre 2025
Parce que... c'est l'épisode 0x698!
Teknik - La guerre Red Team vs EDR - l’aspect technique et non business du problème (c'est la partie 2 BTW)
02 décembre 2025
Parce que... c'est l'épisode 0x692!
Parce que… c’est l’épisode 0x692!
Shameless plug
- 25 et 26 février 2026 - SéQCure 2026
- 31 mars au 2 avril 2026 - Forum INCYBER - Europe 2026
- 14 au 17 avril 2026 - Botconf 2026
- 28 et 29 avril 2026 - Cybereco Cyberconférence 2026
- 9 au 17 mai 2026 - NorthSec 2026
- 3 au 5 juin 2026 - SSTIC 2026
- 19 septembre 2026 - Bsides Montréal
Description
Introduction
Ce deuxième épisode du podcast technique avec Charles F. Hamilton explore en profondeur les techniques d’évasion des solutions EDR (Endpoint Detection and Response) et les stratégies que les red teamers peuvent utiliser pour contourner ces systèmes de détection. La discussion révèle que malgré les avancées technologiques, les EDR restent vulnérables à des techniques relativement simples lorsqu’on comprend leurs mécanismes de détection.
Les limites de la détection EDR
Corrélation réseau et named pipes
Un exemple concret illustre les faiblesses des EDR modernes : un exécutable malveillant qui communique avec internet tout en effectuant de la reconnaissance sur le réseau interne. Les EDR “top tier” détectent généralement cette activité anormale grâce au machine learning, identifiant qu’un processus communique simultanément vers l’extérieur et vers le réseau local via SMB, Kerberos ou d’autres protocoles.
La solution de contournement est élégante : utiliser les named pipes de Windows. Cette fonctionnalité native permet la communication inter-processus. En séparant les tâches entre deux processus indépendants - l’un gérant les communications externes, l’autre la reconnaissance interne - et en les faisant communiquer via named pipes, on brise complètement la chaîne de détection du machine learning. Cette technique, enseignée depuis 8 ans dans les formations red team, demeure efficace.
Des signatures déguisées
Paradoxalement, malgré leurs prétentions, les EDR fonctionnent encore largement sur des principes de signatures. La différence avec les antivirus traditionnels réside davantage dans où ils appliquent cette détection - non seulement sur le disque, mais aussi en mémoire et au niveau comportemental. Le compromis entre faux positifs et détection reste délicat : générer 1500 alertes par jour conduirait à l’“alert fatigue” et rendrait le système inutile.
Techniques d’obfuscation et d’évasion
La randomisation intelligente
Pour éviter la détection statique, l’obfuscation doit être réfléchie. Un piège courant : générer des variables aléatoires de longueur fixe (par exemple, toujours 16 caractères). Les règles Yara peuvent détecter ce pattern. La solution consiste à introduire de la randomness dans le random : utiliser des longueurs variables (entre 6 et 22 caractères) et concaténer plusieurs mots du dictionnaire plutôt que des chaînes purement aléatoires.
Nettoyage de la mémoire
L’obfuscation ne s’arrête pas à l’exécution. Même après déchiffrement en mémoire, des artefacts subsistent. Par exemple, Cobalt Strike laisse des patterns reconnaissables dans les premiers bytes du shellcode. La stratégie recommandée utilise plusieurs threads d’exécution : un pour déchiffrer et lancer le shellcode, un autre pour nettoyer la mémoire des variables intermédiaires. Bien que les EDR ne scannent pas la mémoire en continu (ce serait trop coûteux en performance), ces artefacts restent détectables.
Protection au niveau kernel
Protected Process Light (PPL)
Microsoft a introduit les PPL pour protéger les processus critiques comme LSASS. Même avec des privilèges système, un attaquant ne peut accéder à ces processus. Le problème : le kernel reste le point de confiance ultime. Une fois qu’un attaquant obtient l’exécution de code au niveau kernel - via des drivers vulnérables par exemple - toutes les protections PPL tombent.
Techniques d’anti-tampering
La technique “EDR Freeze” illustre cette réalité : en utilisant ProcDump (un outil Windows légitime), on peut créer un dump mémoire d’un processus EDR, ce qui le met en pause. En arrêtant ensuite ProcDump avant qu’il ne termine, le processus EDR reste indéfiniment en pause, sans générer d’alerte de tampering puisqu’il n’a pas été modifié.
Cloud et nouvelles vulnérabilités
Le passage au cloud déplace simplement les problèmes. Les attaques traditionnelles visaient le “domain admin” en local ; aujourd’hui, avec l’authentification multifacteur, les attaquants utilisent le device code phishing ou des applications tierces malveillantes pour obtenir des tokens OAuth valides. Une fois ces tokens obtenus, l’escalade vers “global admin” devient possible.
La difficulté : aucun EDR ne peut surveiller ces attaques puisqu’elles se déroulent depuis la machine de l’attaquant. La seule visibilité provient de ce que Microsoft accepte de partager, souvent derrière des paywalls supplémentaires. Les entreprises ont passé 20 ans à maîtriser Active Directory et les outils de sécurité on-premise, mais repartent de zéro dans le cloud avec des outils immatures.
Recommandations défensives
Configurations simples mais efficaces
Plusieurs mesures basiques restent sous-utilisées :
- Bloquer PowerShell pour les utilisateurs non techniques
- Désactiver la fonction Run (Windows+R) pour 99% des utilisateurs
- Supprimer MSHTA.exe via GPO (aucun besoin légitime des fichiers HTA)
- Restreindre les scripts Office par défaut
Ces mesures élimineraient la majorité des attaques “commodity malware” qui fonctionnent uniquement parce que les entreprises n’ont pas fermé ces vecteurs d’accès basiques.
Le facteur humain irremplaçable
Les EDR excellent contre le malware de masse mais peinent face aux attaques ciblées. L’IA et les agents ne remplaceront pas les analystes humains capables de :
- Faire du threat hunting actif
- Contextualiser les alertes (pourquoi un utilisateur non technique lancerait-il PowerShell ?)
- Détecter les anomalies dans le trafic réseau (nouveaux domaines, patterns de requêtes POST répétitives)
- Raconter l’histoire complète d’une intrusion en corrélant les événements
Détection réseau
Les NDR/XDR commencent à combler cette lacune, mais restent embryonnaires. La détection réseau devrait identifier :
- Les nouveaux domaines jamais vus auparavant
- Les patterns de communication C2 (requêtes POST régulières avec jitter)
- Les anomalies d’authentification
- Le trafic inhabituel pour un profil utilisateur donné
Conclusion
La sophistication des attaquants reste limitée car ils n’en ont pas encore besoin - trop d’environnements demeurent mal configurés. Les entreprises investissent massivement dans les EDR mais négligent les configurations de base et le facteur humain. L’histoire se répète avec le cloud et l’IA : plutôt que de résoudre les problèmes fondamentaux, on déplace la responsabilité vers de nouveaux outils. La vraie sécurité nécessite une compréhension technique approfondie, des configurations rigoureuses, et surtout, des analystes compétents pour interpréter les signaux et raconter l’histoire des incidents.
Collaborateurs
Crédits
- Montage par Intrasecure inc
- Locaux virtuels par Riverside.fm
Tags: edr, intrusion, malware, red
Tweet
