Exclusions de Defender : l’erreur qui rend les malwares invisibles

Ce que font vraiment les exclusions (et pourquoi elles sont séduisantes)

Les « exclusions » de Defender ressemblent à un simple réglage. Elles ne le sont pas. C’est un changement de frontière de sécurité. Lorsque vous excluez un chemin, un processus ou une extension, vous dites à un moteur AV intégré au noyau de se tenir à l’écart à certains endroits — souvent les endroits où les malwares préfèrent s’installer parce qu’ils sont occupés, bruyants et remplis de binaires approuvés.

La plupart des exclusions ne sont pas malveillantes. Elles viennent de la panique liée aux performances. Un serveur de build commence à tourner en boucle. Une ferme VDI donne l’impression de fonctionner sur des calculatrices de poche. Quelqu’un lance un benchmark, voit le filtre antivirus dans la pile, et l’instinct de survie de l’organisation s’enclenche : « Exclure le dossier chaud. » Le dossier chaud devient une zone chaude. Puis il devient l’angle mort que vous expliquerez plus tard au conseil d’administration.

Les exclusions ne se valent pas toutes

Defender prend en charge plusieurs types d’exclusions. Chacun a un rayon d’impact et un potentiel d’abus différents :

• Exclusions de chemin : « Ne pas scanner quoi que ce soit sous ce dossier. » Si ce dossier est modifiable par des non-admins, vous venez de créer une garderie pour malwares.
• Exclusions de processus : « Ne pas scanner les fichiers ouverts par ce processus. » C’est un favori des développeurs (compilateurs, outils de build) et des attaquants (vivre sur la plateforme via des processus de confiance).
• Exclusions d’extension : « Ne pas scanner les fichiers avec cette extension. » C’est ainsi que vous créez accidentellement un refuge sûr pour des payloads renommés.
• Exclusions réseau/UNC : souvent appliquées pour réduire la charge du serveur de fichiers ; souvent mal comprises ; fréquemment incohérentes selon les endpoints.

Pourquoi les gens continuent malgré tout

Parce que ça marche. Les exclusions peuvent réduire l’utilisation CPU, les E/S et les pics de latence. Elles peuvent fluidifier les builds des développeurs. Elles peuvent éliminer les tickets « pourquoi Outlook se fige ? ». Elles peuvent même être nécessaires pour certaines applications legacy.

Mais les exclusions sont un compromis : vous payez en performances par une perte de couverture de détection. Si vous ne quantifiez pas ce compromis, et si vous ne l’encadrez pas par des contrôles, vous n’optimisez pas. Vous éteignez les phares pour faire avancer la voiture plus vite.

Une citation qui devrait figurer sur chaque demande d’exclusion AV : « L’espoir n’est pas une stratégie. » — Gene Kranz

Voilà tout le problème en une phrase. La plupart des décisions d’exclusion sont basées sur l’espoir. « Espérons que rien de mal n’arrive là. » « Espérons que seul le système de build écrive dans ce dossier. » « Espérons que les attaquants ne remarqueront pas. » Les attaquants remarquent.

Comment les attaquants exploitent les exclusions

Les attaquants n’ont pas besoin de désactiver Defender globalement. Ils ont juste besoin d’un endroit pour respirer. Les exclusions leur en donnent un, et elles ont tendance à être stables au travers des redémarrages et des mises à jour parce qu’elles sont gérées par politique, pas un état d’exécution transitoire.

Schéma d’attaque 1 : « Vivre dans le chemin exclu »

Si C:\Build\ ou D:\Tools\ est exclu et modifiable, l’attaquant y dépose des payloads et les exécute depuis là. Même si vous analysez plus tard le disque, le scan à l’accès qui aurait bloqué l’exécution ne s’est jamais produit. Certaines organisations effectuent finalement des scans hors ligne et se demandent pourquoi c’est propre ; le malware évite activement d’être touché par tout ce qui déclenche l’analyseur.

Schéma d’attaque 2 : « Abuser d’une exclusion de processus »

Les exclusions de processus sont plus sournoises. Si vous excluez devenv.exe, msbuild.exe, node.exe ou un agent interne qui lit et écrit beaucoup de fichiers, vous avez effectivement dit à Defender : « Si ce processus touche un fichier, ne regardez pas trop. »

Un attaquant capable d’exécuter du code sous un processus exclu (ou de s’y injecter, ou de le pousser à charger du contenu malveillant) obtient une dégradation de la détection. Ce n’est pas toujours un contournement complet, mais c’est suffisant pour passer au travers des détections basées sur les fichiers et bruyantes.

Schéma d’attaque 3 : « Gagner la guerre de gouvernance »

Dans les grands environnements, les exclusions sont gérées via GPO, Intune, SCCM/ConfigMgr ou des couches de politique EDR tierces. Les attaquants adorent la complexité. S’ils obtiennent l’admin sur une seule machine, ils ne pourront peut‑être pas changer des paramètres appliqués centralement — à moins que votre contrôle de changement soit faible et que vous autorisiez les contournements locaux, ou que vos politiques soient des « tatouages » d’anciens paramètres qui ne sont jamais nettoyés.

Même sans changer la politique, ils peuvent profiter d’exclusions existantes dont personne ne se souvient. La porte dérobée la plus simple est celle que vous avez déjà construite et oubliée.

Petite blague #1 : Les exclusions sont comme des règles de pare-feu « temporaires » — tout le monde se souvient de les avoir ajoutées, personne ne se souvient de les avoir retirées.

Schéma d’attaque 4 : « Se cacher dans le stockage en clair »

Voici l’angle de l’ingénieur stockage : les gens excluent des dossiers à forte rotation parce qu’ils provoquent une amplification des E/S. Defender analyse les opérations d’ouverture/fermeture ; votre stockage le perçoit comme des lectures supplémentaires, un trafic métadonnées et des ratés de cache. Sur les partages distants, cela devient un multiplicateur de latence. Les équipes excluent donc des volumes entiers, des profils ou des racines de données, souvent sur les machines qui disposent des meilleurs identifiants (admins, agents de build, boxes de déploiement). Ce n’est pas seulement risqué. C’est un panier cadeau.

Faits et historique utiles pour les débats

Quelques points de contexte qui aident lorsque vous tentez de convaincre une organisation occupée d’arrêter de traiter les exclusions comme des bonbons gratuits :

1. Les exclusions prédatent la pensée EDR moderne. Les moteurs AV traditionnels étaient centrés sur les fichiers ; les exclusions étaient un outil grossier pour conserver la capacité d’utilisation des systèmes.
2. La douleur des performances a conduit aux « meilleures pratiques » AV en entreprise. À l’époque des disques tournants et des RAM de quelques gigaoctets, exclure de grands arbres de fichiers était courant.
3. Microsoft Defender a évolué en une plateforme. Ce que l’on appelle « Defender » inclut désormais la protection cloud, la surveillance comportementale, les règles ASR et la protection contre la modification — ce qui fait que les exclusions interagissent avec plusieurs couches.
4. Les attaquants suivent les conventions d’entreprise. Les dossiers de build, répertoires temporaires et caches d’outils sont courants d’une entreprise à l’autre ; une fois exclus, vous standardisez le lieu de cachette.
5. Les exclusions d’extension sont historiquement abusées. Renommer un payload avec une extension « sûre » (ou l’emballer dans un conteneur) est une vieille astuce qui fonctionne encore étonnamment souvent.
6. La dérive des politiques est réelle. Les environnements accumulent des exclusions issues de migrations, d’installations de fournisseurs et de correctifs « juste pour maintenant », et elles persistent lors des cycles de renouvellement.
7. L’analyse UNC/share a toujours été source de débats. Faut-il analyser côté client ? côté serveur ? Les deux ? La mauvaise réponse est « ni l’un ni l’autre », ce que créent souvent des exclusions larges.
8. La visibilité de Defender dépend des logs. Si vous ne collectez pas les journaux opérationnels de Defender (et ne les corrélez pas avec la politique), vous devinez essentiellement.
9. Les exclusions peuvent saper la réponse aux incidents. Si vous collectez des artefacts depuis des chemins exclus, vos outils de réponse en direct peuvent voir des fichiers que Defender avait ignorés à l’exécution — ce qui mène à des débats « pourquoi ça n’a pas alerté ? ».

Mode d’emploi pour un diagnostic rapide

Quand quelque chose cloche — détections manquées, persistance suspecte, ou une machine « trop propre » pendant un incident — ne commencez pas par réinstaller l’agent. Commencez par répondre à trois questions dans l’ordre.

Première : Des exclusions sont-elles présentes, et d’où viennent-elles ?

• Vérifiez les listes d’exclusions locales de Defender.
• Vérifiez si les paramètres sont gérés par une politique (GPO/MDM).
• Vérifiez l’état de la protection contre la modification (tamper protection).

Deuxième : Les emplacements exclus sont-ils modifiables par le privilège probable de l’attaquant ?

• Pour les postes : un utilisateur standard peut-il y écrire ?
• Pour les serveurs : le compte de service ou l’agent de build peut-il y écrire ?
• Pour les volumes partagés : qui a le droit Modifier sur le partage et sur NTFS ?

Troisième : Defender a-t-il journalisé quelque chose de pertinent, ou la journalisation/télémétrie manque-t-elle ?

• Consultez les journaux opérationnels de Defender autour du moment de l’événement.
• Confirmez que l’appareil rapporte à votre console de sécurité centrale.
• Vérifiez si votre SIEM ingère les bons canaux.

Si vous effectuez ces trois étapes, vous trouvez généralement rapidement le goulot d’étranglement : soit (a) les exclusions ont créé un angle mort, (b) la politique est mal appliquée/derivée, ou (c) vous volez sans télémétrie.

Tâches pratiques : commandes, sorties et décisions

Conçues pour les intervenants et responsables plateforme. Exécutez-les sur un poste représentatif, puis sur une machine « connue compromise » si vous en avez une. Chaque tâche inclut la commande, un exemple de sortie, ce que cela signifie et la décision à prendre.

Tâche 1 : Lister toutes les exclusions Defender (chemins, processus, extensions)

cr0x@server:~$ powershell -NoProfile -Command "Get-MpPreference | Select-Object -ExpandProperty ExclusionPath; Get-MpPreference | Select-Object -ExpandProperty ExclusionProcess; Get-MpPreference | Select-Object -ExpandProperty ExclusionExtension"
C:\Build\
C:\Tools\Cache\
node.exe
msbuild.exe
.tmp
.log

Sens : Defender ignorera ces emplacements/interactions de processus/extensions.

Décision : Si un chemin exclu est modifiable par des non-admins ou des comptes de service traitant des entrées non fiables, traitez-le comme un risque prioritaire et planifiez un retour en arrière ou un rétrécissement.

Tâche 2 : Vérifier si les paramètres Defender sont gérés (et par qui)

cr0x@server:~$ powershell -NoProfile -Command "Get-MpComputerStatus | Select-Object AMRunningMode,AntivirusEnabled,RealTimeProtectionEnabled,IsTamperProtected"
AMRunningMode          : Normal
AntivirusEnabled       : True
RealTimeProtectionEnabled : True
IsTamperProtected      : True

Sens : Defender est activé, la protection en temps réel est activée, et la protection contre la modification est activée.

Décision : Si la protection contre la modification est désactivée sur des endpoints, corrigez cela avant de discuter des exclusions. La tamper protection ne résout pas tout, mais augmente le coût des manipulations locales.

Tâche 3 : Identifier rapidement les exclusions larges (test d’odeur « disque entier »)

cr0x@server:~$ powershell -NoProfile -Command "Get-MpPreference | Select-Object -ExpandProperty ExclusionPath | Where-Object {$_ -match '^[A-Z]:\\$' -or $_ -match '^[A-Z]:\\$|^[A-Z]:\\' }"
C:\
D:\

Sens : Quelqu’un a exclu des volumes entiers. Ce n’est pas un réglage ; c’est une reddition.

Décision : Ouvrez un ticket de niveau incident. C’est urgent sauf si l’hôte est isolé et compensé par d’autres contrôles.

Tâche 4 : Vérifier l’état des règles ASR (et si les exclusions masquent des comportements risqués)

cr0x@server:~$ powershell -NoProfile -Command "Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Ids; Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Actions | Select-Object -First 5"
BE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550
D4F940AB-401B-4EFC-AADC-AD5F3C50688A
1
1
2
1
1

Sens : Les règles ASR sont configurées ; les actions indiquent blocage/audit/avertissement selon la cartographie dans votre environnement.

Décision : Si ASR est majoritairement en « audit » tandis que les exclusions sont larges, vous collectez des preuves de compromission plutôt que de l’empêcher. Passez les dispositifs à haute valeur en mode blocage quand c’est faisable.

Tâche 5 : Extraire les détections Defender récentes (locales) pour voir ce qu’il voit ou non

cr0x@server:~$ powershell -NoProfile -Command "Get-MpThreatDetection | Select-Object -First 5 | Format-List"
ThreatID      : 2147724016
ThreatName    : Trojan:Win32/Wacatac.B!ml
ActionSuccess : True
InitialDetectionTime : 2/5/2026 8:41:12 AM
Resources     : {file:_C:\Users\jdoe\AppData\Local\Temp\q1.tmp}

Sens : Defender détecte quelque chose dans un répertoire temporaire ; bien. Demandez si des artefacts similaires existent sous des chemins exclus.

Décision : Si les détections sont rares pendant un incident actif, suspectez les exclusions, des lacunes de télémétrie ou une chaîne d’exécution différente (scripts, uniquement en mémoire, abus de signatures).

Tâche 6 : Interroger le journal opérationnel Defender pour des indices liés aux exclusions

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName 'Microsoft-Windows-Windows Defender/Operational' -MaxEvents 20 | Select-Object TimeCreated,Id,Message | Format-Table -AutoSize"
TimeCreated           Id Message
-----------           -- -------
2/5/2026 8:40:58 AM 1116 Microsoft Defender Antivirus detected malware or other potentially unwanted software.
2/5/2026 8:40:59 AM 1117 Microsoft Defender Antivirus took action to protect this machine from malware or other potentially unwanted software.

Sens : Vous disposez d’une télémétrie de détection locale basique.

Décision : Si ce journal est vide sur une machine dont vous savez qu’elle a exécuté du code suspect, vérifiez si la journalisation est désactivée, si Defender a été remplacé ou si des exclusions ont empêché la génération d’événements de scan.

Tâche 7 : Valider si un dossier suspect est exclu

cr0x@server:~$ powershell -NoProfile -Command "$p='C:\Build\'; (Get-MpPreference).ExclusionPath -contains $p"
True

Sens : Le dossier est exclu.

Décision : Si ce dossier sert à ingérer des artefacts externes (packages, builds PR, outils téléchargés), considérez-le comme hostile. Supprimez ou resserrez l’exclusion et compensez par des paramètres de scan favorables aux performances.

Tâche 8 : Vérifier les permissions d’écriture sur un chemin exclu (est-ce une zone de dépôt ?)

cr0x@server:~$ powershell -NoProfile -Command "icacls C:\Build\"
C:\Build\ BUILTIN\Administrators:(OI)(CI)(F)
         NT AUTHORITY\SYSTEM:(OI)(CI)(F)
         BUILTIN\Users:(OI)(CI)(M)
         CREATOR OWNER:(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files

Sens : BUILTIN\Users ont Modify. Sur un chemin exclu, c’est un problème.

Décision : Supprimez l’exclusion ou verrouillez l’ACL pour que seuls les comptes de service nécessaires puissent écrire. Préférez les deux lorsque c’est possible.

Tâche 9 : Vérifier la « dérive de politique » via le registre (politique locale vs effective)

cr0x@server:~$ powershell -NoProfile -Command "Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender\Exclusions\Paths' -ErrorAction SilentlyContinue | Format-List"
C:\Build\ : 0
C:\Tools\Cache\ : 0
PSPath : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Defender\Exclusions\Paths

Sens : Ces exclusions proviennent probablement de la politique (GPO/MDM), pas d’un réglage local ponctuel.

Décision : Corrigez à la source de vérité. La suppression locale réapparaîtra après actualisation de la politique et vous aurez l’air de n’avoir « rien fait ».

Tâche 10 : Déterminer si Defender est en mode passif (coexistence EDR courante)

cr0x@server:~$ powershell -NoProfile -Command "Get-MpComputerStatus | Select-Object AMRunningMode"
AMRunningMode
------------
Normal

Sens : Defender protège activement (pas en mode passif).

Décision : Si vous voyez Passive ou EDR Block Mode, cartographiez les responsabilités : quel produit applique le scan, et où résident les exclusions ? La sécurité à double voix est la cause de dispositifs « couverts » par personne.

Tâche 11 : Capturer les paramètres de protection en temps réel liés à l’optimisation des performances

cr0x@server:~$ powershell -NoProfile -Command "Get-MpPreference | Select-Object DisableRealtimeMonitoring,DisableIOAVProtection,DisableArchiveScanning,DisableBehaviorMonitoring | Format-List"
DisableRealtimeMonitoring : False
DisableIOAVProtection     : False
DisableArchiveScanning    : False
DisableBehaviorMonitoring : False

Sens : Les protections clés sont activées ; les problèmes de performances ont probablement motivé les exclusions plutôt qu’une désactivation globale.

Décision : Si l’une de ces options est largement désactivée, considérez cela comme un défaut de configuration. Réactivez-les et traitez les performances avec des exclusions ciblées, un bridage CPU ou des scans planifiés — pas en supprimant les fonctionnalités de base.

Tâche 12 : Tester un scan contrôlé contre un dossier spécifique (pour mesurer l’impact avant de changer la politique)

cr0x@server:~$ powershell -NoProfile -Command "Measure-Command { Start-MpScan -ScanType CustomScan -ScanPath 'C:\Build\' } | Select-Object TotalSeconds"
TotalSeconds
------------
38.421

Sens : Un scan personnalisé de ce dossier prend ~38 secondes sur cet hôte, maintenant. Ce sont des données.

Décision : Utilisez cela pour négocier : peut-être n’avez-vous pas besoin d’une exclusion complète ; peut-être devez-vous n’exclure que des sous-dossiers temporaires, ou seulement pendant les heures de travail, ou déplacer les artefacts de build vers un emplacement contrôlé avec un scan séparé.

Tâche 13 : Vérifier si la protection cloud est activée (aide à attraper les menaces communes)

cr0x@server:~$ powershell -NoProfile -Command "Get-MpPreference | Select-Object MAPSReporting,SubmitSamplesConsent | Format-List"
MAPSReporting       : Advanced
SubmitSamplesConsent: SendSafeSamples

Sens : La protection cloud et la soumission d’échantillons sont activées à un niveau raisonnable.

Décision : Si c’est désactivé à l’échelle de l’entreprise « pour des raisons de confidentialité », vous choisissez une détection plus lente et plus fragile. Vous compenserez par plus d’exclusions (car vous aurez plus de faux positifs) et la boucle s’aggravera.

Tâche 14 : Trouver des paramètres Defender récemment modifiés (signal approximatif via les journaux d’événements)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName 'Microsoft-Windows-Windows Defender/Operational' -MaxEvents 200 | Where-Object {$_.Id -in 5007} | Select-Object -First 5 TimeCreated,Message | Format-List"
TimeCreated : 2/5/2026 7:58:21 AM
Message     : Microsoft Defender Antivirus configuration has changed. If this is an unexpected event you should review the settings...

Sens : L’ID d’événement 5007 indique un changement de configuration. Il ne dira pas toujours exactement quoi, mais il indique quand.

Décision : Corrélez l’horodatage avec les fenêtres de changement, les mises à jour GPO, les poussées de politique Intune ou une activité admin suspecte. Si c’est hors contrôle de changement, escaladez.

Petite blague #2 : Le moyen le plus rapide d’accélérer Defender est d’exclure C:\. C’est aussi le moyen le plus rapide d’accélérer la réponse aux incidents… parce que ça ne finit jamais.

Trois mini-récits d’entreprise vécus sur le terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

L’entreprise avait une « base de durcissement standard ». Ça avait l’air bien dans les slides : Defender activé, tamper protection activée, règles ASR activées (principalement en audit), et des exclusions « soigneusement choisies » pour la productivité des développeurs. Tout le monde croyait à la phrase clé : soigneusement choisies.

Pendant une investigation sur une connexion admin suspecte, les intervenants ont trouvé une nouvelle tâche planifiée lançant un binaire depuis C:\DevTools\. Aucun alertes. Aucun blocage. Le hash du fichier n’était dans aucune base connue de malveillants. La machine était autrement propre. La première hypothèse de l’équipe était classique : « Ça doit être un malware uniquement en mémoire. » Cette hypothèse a fait perdre du temps.

L’histoire réelle était plus banale. C:\DevTools\ avait été exclu des années auparavant pour un IDE désormais retiré qui fonctionnait mal sous scan à l’accès. Le dossier est resté dans la baseline parce que personne ne voulait être la personne qui casse les environnements dev. Avec le temps, l’ACL a dérivé. Un groupe d’utilisateurs standard avait Modify. L’attaquant n’avait pas besoin d’un contournement sophistiqué. Il lui suffisait d’un dossier exclu et modifiable et d’une tâche planifiée.

Ce qui a fait mal n’était pas l’exclusion elle-même. C’était l’hypothèse que les exclusions étaient statiques, sûres et revues. L’investigation s’est terminée par un nettoyage de la politique, un verrouillage des ACL et une réalisation inconfortable : la baseline n’avait jamais été testée contre un modèle d’attaquant. Elle avait été testée contre des tickets helpdesk.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une équipe plateforme gérait une flotte d’agents de build Windows. Les builds étaient lents après une mise à jour, et les métriques montraient des pics d’E/S. L’espace de travail de build contenait des milliers de petits fichiers — caches de dépendances, archives extraites, objets intermédiaires. Defender faisait son travail : inspecter les opérations de fichiers.

L’équipe a fait un changement « chirurgical » : exclure la racine de l’espace de travail entier. Le temps de build s’est amélioré immédiatement. Tout le monde a applaudi. Le changement a été déployé largement, parce que rien ne réussit comme un graphique qui descend et va vers la droite.

Puis est survenu l’incident de la chaîne d’approvisionnement. Une dépendance compromise est entrée dans le processus de build. Elle n’avait pas besoin d’exploiter le système d’exploitation. Elle n’avait pas besoin de tricks kernel. Il lui suffisait de déposer un exécutable d’assistance dans l’espace de travail exclu et de l’exécuter pendant le build. Le payload n’était même pas particulièrement novateur. Il était simplement non observé là où cela avait de l’importance.

Quand ils ont annulé l’exclusion, les builds ont de nouveau ralenti — et maintenant l’équipe avait deux incendies : sécurité et performance. L’« optimisation » n’était pas mauvaise en soi. L’erreur était la taille du rayon d’impact et l’absence de contrôles compensatoires : pas de réseaux de build isolés, pas de restrictions d’écriture, pas d’analyse à l’entrée/sortie des artefacts, pas de volumes de staging séparés avec accès contrôlé.

La solution n’était pas « ne jamais exclure ». La solution était « exclure avec intention » : restreindre les chemins, séparer les frontières de confiance, scanner avant exécution et concevoir les agents de build comme semi-disposables. Les performances sont revenues grâce à une meilleure stratégie de cache et des fenêtres de scan intelligentes, pas par l’aveuglement.

Mini-récit 3 : La pratique ennuyeuse qui a sauvé la situation

Une autre organisation avait une politique que personne n’aimait : chaque exclusion nécessitait un ticket avec (1) un impact de performance mesuré, (2) un propriétaire, (3) une date d’expiration et (4) une revue des ACL du chemin exclu. Les gens se plaignaient. Bien sûr. C’était du travail supplémentaire et ça ralentissait les « correctifs rapides ».

Un après-midi, un analyste a vu un motif étrange : une machine exécutant un outil signé légitime touchait régulièrement des fichiers sous un dossier exclu utilisé par une application métier. Aucun hit Defender. Mais le SIEM avait des événements de création de fichiers et des logs d’exécution de processus (provenant d’autres télémetries) qui ne sentaient pas bon.

Le détail clé : le ticket d’exclusion pour ce dossier avait une date d’expiration. Il devait être renouvelé, et le renouvellement demandait de re-justifier les permissions d’écriture du dossier. Lorsqu’ils ont vérifié, ils ont découvert que le fournisseur de l’application avait changé le comportement de son installateur ; il élargissait les ACL lors d’une mise à jour. L’exclusion était devenue silencieusement dangereuse.

Parce que le processus était ennuyeux, il était fiable. Ils ont supprimé l’exclusion, l’ont remplacée par une exclusion de sous-dossier plus étroite et ont verrouillé les permissions. L’activité suspecte s’est révélée être une tentative d’intrusion de stade précoce utilisant des outils commodités. Elle a échoué dans cet environnement pour une raison simple : quelqu’un a traité « exclure » comme un changement ayant des conséquences, pas comme une astuce de performance.

Erreurs courantes : symptôme → cause racine → correctif

1) Symptom : « Defender est activé, mais il n’alerte jamais sur cet hôte »

Cause racine : Le malware s’exécute depuis des chemins exclus ou via des processus exclus ; Defender fonctionne comme configuré.

Correctif : Auditer les exclusions ; supprimer les chemins larges ; vérifier les ACL ; ajouter une télémétrie de détection pour la création de processus et l’activité des scripts ; rescanner les emplacements précédemment exclus avec un scan personnalisé contrôlé.

2) Symptom : « Nous avons supprimé l’exclusion, mais elle revient »

Cause racine : La politique gérée (GPO/Intune/ConfigMgr) la réapplique, ou des « tatouages » de registre legacy restent.

Correctif : Identifier la source de vérité (chemins de politique dans le registre et gestion des appareils) ; modifier centralement ; confirmer l’actualisation de la politique ; documenter la propriété et la date d’expiration.

3) Symptom : « Seuls les développeurs sont impactés ; les autres non »

Cause racine : Outils dev ou caches de build ont des exclusions de processus (ex. node.exe, msbuild.exe) ou de larges exclusions de chemin sur les machines dev.

Correctif : Remplacer les exclusions de processus par des exclusions de chemin sur des répertoires non modifiables par l’utilisateur, ou isoler les caches par utilisateur avec scan au moment du téléchargement ; appliquer le moindre privilège sur les répertoires d’outils.

4) Symptom : « La VDI est lente, donc nous avons exclu les profils »

Cause racine : Exclure C:\Users\ ou des sous-arbres de profils pour réduire les tempêtes de logon et les E/S.

Correctif : N’excluez pas des profils entiers. Ajustez les horaires de scan, activez les paramètres de performance et ciblez les exclusions vers des caches lourds mais à faible risque avec des ACL strictes. Envisagez des solutions de conteneur de profil avec scan à la frontière du conteneur.

5) Symptom : « Le CPU du serveur de fichiers est élevé, donc nous avons exclu les partages sur les clients »

Cause racine : Confusion sur l’endroit où l’analyse doit se produire ; les exclusions côté client réduisent la charge mais créent des angles morts pour les fichiers accessibles via SMB.

Correctif : Décidez explicitement de la responsabilité du scan : scanner à l’ingestion (serveur) et/ou au egress (client) selon le risque. Si vous excluez sur les clients, assurez-vous d’un scan côté serveur et de contrôles stricts sur les permissions d’écriture et le filtrage de fichiers.

6) Symptom : « Nous avons exclu .log et .tmp pour réduire le bruit »

Cause racine : Les exclusions d’extension trop larges sont faciles à abuser ; les payloads peuvent être stockés avec des extensions trompeuses.

Correctif : Évitez les exclusions d’extension sauf pour des types de données strictement contrôlés et non exécutables, et même dans ce cas préférez des exclusions basées sur le chemin avec des ACL verrouillées. Réévaluez toute exclusion correspondant à des extensions communes « génériques ».

7) Symptom : « Après installation d’une appli fournisseur, Defender a cessé de signaler son dossier »

Cause racine : L’installateur du fournisseur a ajouté des exclusions (parfois légitimes, parfois par paresse) et elles ont persisté lors des mises à jour.

Correctif : Inventoriez les changements post-installation (ID d’événement 5007) ; exigez une justification du fournisseur ; resserrez les exclusions ; imposez que les fournisseurs n’excluent pas les répertoires de plugins modifiables.

8) Symptom : « Le scan IR trouve un malware, mais il n’a pas été bloqué plus tôt »

Cause racine : L’exécution s’est produite depuis une zone exclue ou via un processus exclu ; les scans ultérieurs ont utilisé d’autres moteurs/modes, ou l’analyse n’a eu lieu qu’après connaissance des IOC.

Correctif : Traitez les exclusions comme le principal suspect. Alignez les contrôles préventifs (scan à l’accès) avec les contrôles détectifs (scan IR) pour ne pas comparer des pommes et une salade de fruits.

Listes de contrôle / plan étape par étape

Étape par étape : Comment corriger les exclusions sans casser la production

1. Inventairez les exclusions effectives sur des endpoints représentatifs (dev, VDI, serveurs, kiosques). Catégorisez par type : chemin/processus/extension.
2. Classez chaque exclusion par risque :
   • Le chemin exclu est-il modifiable par des utilisateurs standards ou des groupes larges ?
   • Reçoit-il du contenu non fiable (téléchargements, pièces jointes, dépendances de build, import USB) ?
   • Des exécutables y sont-ils lancés ?
3. Trouvez le propriétaire (équipe ou appli). S’il n’y a pas de propriétaire, c’est déjà un problème.
4. Ajoutez une date d’expiration pour chaque exclusion. Traitez le « permanent » comme une odeur suspecte.
5. Resserrez la portée :
   • Privilégiez l’exclusion d’un sous-dossier de cache spécifique plutôt que la racine d’un workspace entier.
   • Privilégiez l’exclusion d’un dossier de données non exécutables plutôt qu’un dossier d’outils.
   • Évitez les exclusions de processus sauf si vous pouvez démontrer qu’elles ne créent pas d’angles morts d’exécution.
6. Verrouillez les ACL sur les chemins exclus. Si c’est exclu, ça ne doit pas être généralement modifiable. Si l’écriture est nécessaire, isolez-le et scannez à la frontière.
7. Mesurez les performances avant et après avec des tests reproductibles (temps de build, métriques E/S, scans personnalisés contrôlés). Pas de benchmarks, pas d’exclusions.
8. Déployez en anneaux : groupe pilote, puis cohorte plus large, puis production complète. Les exclusions multiplient le risque ; évitez les changements en big-bang.
9. Surveillez les signaux :
   • Événements opérationnels Defender (changement de config, événements de détection).
   • CPU et longueur de file d’attente disque sur endpoints et serveurs de fichiers.
   • Tickets helpdesk liés aux performances et compatibilité applicative.
10. Documentez les contrôles compensatoires quand des exclusions persistent : accès en écriture restreint, allowlisting applicatif, scan côté serveur, scan d’artefacts dans CI/CD.
11. Ré-auditez trimestriellement ou après de grosses mises à jour. La dérive se produit discrètement ; vous avez besoin d’une méthode planifiée pour la remarquer.

Checklist : À quoi ressemble une demande d’exclusion acceptable

• Chemin/processus/extension exact et justification liée à un impact mesurable.
• Preuve des permissions d’écriture et des entités pouvant écrire.
• Indication si l’emplacement peut contenir des exécutables ou des scripts.
• Contrôles compensatoires (ex. scan au téléchargement, isolation des agents de build, signature des artefacts).
• Propriétaire et date d’expiration.
• Plan de retour en arrière et stratégie de déploiement en anneaux.

Checklist : Signaux d’alerte (traiter comme incident de sécurité, pas une demande de réglage)

• Exclure C:\, D:\, racines de profils utilisateurs, ou racines d’applications entières avec plugins/macros.
• Exclure des processus d’outillage courants (powershell.exe, wscript.exe, cmd.exe) ou des hôtes de script. C’est pratiquement une invitation écrite.
• Exclusions sans propriétaire ou « on ne sait pas pourquoi, ça existe depuis toujours ».
• Exclusions sur des machines à haut privilège (serveurs de déploiement, jump hosts admin) sans contrôles compensatoires.
• Exclusions d’extension pour des types pouvant contenir du code en pratique (ou facilement renommables).

FAQ

1) Les exclusions Defender sont-elles toujours mauvaises ?

Non. Certaines sont nécessaires. Le problème vient des exclusions sans bornes : trop larges, trop modifiables, sans propriétaire, sans date d’expiration, sans contrôles compensatoires. Utilisez les exclusions comme un scalpel, pas comme une pelle.

2) Qu’est-ce qui est pire : une exclusion de chemin ou une exclusion de processus ?

Les exclusions de processus sont souvent pires car elles sont plus difficiles à raisonner. Une exclusion de chemin peut être contenue avec des ACL. Une exclusion de processus peut créer des angles morts « tout ce que ce processus de confiance touche », sur lesquels les attaquants peuvent parfois s’appuyer.

3) Les attaquants peuvent-ils ajouter eux-mêmes des exclusions ?

S’ils disposent de privilèges suffisants et que la protection contre la modification/la police ne les en empêche pas, oui. Mais le cas le plus courant est plus simple : ils abusent des exclusions que vous avez déjà déployées pour les performances.

4) Si la protection contre la modification est activée, sommes-nous en sécurité ?

Plus sécurisé, pas invulnérable. La protection contre la modification aide à empêcher les changements locaux, mais elle ne corrige pas des exclusions risquées livrées par la politique, et elle ne change pas le fait qu’un dossier exclu et modifiable est une cachette.

5) Nous excluons les caches de build. Comment le faire en sécurité ?

Rendez le dossier de cache exclu non modifiable par des humains, seulement par l’identité de l’agent de build. Scannez les dépendances au moment du téléchargement, scannez les artefacts au moment de la publication, et gardez les agents de build isolés et reconstruisables. Resserrez l’exclusion sur le cache, pas sur l’espace de travail.

6) Faut-il exclure les fichiers de base de données pour les performances ?

Parfois, mais ne devinez pas. Beaucoup de fournisseurs de bases de données ont des recommandations spécifiques car l’analyse des fichiers DB en ligne peut causer latence et risque de corruption. Si vous excluez des fichiers de données DB, compensez en scannant les binaires, scripts, sauvegardes et répertoires de staging — là où les attaquants déposent réellement des payloads.

7) Pourquoi les exclusions « reviennent » après qu’on les a supprimées ?

Parce que votre environnement est géré. GPO/MDM réappliquent les paramètres, et certaines politiques legacy restent dans les clés de registre jusqu’à suppression centrale. Corrigez toujours la source de politique, pas seulement le endpoint.

8) Comment détecter qu’un chemin exclu est utilisé par un malware ?

Utilisez d’autres télémétries : logs de création de processus, audit de création de fichiers, Sysmon (lorsqu’il est déployé), capteurs EDR et tâches/services planifiés inhabituels pointant vers des répertoires exclus. Cherchez aussi des événements de changement de configuration Defender et des rafales de créations à l’intérieur des chemins exclus.

9) L’exclusion d’extensions de fichiers est-elle acceptable ?

Rarement. Les exclusions d’extension sont trop faciles à manipuler. Si nécessaire, gardez-les extrêmement étroites, assurez-vous que le répertoire est non-exécutable et confirmez que vous n’excluez pas quelque chose qui peut être exécuté ou interprété indirectement.

10) Quelle posture politique par défaut est sûre ?

Par défaut, pas d’exclusions. Ajoutez-les uniquement avec une justification mesurée, un propriétaire, une date d’expiration et une revue ACL. Pour les performances, privilégiez l’ajustement des horaires de scan et le resserrement de la portée plutôt que des exclusions globales.

Conclusion : prochaines actions à mener cette semaine

Si vous déployez Windows à grande échelle, vous avez déjà des exclusions. La question est de savoir si elles sont des décisions d’ingénierie contrôlées ou des panics fossilisés.

1. Exportez les exclusions effectives depuis un échantillon représentatif d’endpoints et de serveurs. Faites une liste lisible par des humains.
2. Signalez les dangers évidents : exclusions de disque entier, chemins exclus modifiables par des utilisateurs, exclusions de processus larges.
3. Trouvez la source de politique (locale vs gérée) et assignez un propriétaire pour chaque groupe d’exclusions.
4. Verrouillez les permissions sur tout chemin exclu qui doit rester. S’il est modifiable par « Users », ce n’est pas une exclusion, c’est une surface d’attaque.
5. Mettez des dates d’expiration sur tout et planifiez une revue trimestrielle. Le processus ennuyeux est celui qui fonctionne encore quand le personnel change et que la mémoire fait défaut.

Le meilleur moment pour corriger les exclusions est avant l’incident. Le deuxième meilleur moment est juste après avoir fini de lire ceci et avant votre prochaine réunion « pourquoi Defender ne l’a pas détecté ? ».