Règles ASR Defender via GPO : vérifier les appareils

Que sont les règles ASR Defender via GPO ?

Les règles ASR Defender via GPO permettent aux administrateurs de distribuer des protections fondées sur les comportements aux appareils Windows par la stratégie de groupe. Les règles de réduction de la surface d’attaque (ASR) ciblent des activités telles que la création de processus enfants par les applications Office ou le lancement d’exécutables téléchargés par des scripts. La question utile est de savoir quels GUID de règles, modes et exclusions l’appareil cible possède réellement, plutôt que de vérifier seulement l’existence d’une stratégie ASR. Guide de configuration Microsoft

Une stratégie peut décrire une protection souhaitée sans démontrer que chaque ordinateur la reçoit. Le mode Audit peut enregistrer une activité pertinente sans la bloquer ; les exclusions peuvent modifier ce qu’une règle évalue. Examinez ensemble la source du déploiement et la configuration des appareils avant de rendre compte de la couverture.

Ce guide utilise des pages Microsoft Learn vérifiées le 3 octobre 2026 et l’implémentation examinée d’etc-collector. Les commandes PowerShell sont des exemples issus de la documentation, destinés à un administrateur Windows autorisé ; elles n’ont pas été exécutées sur un parc Windows pour cet article. Aucune couverture des appareils, fréquence d’attaque ou remédiation réussie n’est revendiquée.

Fonctionnement : une matrice des règles, modes et exclusions

La configuration ASR est une liste de règles associées à des actions individuelles. Dans la console de gestion des stratégies de groupe, modifiez la GPO prévue sous Configuration ordinateur → Modèles d’administration → Composants Windows → Microsoft Defender Antivirus → Microsoft Defender Exploit Guard → Réduction de la surface d’attaque. Ouvrez Configurer les règles de réduction de la surface d’attaque, sélectionnez Activé, puis utilisez Afficher... pour saisir chaque GUID de règle comme nom de valeur et son mode comme valeur. Les anciens modèles peuvent utiliser Windows Defender Antivirus dans le chemin. Procédure GPO de Microsoft

Les actions numériques documentées par Learn sont les suivantes :

Ces valeurs proviennent de la page de configuration ASR. La disponibilité des modes, les dépendances et la prise en charge du système d’exploitation doivent toujours être examinées règle par règle dans la référence des règles ASR.

Construisez une matrice avec une ligne par règle prévue et population cible. Les lignes suivantes sont des exemples d’examen, et non un ensemble complet de règles recommandé ou des mesures issues d’un environnement :

Microsoft documente une condition d’emplacement d’installation pour la règle Office : Office doit être installé sous %ProgramFiles% ou %ProgramFiles(x86)%. Microsoft précise aussi que la règle LSASS n’est pas nécessaire et n’apporte aucune protection supplémentaire lorsque la protection LSA est activée, et recommande cette protection avec Credential Guard. Ne considérez pas chaque règle disponible comme une exigence inconditionnelle. Détails propres aux règles

Notre guide Credential Guard après une mise à niveau explique comment vérifier l’isolation des informations d’identification fondée sur VBS et une désactivation héritée. Ces éléments ne démontrent pas la configuration de l’ensemble plus large des règles comportementales ASR. Distinguez l’applicabilité des protections et leurs mesures.

Déterminer quelle source de gestion prévaut

Une entrée GPO et un profil Intune peuvent entrer en conflit pour une même règle. La page de configuration Learn actuelle indique que les paramètres issus de stratégies prennent le pas sur les paramètres locaux Set-MpPreference au démarrage. Elle décrit la stratégie de groupe comme prioritaire par défaut face au MDM, avec MDMWinsOverGP=1 favorisant le MDM, et déconseille de configurer les mêmes règles ASR au moyen des deux sources. Le guide de dépannage Defender, publié séparément par Microsoft, avertit que ce commutateur ne s’applique pas aux règles ASR sous Windows 10. Ces pages diffèrent sur cette limite : vérifiez le système d’exploitation cible et le résultat de stratégie observé au lieu de supposer que l’indicateur résout tous les conflits.

Une autre limite est explicite : la configuration contrôlée impose les paramètres Intune ou ceux de la gestion des paramètres de sécurité de Defender for Endpoint et ignore les paramètres conflictuels de stratégie de groupe, de Configuration Manager et les paramètres locaux. Vérifiez si ce mécanisme s’applique avant d’attribuer la responsabilité à la GPO. Gestion des conflits de stratégies par Microsoft

Consignez la source de gestion prévue, la population d’appareils, les profils conflictuels et les éléments démontrant la configuration qui prévaut. Une modification PowerShell locale temporaire peut disparaître lorsque la stratégie gérée prend effet. Elle ne constitue donc pas, à elle seule, une preuve suffisante que le déploiement géré est corrigé.

Détection : comparer l’intention de la GPO à la configuration des appareils

Étape 1 : conserver la stratégie prévue

Lisez la liste des GUID/actions configurés et les exclusions dans la GPO réelle. Inspectez ses données registry.pol décodées pour la branche ASR de Windows Defender Exploit Guard, en conservant l’identité de la GPO et l’heure de collecte avec les éléments de preuve. Un fichier de stratégie binaire doit être décodé avec un outil adapté aux stratégies ; son seul nom ne révèle pas ses paramètres.

Distinguez la liste par règle du DWORD agrégé exploitguard_asr_rules utilisé par le parseur du collector décrit plus bas. Un paramètre agrégé activé n’est pas un inventaire de GUID et d’actions.

Notre guide des quatre contrôles de sécurité GPO Active Directory applique la même méthode de vérification à LLMNR, WSUS, à la protection LSA et aux chemins UNC : comparer l’intention de la stratégie, le périmètre cible et les preuves côté client. Ces quatre contrôles ne démontrent pas la couverture ASR ; leur rigueur de vérification est utile ici.

Étape 2 : lire les préférences de l’appareil cible

Sur chaque cible évaluée, récupérez les préférences Defender. La référence Get-MpPreference documente la cmdlet et son comportement local par défaut. La page de configuration ASR documente les propriétés des identifiants de règles et des actions.

Exécutez les commandes suivantes séparément dans la session PowerShell administrative de la cible :

$p = Get-MpPreference

$p.AttackSurfaceReductionRules_Ids

$p.AttackSurfaceReductionRules_Actions

Associez les entrées selon leur position dans les tableaux : l’action à un indice appartient à l’identifiant de règle au même indice. Conservez la sortie d’origine. Si l’une des listes manque, si leurs longueurs diffèrent ou si la collecte échoue, consignez le résultat comme non résolu au lieu d’écarter silencieusement des entrées ou de déclarer la conformité.

Pour une paire de tableaux alignés et non vides, cet exemple affiche la correspondance :

for ($i = 0; $i -lt $p.AttackSurfaceReductionRules_Ids.Count; $i++) {
    [pscustomobject]@{
        Id = $p.AttackSurfaceReductionRules_Ids[$i]
        Action = $p.AttackSurfaceReductionRules_Actions[$i]
    }
}

Examinez les exclusions ASR globales avec la commande de lecture documentée par Microsoft :

(Get-MpPreference).AttackSurfaceReductionOnlyExclusions

Inspectez également les exclusions par règle dans la stratégie de gestion faisant autorité. La liste globale seule ne constitue pas un examen complet des exceptions lorsque des exclusions propres aux règles sont configurées. Configuration des exclusions Microsoft

Comparez chaque GUID et mode attendu à la sortie de l’appareil. Examinez les règles manquantes, les actions inattendues et les exclusions inattendues. Incluez l’hôte, l’heure d’observation et la source de gestion dans le compte rendu ; répétez la collecte après l’application de la stratégie pour distinguer un paramètre local transitoire du résultat géré. Ces préférences établissent la configuration de l’appareil, tandis que la télémétrie d’activité fournit des preuves du déclenchement d’une règle.

Étape 3 : examiner les événements ASR

Dans l’Observateur d’événements, accédez à Journaux des applications et des services → Microsoft → Windows → Windows Defender → Operational. Microsoft répertorie les événements de règles ASR suivants sur sa page consacrée à l’Observateur d’événements Windows :

Mettez en relation l’identifiant de règle, l’appareil, l’heure et l’activité avec la matrice de configuration. Microsoft documente aussi Windows Event Forwarding pour centraliser la collecte. Son guide de test du déploiement distingue l’Observateur d’événements local des fonctions de reporting qui dépendent du produit Defender et de l’offre utilisée.

Remédiation : tester, examiner et appliquer les règles approuvées (Remediation)

Étape 1 : définir un pilote représentatif

Choisissez une population d’appareils contrôlée et des responsables applicatifs. Vérifiez la prise en charge et les dépendances des règles sélectionnées, établissez la source de gestion et consignez les préférences initiales des appareils. Incluez les flux de travail métier susceptibles de solliciter les règles, plutôt que de considérer un appareil inactif comme un test de compatibilité.

Le guide de déploiement de Microsoft organise le travail en planification, test, activation et surveillance continue. Il indique que les règles de protection standard peuvent généralement commencer en mode Block ou Warn sans test, tandis que les autres règles doivent d’abord être évaluées en mode Audit. Le pilote Audit est ici un choix d’évaluation délibéré, et non une affirmation selon laquelle Microsoft impose la même séquence pour chaque règle.

Étape 2 : configurer Audit dans la stratégie responsable

Pour le pilote géré par GPO, activez Configurer les règles de réduction de la surface d’attaque et renseignez Afficher... avec les GUID sélectionnés et l’action 2. Utilisez les valeurs documentées sans guillemets, caractères supplémentaires ou espaces en début ou fin. Confirmez que les ordinateurs du pilote prévu reçoivent cette GPO, puis répétez la collecte des préférences des appareils.

Par exemple, le nom de valeur de la règle Office sur les processus enfants est d4f940ab-401b-4efc-aadc-ad5f3c50688a ; sa valeur Audit est 2. Cela illustre la correspondance GUID/action de Microsoft, et non une configuration découverte. Configuration GPO des règles

Étape 3 : examiner les événements et documenter les exceptions applicatives

Utilisez l’activité Audit pour identifier les flux de travail légitimes que l’application des règles pourrait interrompre. Examinez le contexte réel du processus et du fichier avec le responsable applicatif avant d’approuver une exclusion. Consignez la règle concernée, l’exception exacte, sa raison, son responsable et la décision d’examen.

La stratégie de groupe fournit des exclusions globales et des exclusions par règle. Dans sa procédure GPO globale, Learn présente les exclusions de fichiers spécifiques comme préférables à l’exclusion d’un dossier entier. Les exclusions propres aux règles nécessitent les modèles d’administration adaptés ; la page actuelle indique les modèles 24H2 ou ultérieurs lorsque ce paramètre est absent de GPMC. Vérifiez la disponibilité du paramètre avant de concevoir le déploiement autour de celui-ci. Exclusions GPO Microsoft

Étape 4 : passer à Block ou à Warn pris en charge, puis vérifier de nouveau

Modifiez les actions approuvées dans la stratégie responsable pour utiliser Block 1, ou Warn 6 lorsque ce mode est pris en charge et approprié. La règle contre le vol d’informations d’identification LSASS ne prend pas en charge Warn. Élargissez le déploiement par anneaux après avoir examiné le comportement des applications et la configuration des appareils. Guide de déploiement et référence des règles

Répétez la comparaison GUID/action et examinez les événements Block ou les contournements Warn. Une modification de GPO terminée n’est pas le critère d’acceptation. Clôturez la décision de déploiement pour une population lorsque la configuration prévue est observée sur ses appareils évalués, que les flux de travail pertinents ont été examinés et que les exceptions restantes ou les appareils inconnus sont explicités.

Évitez de remplacer une liste de règles gérée par une commande locale de facilité. Microsoft avertit que Set-MpPreference écrase les règles et actions existantes fournies au moyen de cette cmdlet, et que les paramètres gérés écrasent les modifications locales conflictuelles au démarrage. Résolvez le conflit de sources et préservez la configuration sans rapport avec celui-ci. Comportement de la configuration PowerShell

Comment EtcSec détecte cette configuration

L’etc-collector d’EtcSec comprend DEFENDER_ASR_NOT_CONFIGURED, un contrôle de configuration GPO de sévérité Medium. L’implémentation examinée de defender-asr.go appelle FindRegistrySettingInt pour DefenderASREnabled. Une valeur absente ou différente de 1 produit Count 1 ; une valeur de 1 laisse Count 0.

Le helper privilégie une valeur non nulle de Default Domain Controllers Policy, puis de Default Domain Policy, puis d’une autre GPO disponible. Il s’agit de l’ordre de recherche du collector, et non de la précédence des stratégies Windows pour un appareil individuel. Il ne calcule pas les liens effectifs, le filtrage, l’héritage ou les conflits MDM de chaque ordinateur.

Le fichier registrypol_parser.go examiné renseigne le champ uniquement à partir d’un DWORD nommé exploitguard_asr_rules dans une clé contenant Windows Defender et ASR. Il ne renseigne pas l’inventaire complet des GUID/actions pour ce contrôle. La valeur agrégée comparée à 1 ne doit pas être interprétée comme l’action Block de chaque règle.

Utilisez ce signal pour ouvrir une investigation ciblée sur la configuration. Joignez la liste GPO prévue, les préférences des appareils et les événements ASR pertinents au dossier de remédiation. Laissez les mesures indisponibles non résolues jusqu’à leur collecte ; un contrôle de configuration à l’échelle du domaine ne peut pas remplacer les preuves provenant des appareils.