Quand on installe son premier EDR (ou quand on arrive dans une équipe qui en a déjà un), on se prend souvent une claque. Pas parce que l’outil est compliqué. Mais parce que le flux d’alertes ressemble à un robinet ouvert à fond.
Et du coup, on fait n’importe quoi. On clique partout. On traite les trucs faciles. On ignore ce qui semble « bruyant ». Ou on ferme des alertes parce que « ça a l’air d’un faux positif ». Alors que non. Parfois, c’était la seule alerte vraiment critique de la journée.
L’idée de cet article, c’est de te donner un ordre de priorité simple, réaliste, utilisable dès le début. Pas un guide de SOC niveau enterprise. Un truc de terrain.
Objectif : savoir quoi regarder en premier, quoi escalader, quoi isoler, et quoi mettre de côté sans se mentir.
Ce que ton EDR te dit vraiment (et ce qu’il ne te dit pas)
Un EDR, c’est un capteur + une logique de détection + un moteur de réponse. Il voit des événements sur l’endpoint : création de processus, connexions réseau, accès registre, chargement de DLL, tâches planifiées, tentatives d’élévation, etc.
Mais un EDR ne lit pas dans les pensées. Il ne « sait » pas si l’utilisateur est malveillant. Il émet des alertes sur des patterns. Donc, oui, il y a des faux positifs. Oui, il y a aussi des vrais positifs déguisés en trucs banals.
Au début, ton job ce n’est pas d’être parfait. C’est d’éviter de rater les signaux qui comptent.
Tri rapide : les 4 questions à te poser sur chaque alerte
Avant de rentrer dans des détails, garde ce mini filtre. Même si tu es stressé, même si ça sonne de partout.
- Est ce que ça touche un compte à privilèges (admin local, domaine, service account sensible) ?
- Est ce que ça ressemble à de la persistance (tâche planifiée, run key, service, WMI, startup folder) ?
- Est ce que ça ressemble à un vol d’identifiants (LSASS, dump, accès mémoire, outils type mimikatz) ?
- Est ce que ça parle à Internet de façon louche (C2, IP inconnue, DNS bizarre, connexion sortante inhabituelle) ?
Si tu as « oui » à une seule de ces questions, tu ne mets pas ça en bas de pile.
Priorité 1 : tout ce qui ressemble à du credential access (vol d’identifiants)
C’est vraiment le haut du panier. Parce que si l’attaquant récupère des identifiants, l’incident change d’échelle. On ne parle plus d’un poste infecté. On parle de mouvement latéral, de domaine, de serveurs, de sauvegardes. Et du fameux scénario ransomware.
Alertes typiques à traiter immédiatement
- Accès anormal à LSASS (lecture mémoire, handle suspect)
- Dump de processus, création de fichiers type
.dmp - Commandes ou outils connus :
procdump,comsvcs.dll,rundll32avec des arguments suspects - Accès à
C:\Windows\NTDS\(si c’est un contrôleur de domaine, c’est rouge vif) - Tentative d’export de credentials navigateurs (Chrome, Edge), ou DPAPI usage suspect
Actions recommandées, simples mais efficaces
- Isoler la machine du réseau (si tu as la main via l’EDR)
- Prévenir tout de suite un référent (prof, tuteur, admin senior, ou l’équipe sécu)
- Collecter : arbre des processus, commande exacte, hash, utilisateur, IP de destination, timeline
- Lancer une rotation de mots de passe si un compte sensible est impliqué (au moins, mettre en surveillance + reset ciblé)
Si tu es en contexte BTS et lab, entraîne toi à retrouver la chaîne : processus parent, child, arguments, puis activité réseau. C’est un super exercice. Sur BTS SIO2 SISR Tech Lab (https://sio1blog.blogspot.com/), tu peux te faire une checklist d’analyse et la garder sous la main.
Priorité 2 : persistance (parce que si ça reste, ça revient)
La persistance, c’est ce que l’attaquant met en place pour revenir après un reboot, après une suppression, après un nettoyage partiel.
Au début, on sous estime souvent ces alertes. On se dit « on verra demain ». Mauvais plan. C’est justement ce qui transforme un incident en feuilleton.
Alertes de persistance très fréquentes
- Création ou modification de tâche planifiée
- Ajout de clé registre
Run/RunOnce - Création d’un service Windows avec binaire dans un chemin bizarre (AppData, Temp)
- WMI event subscription
- Fichier déposé dans
StartupouProgramDataavec nom random - Installation silencieuse d’un agent « légitime » mais inattendu (remote admin tool)
Comment décider vite si c’est légitime
- Le binaire est il signé ? Par qui ?
- Le chemin est il standard ? (Program Files vs AppData)
- Le nom de la tâche a t il du sens ? (ex :
AdobeUpdatevsUpdate_39281) - Est ce que ça a été déployé en masse par IT (SCCM, Intune) ou sur une seule machine ?
- L’utilisateur est il en train d’installer quelque chose ?
Actions
- Bloquer / quarantaine du binaire si suspicion forte
- Snapshot des éléments de persistance (nom, chemin, commande, date)
- Vérifier si la même persistance existe ailleurs (recherche par hash, nom de tâche, IoC)
Priorité 3 : exécution suspecte via LOLBins (outils Windows détournés)
Les LOLBins, ce sont les binaires légitimes Windows utilisés comme outils d’attaque. C’est l’enfer des débutants, parce que ça ressemble à du normal. Sauf que non.
Ceux que tu verras tout le temps
powershell.exe(surtout avec-enc,IEX,DownloadString)cmd.exeavec chaînes longues, obfuscationwscript.exe/cscript.exemshta.exerundll32.exeregsvr32.exebitsadmin.execertutil.exe(download, decode)
Ce qui doit te faire lever un sourcil
- Command line obfusquée, base64, caractères bizarres
- Processus lancé depuis Word, Excel, Outlook, navigateur
- Téléchargement vers
AppData\RoamingouTemp - Connexion sortante juste après l’exécution
Actions
- Remonter au processus parent (souvent la clé)
- Isoler si chaîne typique phishing macro
- Extraire l’URL ou l’IP contactée
- Mettre en blocage (hash, domaine) si confirmé
Priorité 4 : comportements ransomware (là, tu n’attends pas)
Certains EDR déclenchent des alertes explicites « ransomware behavior ». D’autres te montrent juste des symptômes : un process qui touche des centaines de fichiers rapidement, suppression de shadow copies, chiffrement.
Indicateurs qui doivent passer devant tout le reste
- Suppression des shadow copies :
vssadmin delete shadows - Désactivation services de sauvegarde, arrêt Veeam, etc.
- Volume anormal de rename / write sur fichiers utilisateurs
- Extension de fichiers qui change en masse
- Tentative de désactiver l’antivirus / EDR
Actions immédiates
- Isolation réseau sans discuter
- Prévenir, escalader
- Identifier le compte utilisé, stopper session si possible
- Vérifier propagation : autres endpoints qui montrent le même pattern
Priorité 5 : accès distant et mouvement latéral
Là aussi, au début, on confond vite admin légitime et attaque. Pourtant, certains patterns sont vraiment suspects.
Ce que tu surveilles
- Connexions RDP à des heures bizarres, depuis un poste utilisateur
psexec,wmic,winrm,schtasksà distance- Création de services à distance
- Authentication failures en rafale, puis succès (bruteforce ou password spraying)
Actions
- Identifier source et cible
- Vérifier si c’est un admin qui bosse (ticket, changement planifié)
- Si non justifié : isolation de la source, reset des identifiants, hunting sur autres machines
Priorité 6 : alertes « malware détecté » simples (oui, parfois ce n’est pas le plus urgent)
C’est contre intuitif, mais une détection malware nette et bloquée n’est pas toujours le plus critique, si elle est contenue.
Ce que tu dois vérifier quand même :
- Est ce que c’est bloqué ou juste « détecté » ?
- Est ce que le fichier a été exécuté ?
- Est ce qu’il y a eu activité réseau après ?
- Est ce que ça a déposé de la persistance ?
Si c’est juste un download bloqué dans le navigateur, ça peut passer après les alertes credential access ou persistance. Mais tu le traites, juste dans le bon ordre.
Priorité 7 : Évasion antiforensique
Il est important d'être vigilant face aux techniques d'évasion antiforensique utilisées par les attaquants. Ces méthodes peuvent rendre l'analyse post-incident plus difficile et permettre aux attaquants de dissimuler leurs traces.
Les alertes souvent bruyantes (à trier, pas à ignorer)
Quelques catégories te polluent, surtout au début :
- PUP / adware
- Outils d’admin : TeamViewer, AnyDesk, PsExec (selon l’entreprise)
- Scripts PowerShell d’IT internes
- Scans réseau internes (monitoring, inventaire)
Le piège, c’est de tout mettre en « faux positif » et d’arrêter de regarder. Le bon réflexe, c’est de créer une base de légitimes : quels serveurs lancent quels scripts, quels admins utilisent quels outils, à quelles heures, avec quels paramètres.
En clair : tu construis ta normalité.
Une méthode concrète pour débuter : la pile « 15 minutes »
Si tu n’as pas de process SOC, tu peux t’en fabriquer un petit, juste pour tenir.
1. Les 5 premières minutes : décider si tu isoles
- Vol d’identifiants ? Persistance ? Ransomware ? Mouvement latéral ?
- Si oui : isolation.
- Si non : tu continues l’analyse.
2. 5 minutes suivantes : comprendre la chaîne
- Processus parent -> enfant
- Command line complète
- User + machine + contexte (poste user, serveur, DC)
- Réseau : où ça parle ?
3. Dernières 5 minutes : documenter proprement
- Capture des éléments clés (hash, URL, chemins, timestamps)
- Statut : confirmé / suspect / faux positif
- Action : isolé / bloqué / en attente / escaladé
Ce format, tu peux le mettre en fiche et l’utiliser en TP. Et si tu veux, tu peux en faire une version « fiche reflexe EDR » et la publier sur BTS SIO2 SISR Tech Lab (https://sio1blog.blogspot.com/) pour la retrouver avant les exams E4 E5 ou un stage. Franchement, ça sert.
Conclusion : au début, il faut surtout éviter les mauvaises priorités
Un EDR qui alerte beaucoup n’est pas forcément un mauvais EDR. C’est juste qu’il te montre la réalité. Et la réalité, c’est bruyant.
Ta priorité, c’est :
- Credential access
- Persistance
- LOLBins et exécution suspecte
- Ransomware behavior
- Mouvement latéral
- Malware simple et contenu
Le reste, tu le traites. Mais tu ne laisses pas les alertes critiques se noyer dans le bruit.
Si tu veux, je peux aussi te proposer une checklist prête à copier coller (format tableau) pour chaque type d’alerte, avec « quoi vérifier », « quoi collecter », « quoi faire ». Ça se glisse bien dans un article ou une page ressource sur BTS SIO2 SISR Tech Lab.
Questions fréquemment posées
Qu'est-ce qu'un EDR et comment fonctionne-t-il ?
Un EDR (Endpoint Detection and Response) est un outil de cybersécurité combinant un capteur, une logique de détection et un moteur de réponse. Il surveille les événements sur les endpoints tels que la création de processus, connexions réseau, accès au registre, chargement de DLL, tâches planifiées ou tentatives d'élévation. L'EDR détecte des patterns suspects mais ne peut pas déterminer si un utilisateur est malveillant, ce qui peut générer des faux positifs.
Pourquoi le flux d'alertes d'un EDR peut-il être déroutant pour un débutant ?
Le flux d'alertes d'un EDR ressemble souvent à un robinet ouvert à fond, avec de nombreuses alertes en continu. Cela peut submerger un débutant qui risque alors de traiter uniquement les alertes faciles, ignorer celles qui paraissent bruyantes ou fermer des alertes suspectées comme faux positifs, alors que certaines peuvent être critiques.
Quelles sont les 4 questions essentielles à se poser pour prioriser une alerte EDR ?
Pour trier rapidement une alerte, il faut se demander : 1) Est-ce que cela touche un compte à privilèges ? 2) Est-ce que cela ressemble à une tentative de persistance ? 3) Est-ce que cela évoque un vol d'identifiants ? 4) Est-ce que cela communique de façon suspecte avec Internet ? Si la réponse est oui à une seule question, l'alerte doit être traitée en priorité.
Pourquoi les alertes liées au vol d'identifiants sont-elles prioritaires dans la gestion des incidents ?
Les alertes concernant le credential access sont critiques car si un attaquant récupère des identifiants, il peut étendre son attaque au mouvement latéral sur le réseau, affecter le domaine entier, les serveurs et les sauvegardes. Cela augmente considérablement la gravité de l'incident et peut mener à des scénarios comme le ransomware.
Quelles actions simples mais efficaces recommander après une alerte critique sur le vol d'identifiants ?
Il est recommandé d'isoler immédiatement la machine concernée du réseau via l'EDR si possible, prévenir un référent ou l'équipe sécurité rapidement, collecter toutes les informations pertinentes (arbre des processus, commandes exactes, hashes, utilisateur impliqué, IP destination), et lancer une rotation des mots de passe pour tout compte sensible touché.
Comment s'entraîner efficacement à analyser les alertes EDR en contexte éducatif ?
En contexte BTS SIO2 SISR Tech Lab par exemple, il est conseillé de s'exercer à retracer la chaîne complète d'une alerte : identifier le processus parent et enfant, analyser les arguments utilisés puis examiner l'activité réseau associée. Cela permet de mieux comprendre la nature des alertes et affiner ses compétences en gestion des incidents.
0 Commentaires