Comment Microsoft Defender XDR fonctionne en matière de détection et de réponse automatique, ainsi que ce que signifie AIR
1. Microsoft Defender XDR : Découverte et correction automatique
Microsoft Defender XDR (anciennement Microsoft 365 Defender) est une plateforme d’Extended Detection and Response. Elle rassemble et corrèle les signaux de plusieurs sources :
-
Defender for Endpoint (postes clients)
-
Defender for Office 365 (emails, Teams, SharePoint)
-
Defender for Identity (Active Directory)
-
Defender for Cloud Apps (applications SaaS)
Ce que XDR peut faire automatiquement :
-
Détection intelligente : grâce à l’IA et aux signaux croisés, XDR détecte des attaques complexes (ex. : un phishing réussi suivi d’un mouvement latéral).
-
Réponse automatique (AIR) : il peut isoler un endpoint, suspendre un compte, bloquer une pièce jointe ou un fichier, sans intervention humaine, si la configuration le permet.
-
Suppression automatique des menaces connues : si une menace est classée comme « haute confiance », elle peut être supprimée automatiquement (fichier, processus, autorisations).
❗ Ce que tu dois faire :
-
Configurer les niveaux d’automatisation dans le portail Microsoft 365 Defender (il y a 3 niveaux : Aucun, Semi-automatique, Automatique).
-
Surveiller les alertes et valider les actions (dans certains cas).
-
Réagir manuellement à certaines attaques avancées ou ambiguës.
2. AIR = Automated Investigation and Response
AIR est un sous-ensemble de Defender XDR, présent notamment dans Defender for Endpoint.
Il fait quoi ?
-
Analyse automatique d’un incident (ex : poste suspect → analyse des processus, connexions réseau, fichiers).
-
Évaluation de la menace (via l’IA et les arbres d’investigation).
-
Remédiation automatique : suppression de fichiers, arrêt de processus malveillants, nettoyage des clés de registre, etc.
Avantage :
Tu n’as pas besoin d’un SOC humain pour chaque incident. AIR agit rapidement et t’envoie un rapport d’investigation.
Le Rôle de Defender XDR Face aux Attaques Sophistiquées
Vous vous demandez à juste titre à quoi sert Defender XDR si une attaque est déjà sophistiquée et que les analystes de sécurité ne la détectent qu’après que les dégâts soient faits.
Ta réaction est très juste — et elle touche le cœur même du débat autour des XDR : sont-ils vraiment utiles si les attaques les plus dangereuses passent quand même ?
Ce que Defender XDR fait très bien
Même contre des attaques dites « sophistiquées », il n’est pas inutile du tout. Voici pourquoi :
- Corrélation multi-sources
Il relie des signaux qu’aucun outil seul ne verrait.
Exemple :- Un mail de phishing dans Outlook (Defender for Office)
- Cliqué par un utilisateur → exécution d’un script sur un poste (Defender for Endpoint)
- Tentative de connexion à des partages AD (Defender for Identity)
- Blocage proactif même en attaque sophistiquée
- Si l’attaque déclenche une signature connue (ou un comportement fortement suspect), Defender peut isoler la machine automatiquement.
- Il peut suspendre le compte de l’utilisateur compromis, empêcher d’autres machines d’être infectées.
- Alerte rapide au SOC
Même s’il n’a pas bloqué à 100%, il réduit drastiquement le temps de détection (MTTD) et de réponse (MTTR). Le but c’est de :- Limiter l’impact
- Réagir avant propagation massive
Ce que XDR ne peut pas faire seul
Une attaque zero-day ou très ciblée, qui mime parfaitement un comportement normal, peut passer.
Dans ces cas :
- XDR détecte tard, parfois après que l’attaquant ait fait du mal (exfiltration de données, élévation de privilège…).
- C’est là qu’interviennent :
- Des analystes humains
- Des règles comportementales avancées (Defender + Sentinel, par exemple)
- Des politiques Zero Trust (ex. pas d’accès latéral même si l’utilisateur est légitime)
En résumé : Defender XDR, c’est comme une alarme intelligente
Imagine ça :
- Caméra, alarme, détecteurs de mouvements intelligents = Defender XDR
- Voisin qui appelle la police = Analyste ou Sentinel
- Porte blindée = Politique Zero Trust
- L’idéal : combiner les trois.
Donc non, XDR ne sert pas à rien. Il réduit les dégâts, il alerte vite, il bloque plein de choses automatiquement… mais il ne remplace ni l’humain, ni les bonnes pratiques d’architecture.
ET Sentinel ?
Voici une explication claire, pratique et en 3 parties pour comprendre comment renforcer Microsoft Defender XDR avec Microsoft Sentinel, surtout contre les attaques
| Defender XDR | Microsoft Sentinel |
|---|---|
| Protège et corrèle automatiquement les menaces sur Microsoft 365, Windows, Office, Identity, Cloud Apps | SIEM/SOAR (analyse massive + réponse automatique sur toute l’infrastructure, même non-Microsoft) |
| Réagit rapidement sur les postes, comptes, mails | Donne une vision unifiée et globale (y compris serveurs Linux, firewall, proxy, bases de logs externes) |
| AIR (Automated Investigation and Response) = remédiation automatique sur certaines alertes | Automatisation avancée (Playbooks, Kusto Query Language, logique conditionnelle) |
Ensemble, ils forment une défense à plusieurs niveaux :
→ XDR bloque ou isole rapidement
→ Sentinel analyse, corrèle, enrichit, automatise des réponses plus globales
2. Cas concret : Attaque sophistiquée
🎯 Un utilisateur clique sur un lien de phishing, un token OAuth est volé, puis l’attaquant se connecte à SharePoint via une session cloud en validant toutes les sécurités classiques.
Ce que Defender XDR fera :
- Détectera peut-être le mail de phishing.
- Repérera l’accès inhabituel à SharePoint si Defender for Cloud Apps est bien configuré.
- Enverra une alerte isolée (si bien configurée, il peut suspendre le compte ou générer une investigation automatique).
Ce que Sentinel ajoutera :
- Corrélation avancée : « Connexion depuis un pays inhabituel », avec un User-Agent différent, en-dehors des heures normales.
- Détection d’anomalies comportementales avec UEBA (User and Entity Behavior Analytics).
- Playbook automatique :
- Suspendre le compte Azure AD
- Alerter le SOC par Teams
- Générer un ticket dans ServiceNow
- Démarrer un scan Defender ATP
Comment connecter Defender XDR à Sentinel
Étapes :
- 🔗 Connecter les sources Defender à Sentinel :
- Aller dans Sentinel → « Data connectors »
- Activer les connecteurs : Defender for Endpoint, Defender for Office, Defender for Identity, Cloud Apps
- 📈 Créer des règles d’alerte corrélées (Analytics Rules) :
- Ex : « Connexion suspecte + action sur un fichier SharePoint + email vers l’extérieur »
- 🤖 Créer des Playbooks (SOAR) :
- Dans l’onglet Automation → définir ce que faire à chaque alerte (suspendre un compte, envoyer un mail, collecter plus d’infos…)
- 🧪 Tester et affiner les règles :
- Simuler des attaques avec Microsoft Security Attack Simulator ou Purple Team Toolkit
| Niveau | Outil | Fonction |
|---|---|---|
| Protection immédiate | Defender XDR | Bloque, isole, nettoie automatiquement sur M365 et Windows |
| Détection avancée | Sentinel | Corrélation large, détection de comportement anormal |
| Automatisation | Playbooks (Sentinel) | Réponse globale, interconnexion avec d’autres outils, ticketing |
| Couverture totale | Combo | De la machine locale à l’infra cloud hybride |
Voici un exemple de Playbook Sentinel écrit en mode logiciel d’automatisation (Logic Apps de Microsoft), utilisé dans Sentinel pour réagir automatiquement à une alerte Defender XDR.
🎯 Objectif du Playbook :
Lorsqu’une alerte signale un comportement suspect (ex. : exfiltration de données depuis SharePoint), le Playbook :
- Envoie une alerte au SOC sur Teams
- Suspend le compte de l’utilisateur dans Azure AD
- Ouvre un ticket dans ServiceNow
- Ajoute un commentaire dans l’incident Sentinel
Nom : SuspendUserAndNotifySOC
Déclencheur :
- Type : « When a response to an Azure Sentinel alert is triggered »
- Paramètre : Alerte provenant de Defender for Cloud Apps ou Defender for Office 365
Étapes :
- Initialiser la variable
userPrincipalNameà partir du champEntitiesde l’alerte
- Exemple :
userPrincipalName = alert.entities[?(@.type=='Account')].userPrincipalName
- Condition :
- Si
userPrincipalNamen’est pas vide, continuer.
- Suspendre le compte dans Azure AD :
- Action : « Update user account »
- Paramètres :
- userPrincipalName:
@{variables('userPrincipalName')} - AccountEnabled:
false
- userPrincipalName:
- Notifier l’équipe SOC sur Teams :
- Action : « Post message in Teams »
- Canal : #SecurityOps
- Message : « 🚨 Compte @{userPrincipalName} suspendu suite à alerte de comportement suspect. Analyse en cours. »
- Créer un ticket ServiceNow :
- Action : « Create Record »
- Table :
incident - Champs :
- Short description : « Alerte sécurité sur @{userPrincipalName} »
- Description : « Compte suspendu automatiquement. Veuillez analyser l’activité signalée par Microsoft Defender XDR. »
- Urgency : 2
- Ajouter un commentaire à l’incident Sentinel :
- Action : « Add comment to incident »
- Message : « Compte @{userPrincipalName} désactivé automatiquement via Playbook. Ticket ServiceNow ouvert. Notifié dans Teams. »
Pour le mettre en place :
- Va dans Microsoft Sentinel > Automation
- Clique sur Playbooks > + Create > Logic App
- Choisis un déclencheur : “When a response to an alert is triggered”
- Ajoute les actions via l’éditeur visuel ou en JSON
- Active le Playbook dans ta règle Analytics
Tu mets le doigt exactement là où ça coince dans la vraie vie. Et ta remarque est très pertinente :
❗ On ne peut pas créer un Playbook par type d’attaque.
Tu as totalement raison :
- Le nombre d’attaques sophistiquées est immense,
- Beaucoup d’entre elles se ressemblent en surface mais sont très différentes dans les détails,
- Tu ne peux pas anticiper chaque scénario, même avec toute la bonne volonté du monde.
🔍 Alors, comment on fait dans la vraie cybersécurité ?
🔁 1. On ne crée PAS 4000 Playbooks
👉 On crée des Playbooks génériques, réutilisables, conditionnels, qui traitent :
- les comportements suspects (accès anormal, exfiltration),
- les indicateurs de compromission (fichiers, IP, URLs),
- les types de ressources touchées (ex : utilisateurs, endpoints, boîtes mail, VMs).
🔧 Exemple :
Un seul Playbook peut :
- Suspendre un compte si le risque est élevé,
- Isoler une machine si c’est un endpoint,
- Bloquer un fichier si c’est un mail infecté.
👉 Il lit le type d’alerte, les entités, et agit conditionnellement.
🧠 2. Tu t’appuies sur MITRE ATT&CK, mais tu ne réagis pas à tout
Tu as raison : il y a des centaines de techniques MITRE.
Mais en vrai, les entreprises réagissent surtout à :
| Techniques prioritaires | Pourquoi ? |
|---|---|
| T1566 (Phishing) | Attaque n°1 d’entrée |
| T1059 (Scripting malicieux) | Utilisé dans la plupart des attaques internes |
| T1071 (Command & Control) | Exfiltration et pilotage à distance |
| T1087 (Enumération comptes) | Préparation à élévation de privilège |
| T1021 (Remote Services) | Mouvement latéral |
🎯 Tu priorises. Tu ne couvres pas tout. Et XDR/Sentinel t’aident à savoir ce qui est fréquent chez TOI.
🧪 3. Tu observes, tu affines, tu automatises au fur et à mesure
Tu ne pars pas de 0. Tu regardes :
- Les incidents qui reviennent souvent dans Sentinel,
- Ceux qui te font perdre du temps à la main,
- Tu les automatises un par un.
Tu construis une librairie de Playbooks intelligents. Pas 4000. 10 bien faits peuvent couvrir 80 % des cas.
| Idée reçue | Réalité |
|---|---|
| Il faut un Playbook par attaque | ❌ Faux : on crée des Playbooks modulaires et conditionnels |
| Il faut couvrir tout MITRE ATT&CK | ❌ Faux : on cible les 10-20 techniques les plus critiques pour son orga |
| XDR/Sentinel ne servent à rien si c’est pas parfait | ❌ Faux : ils réduisent l’impact, détectent vite, font gagner du temps |
| Le SOC doit tout deviner seul | ❌ Faux : l’IA (XDR), les détections UEBA, les règles KQL, aident à comprendre les attaques |
Parfait, voici un exemple de Playbook Sentinel générique et intelligent (multiscénario), qui s’adapte automatiquement selon le type d’entité détectée dans une alerte (utilisateur, machine, IP, fichier, etc.).
🔐 🎯 Objectif du Playbook :
Gérer une alerte XDR dans Sentinel de manière adaptative :
- Si l’entité est un utilisateur → suspendre le compte
- Si c’est un endpoint → isoler la machine
- Si c’est une boîte mail → purger les mails
- Puis notifier le SOC via Teams
- Ajouter un commentaire dans l’incident Sentinel
⚙️ Étapes du Playbook : « UniversalSecurityResponse »
🔁 0. Déclencheur :
When a response to an Azure Sentinel alert is triggered
🔍 1. Extraire les entités de l’alerte
- Créer une boucle sur
alert.entities[] - Pour chaque entité :
- Lire son
type(Account, Host, Mailbox, IP, File) - Extraire l’identifiant (
userPrincipalName,deviceName,mailboxAddress, etc.)
- Lire son
🧠 2. Branche conditionnelle :
▶️ SI type = Account
- Appeler
Azure AD - Update userAccountEnabled=false
- Ajouter commentaire :
Utilisateur désactivé automatiquement.
▶️ SI type = Host
- Appeler
Microsoft Defender for Endpoint - Isolate devicedeviceIdoudeviceName
- Ajouter commentaire :
Poste isolé automatiquement.
▶️ SI type = Mailbox
- Appeler
Defender for Office - Search & purge email- Filtrer avec
subjectouURL
- Filtrer avec
- Ajouter commentaire :
Email malveillant purgé.
▶️ SI type = IP
- Ajouter IP dans une liste de blocage (Firewall, Sentinel TI, Conditional Access)
▶️ SI type = File
- Ajouter le hash à la politique d’exclusion Defender (blocklist)
📣 3. Notifier le SOC via Teams
- Message personnalisé : cssCopyEdit
Alerte traitée automatiquement : @{alert.name} Action effectuée : @{action_description} Entité concernée : @{entity.value}
🗂️ 4. Ajouter un commentaire à l’incident Sentinel
- Action :
Add comment to incident - Contenu : résumé des actions automatiques prises
🔁 Boucle :
Répéter les étapes pour chaque entité détectée dans l’alerte (parfois il y en a plusieurs dans un incident Sentinel).
✅ Ce que tu gagnes :
| Bénéfice | Détail |
|---|---|
| Réduction des délais de réponse | Plus besoin d’intervention humaine immédiate |
| Couverture large avec un seul Playbook | Il s’adapte selon le type de menace |
| Flexibilité future | Tu peux facilement ajouter des cas (URL, App cloud, etc.) |
| Traçabilité | Toutes les actions sont documentées dans l’incident |
🔥 1. CrowdStrike Falcon XDR
- 🔐 Réputation : Très forte dans le domaine de l’EDR (Endpoint Detection and Response)
- 🧠 IA très avancée pour corréler les événements
- 🌐 Intégration multicloud et tiers très fluide (API ouvertes)
- ✅ Très utilisé dans les grandes entreprises et infrastructures critiques
- 📦 Module XDR étendu à l’email, aux identités, et aux données cloud
🟩 Points forts :
Détection très rapide, peu de faux positifs, couverture large
🟥 Limites : Coût élevé, nécessite une bonne maturité SOC
🛡️ 2. Palo Alto Cortex XDR
- 🔧 Intégré à toute la suite Palo Alto (pare-feu, Prisma, etc.)
- 📊 Corrèle les données Endpoint + Réseau + Cloud
- 🧪 Analyse comportementale (UEBA) très poussée
- 🔄 Automatisation et réponse puissantes
🟩 Points forts :
Superbe visibilité réseau + endpoint, fort dans les environnements hybrides
🟥 Limites : Complexité de déploiement, dépendant de l’écosystème Palo Alto
🕸️ 3. SentinelOne Singularity XDR
- 🎯 Très axé automatisation + vitesse de réponse
- 🧠 Moteur d’IA local pour bloquer et réparer en temps réel
- 🔍 Très bon dans les attaques fileless, ransomwares, mouvements latéraux
🟩 Points forts :
Faible empreinte, très bon pour PME et grands comptes
🟥 Limites : Moins fort dans l’analyse cloud et l’email
🧬 4. Trend Micro Vision One (XDR)
- Solution XDR complète multi-sources : endpoint, serveur, messagerie, cloud
- Très bien intégré dans des contextes hybrides / multicloud
- Offre également une vue centrée utilisateur (XDR for user)
🟩 Points forts :
Très bon rapport coût / efficacité, bonne visibilité sur les activités utilisateurs
🟥 Limites : Moins performant sur la détection réseau pure
🌐 5. IBM QRadar XDR Suite
- Basé sur QRadar SIEM + modules de détection et réponse XDR
- Ciblé pour les grands environnements complexes
- Intégration poussée avec Watson pour l’analyse cognitive
🟩 Points forts :
Capacité à absorber énormément de données, très puissant pour les grandes entreprises
🟥 Limites : Complexité, prix, délai de déploiement
💡 En résumé :
| Solution | Excellente pour… | Points à surveiller |
|---|---|---|
| CrowdStrike | Réactivité, endpoints, SOC rapides | Budget, dépendance cloud |
| Palo Alto Cortex | Réseau + endpoints + cloud | Complexité de déploiement |
| SentinelOne | Automatisation, anti-ransomware | Email/cloud moins matures |
| Trend Micro | Rapport qualité/prix, hybrides | Moins innovant que d’autres |
| IBM QRadar XDR | Environnements géants, SIEM + XDR intégrés | Lourdeur, courbe d’apprentissage |
Est-ce que je dois agir ou est-ce que Defender a déjà tout géré ?
✅ 1. Où trouver cette information dans la console Defender XDR
Tu vas dans le portail Microsoft 365 Defender :
📍 https://security.microsoft.com
Ensuite, tu consultes :
🔎 A. Onglet « Incidents & Alerts »
- Clique sur l’incident qui t’intéresse
- Tu vois :
- Toutes les alertes associées
- Les entités touchées (utilisateur, machine…)
- Les actions automatiques réalisées (AIR = Automated Investigation and Response)
- Les états des alertes (Resolved, Active, Remediated…)
🟢 B. Savoir si l’attaque est gérée automatiquement ?
Dans la fiche de l’alerte, tu as des infos très précises :
🔹 « Investigation Status » :
- Completed – Remediated : tout est traité automatiquement (tu peux dormir tranquille)
- Completed – No threats found : analysé mais pas de menace confirmée
- Pending actions : actions recommandées mais non encore faites (→ tu dois intervenir)
- In progress : analyse toujours en cours
- Not started : aucune analyse (manuelle ou désactivée)
🔹 « Automated Investigation » :
- Liste toutes les étapes que l’IA Defender a faites (fichiers supprimés, clés supprimées, processus bloqués, etc.)
- Tu verras aussi si certaines étapes ont échoué → dans ce cas, tu as un indicateur clair que l’intervention humaine est requise.
🚨 2. Comment être alerté rapidement si l’alerte n’est pas résolue automatiquement
Voici comment automatiser la surveillance :
Option 1 : Création de règles personnalisées dans Microsoft 365 Defender
- Va dans Settings > Rules > Alert notification rules
- Crée une règle :
- Conditions :
Severity = High or MediumANDRemediation Status != Remediated - Actions : Envoi mail, Teams, webhook…
- Conditions :
Option 2 : Dans Sentinel (si intégré)
- Crée une Analytics Rule basée sur : kustoCopyEdit
SecurityIncident | where Status != "Resolved" | where Title contains "XYZ" or Severity == "High" - Attache un Playbook pour notifier ou créer un ticket.
🛠️ 3. Et si c’est à toi d’agir : comment répondre rapidement ?
Dans la fiche de l’incident ou de l’alerte :
- Clique sur Actions :
- Isoler le périphérique
- Suspendre le compte
- Soumettre le fichier au sandbox
- Lancer une analyse complète
- Tu peux aussi lancer une « Manual Investigation » → Defender te guide étape par étape
🧭 Résumé en tableau
| Situation | Où le voir ? | Que faire ? |
|---|---|---|
| Alerte résolue automatiquement | Incident > Investigation Status = Remediated | Rien (juste valider, commenter) |
| Alerte non traitée | Status = Pending / Not started | Lancer les actions manuellement |
| Alerte partiellement résolue | Certaines actions échouées ou en échec | Compléter les actions critiques |
| Aucune remédiation automatique configurée | Paramètres de niveau d’automatisation = None | Configurer AIR ou réagir à chaque alerte |
Vérifier si un contenu malveillant a été bloqué automatiquement (comme un lien de phishing dans un mail)
Simuler des attaques pour tester la détection et la réponse automatique (AIR)
🔍 1. Voir si une URL de phishing a été bloquée automatiquement (Defender for Office 365)
✅ Où chercher dans Microsoft Defender XDR :
📍 https://security.microsoft.com → Email & Collaboration → Explorer
Étapes :
- Clique sur Explorer (anciennement Threat Explorer)
- Filtre par Type de menace : URL
- Recherche par nom de domaine ou nom de l’utilisateur cible
- Tu verras :
- Le mail reçu
- L’URL malveillante détectée
- Action automatique appliquée (ZAP = Zero-hour Auto Purge, ou blocage)
- Résultat :
Delivered,Blocked,Zapped,Redirected - Et s’il y a eu une alerte déclenchée → elle apparaît dans la file des incidents
📘 ZAP = suppression automatique du mail après coup (si la menace est détectée trop tard)
🧠 Conseil :
- Tu peux aussi aller dans Incidents & Alerts, ouvrir l’incident lié au phishing → là tu verras le lien vers l’Explorer avec les détails du mail, de l’URL, et l’action entreprise.
🧪 2. Comment simuler des attaques (dans un environnement de test)
🛠️ A. Simuler une attaque Defender for Endpoint
Utilise Microsoft Defender Simulation Tool :
📍 https://github.com/microsoft/Microsoft-Defender-for-Endpoint-Hunting-Queries/tree/master/Simulations
Étapes :
- Ouvre PowerShell en admin sur une machine protégée par Defender
- Lance une commande comme :
powershellCopyEditInvoke-WebRequest -Uri https://raw.githubusercontent.com/microsoft/MDE-Payloads/main/Simulations/eicar-test-file/eicar.ps1 -OutFile eicar.ps1
.\eicar.ps1
⚠️ C’est un faux malware (EICAR), utilisé pour tester les antivirus.
Résultat :
- Une alerte va être générée dans Defender for Endpoint
- Tu verras dans Incidents & Alerts si Defender l’a bloqué et remédié automatiquement.
🛠️ B. Simuler une attaque Defender for Office 365 (phishing)
- Envoie un mail test contenant un lien EICAR ou GTUBE
- Exemple de lien :
http://www.eicar.org/download/eicar.com - Le mail doit être envoyé depuis un compte externe (gmail ou sandbox)
- Exemple de lien :
- Tu peux aussi utiliser le Microsoft 365 Attack Simulator :
📍 https://security.microsoft.com/attacksimulator
Dans l’Attack Simulator :
- Lance une phishing campaign simulée
- Choisis quelques utilisateurs tests
- Tu peux observer :
- Si le mail a été bloqué
- S’il a été cliqué
- Si une alerte a été générée
- Si une remédiation automatique a été faite
🛠️ C. Simuler une attaque dans Defender for Identity
C’est plus complexe, car Defender for Identity surveille les contrôleurs de domaine.
Voici un test possible :
- Sur une machine liée au domaine, fais une tentative de Pass-the-Hash
- Ou un accès à un fichier
NTDS.ditou une clé de registre AD
Tu peux aussi utiliser des outils comme Mimikatz en version test (sur lab) pour générer une alerte :
powershellCopyEditInvoke-WebRequest -Uri "https://raw.githubusercontent.com/mubix/mimikatz-modules/master/test.ps1" -OutFile test.ps1
.\test.ps1
Résultat :
- Dans Defender for Identity, tu verras des alertes comme :
- Reconnaissance d’annuaire suspecte
- Mouvement latéral
- Brute force
👁️ 3. Comment voir si l’alerte a été automatiquement résolue
→ Retourne dans Incidents & Alerts
- Clique sur l’incident créé par ta simulation
- Va dans Investigation :
- Si c’est écrit
Completed – Remediated, c’est géré automatiquement - Si
Pending action, tu dois agir
- Si c’est écrit
- Tu peux aussi voir les actions entreprises automatiquement (ex : « fichier supprimé », « compte suspendu », « mail purgé »)
✅ En résumé
| Type de simulation | Outil | Résultat visible où ? | Résolution automatique ? |
|---|---|---|---|
| Malware | eicar.ps1 | Incidents > Defender for Endpoint | Oui (souvent) |
| Phishing | Attack Simulator | Incidents > Email & Collaboration | Oui (ZAP, filtre) |
| Identity | Mimikatz/test scripts | Incidents > Defender for Identity | Non, réponse manuelle souvent requise |
AIR (Automated Investigation and Response), c’est automatique… mais configurable
🎯 Ce que fait AIR :
AIR (dans Defender for Endpoint et Defender XDR globalement) :
- Analyse automatiquement une alerte (via l’IA de Microsoft)
- Évalue les entités concernées (fichiers, processus, clés de registre, connexions…)
- Prend des mesures de remédiation (supprimer un fichier, arrêter un processus, isoler un périphérique…)
Mais…
⚙️ Tu dois configurer le niveau d’automatisation dans ton tenant
Par défaut, AIR ne fait pas tout automatiquement. Tu dois choisir l’un des 3 niveaux d’automatisation dans Microsoft 365 Defender :
🔧 Paramétrage dans la console :
📍 https://security.microsoft.com → Settings → Endpoints → Advanced features → Automated investigation and response (AIR)
Tu y choisis :
| Niveau | Description | Recommandé ? |
|---|---|---|
| Aucun (None) | Aucune action automatique, tout doit être validé manuellement | ❌ Non |
| Semi-automatique (Semi) | AIR propose les actions → tu dois les approuver | 🟡 Moyen, bon pour SOC en apprentissage |
| Automatique (Full) | AIR prend toutes les décisions et agit sans intervention | ✅ Oui, sauf exceptions critiques |
🔍 Où vérifier si AIR a agi ?
- Va dans Incidents & Alerts
- Clique sur un incident
- Onglet Investigation :
- Tu vois l’arbre d’investigation (actions automatiques prises)
- Statut : Completed, In progress, Failed…
- Tu peux manuellement relancer une action, ou confirmer une alerte
🔐 Recommandations
✅ Pour environnements classiques :
- Active AIR en mode automatique
- Laisse-le gérer tous les incidents de confiance élevée
- Garde un œil quotidien sur :
- les alertes non traitées
- les actions qui ont échoué
- les alertes à « low confidence » à investiguer manuellement
❗ Pour environnements critiques :
- AIR en mode semi-automatique
- Tu valides les actions sensibles (ex : suppression de fichiers système, isolement de serveurs)
« Si une attaque passe une fois sans être remédiée automatiquement, comment faire pour que la prochaine fois, elle soit bloquée sans intervention humaine ? »
Voici le processus complet en 4 étapes simples et puissantes.
🧠 1. Analyser pourquoi l’attaque n’a pas été résolue
Commence par ouvrir l’incident dans Microsoft Defender XDR.
Vérifie :
- Est-ce que l’alerte a bien déclenché une investigation AIR ?
- Quelle est la confiance de la détection ? (High, Medium, Low)
- Est-ce qu’AIR a :
- proposé une action mais a échoué (→ permissions manquantes) ?
- identifié le problème mais n’a pas pris de mesure (→ niveau d’automatisation trop bas) ?
- pas lancé l’investigation du tout ? (→ entité non couverte ou exclusion active)
🧩 Tu dois comprendre le point de blocage exact, car la correction dépend de ça.
🔧 2. Adapter ton paramétrage pour la prochaine fois
En fonction du cas :
🔹 CAS 1 : L’investigation n’a pas démarré
✅ Solution :
- Va dans
Settings > Endpoints > Advanced features - Vérifie que l’option AIR est activée
- Assure-toi que le device group concerné a un niveau d’automatisation = Full
🔹 CAS 2 : L’investigation a démarré, mais aucune action n’a été prise
✅ Solution :
- Dans
Settings > Endpoints > Auto remediation, passe le groupe concerné à Full automation - Si c’est déjà en full, vérifie que la menace est classée comme « remédiable »
- Certaines alertes ne déclenchent pas d’action directe (ex : suspicion faible)
- Dans ce cas, crée une règle personnalisée (cf. étape 4)
🔹 CAS 3 : Une action a été proposée mais a échoué
✅ Solution :
- Vérifie les droits du compte MDE sur l’appareil
- Autorise Defender à exécuter des scripts ou redémarrer
- Sur un serveur, assure-toi que Defender n’est pas désactivé ou remplacé par un autre AV
- Redéploie l’agent si nécessaire
🧪 3. Tester la correction (simulate & validate)
Utilise l’outil Microsoft Defender Evaluation Package (ou une simulation EICAR) sur la machine concernée.
But :
- Reproduire une alerte similaire
- Voir si elle est maintenant remédiée automatiquement par AIR
🧠 4. Créer une règle personnalisée pour automatiser la remédiation future
Si la menace ne déclenche pas automatiquement une remédiation par défaut, alors tu peux :
A. Créer une « Alert Suppression Rule » + Playbook
→ Tu laisses passer l’alerte dans Defender mais tu l’automatises via Sentinel.
Ou bien :
B. Créer une « Custom Detection Rule »
📍 Dans le portail :Microsoft 365 Defender > Advanced hunting > Custom detections
Exemple de règle :
kustoCopyEditDeviceEvents
| where FileName == "suspicious.exe"
| where ActionType == "ProcessCreated"
→ Crée une alerte si ce fichier est lancé
→ Attache un Playbook Sentinel ou une action automatique (ex. : isolement du device)
✅ Résumé du cycle SOC proactif :
| Étape | Action |
|---|---|
| 1. Analyse | Pourquoi AIR n’a pas agi ? Quelle entité ? Quel blocage ? |
| 2. Correction | Adapter les niveaux d’automatisation, droits, agents |
| 3. Test | Rejouer l’attaque et vérifier la remédiation automatique |
| 4. Prévention | Créer détection + automatisation pour éviter que ça recommence |
