La phase initiale exige des analystes qu’ils comprennent ce que le capteur EDR a détecté, sans introduire de biais cognitif.
Analyser les métadonnées de l’alerte :
Identifier le nom exact de la détection (ex: “Malicious PowerShell Command”, “LSASS Memory Access”).
Évaluer la sévérité attribuée par l’outil (basse, moyenne, haute, critique).
Déterminer le mécanisme de détection : s’agit-il d’une détection par signature (un IOC connu) ou d’une heuristique comportementale (un indicateur d’attaque - IOA) ?
Identifier les entités impliquées :
Le terminal : nom d’hôte, système d’exploitation, adresse IP. Il est vital de différencier un poste de travail standard d’un serveur d’infrastructure critique.
Le compte utilisateur : le contexte de sécurité sous lequel l’activité a eu lieu. S’agit-il d’un utilisateur de domaine standard, d’un administrateur local ou d’un compte de service hautement privilégié (ex: SYSTEM) ?
Comprendre le contexte d’exécution est l’étape la plus critique du triage EDR. L’arborescence des processus (Process Tree) permet de visualiser les relations parent-enfant ayant conduit à l’alerte.
Les analystes DFIR doivent rechercher des incohérences logiques dans la chaîne d’exécution.
Filiation suspecte (Anomalies)
outlook.exe → winword.exe → powershell.exe(Phishing classique / Exécution de macro)
httpd.exe ou nginx → cmd.exe(Exploitation de serveur web / Web Shell)
services.exe → Rundll32.exe sans arguments légitimes.
Tout binaire non signé générant des outils d’administration système natifs.
Filiation bénigne (Attendue)
explorer.exe → cmd.exe(Un utilisateur lance manuellement une invite de commande)
services.exe → SCCM_agent.exe → update.exe(Déploiement logiciel légitime via un outil de gestion de parc)
Connexions réseau : le processus signalé a-t-il initié des connexions réseau sortantes ? Si oui, interrogez l’adresse IP de destination sur des flux de Threat Intelligence. Vérifiez si la connexion a été bloquée par le pare-feu périmétrique ou établie avec succès.
Opérations sur les fichiers et le registre : le processus a-t-il déposé des fichiers exécutables dans des répertoires inscriptibles par tous (ex: C:\Users\Public\ ou %TEMP%) ? A-t-il modifié des clés de registre de persistance (ex: HKCU\Software\Microsoft\Windows\CurrentVersion\Run) ?
En se basant sur les données enrichies, l’analyste doit appliquer l’un des verdicts suivants :
Faux positif (False Positive) : l’activité est totalement légitime et attendue dans le contexte métier spécifique (ex: un administrateur informatique exécutant un script de maintenance connu).
Action : clôturer l’alerte. Créer une règle d’exclusion granulaire dans la console EDR pour prévenir la fatigue d’alerte à l’avenir.
Vrai positif - Bénin (True Positive - Benign) : un utilisateur a effectué une action inhabituelle mais non malveillante ayant déclenché une règle heuristique (ex: un développeur exécutant manuellement whoami ou nmap à des fins de test).
Action : clôturer l’alerte. Facultativement, contacter l’utilisateur pour confirmer l’activité et rappeler les politiques de sécurité.
Vrai positif - Malveillant (Incident) : l’analyse révèle une filiation de processus anormale, des lignes de commande offusquées, et/ou des IOCs malveillants confirmés.
Action :ne pas clôturer l’alerte. Isoler immédiatement l’hôte (Network Containment) via l’EDR. Escalader l’alerte en incident de sécurité formel et déployer le playbook de réponse approprié, tel que le Playbook d’Investigation de Ransomware ou le Playbook d’Exfiltration Interne.