Attack Surface Reduction (ASR)¶

1. Qu'est-ce que l'Attack Surface Reduction¶

Les règles ASR, pour Attack Surface Reduction, font partie de Microsoft Defender. Elles visent des techniques d'attaque précises, pas une logique générale de liste blanche.

ASR ne dit pas "seuls ces binaires sont autorisés". ASR dit plutôt "ce type d'action est interdit", par exemple lorsqu'Office tente de créer un processus enfant, ou lorsqu'un script fortement obfusqué s'exécute.

Cette différence est structurante. ASR est un contrôle comportemental ciblé. WDAC est un contrôle d'autorisation d'exécution.

Les règles ASR sont particulièrement utiles pour freiner :

• les chaînes Office macro -> cmd.exe -> powershell.exe ;
• les scripts obfusqués ou fortement encodés ;
• les scripts JavaScript et VBScript qui lancent du contenu téléchargé ;
• les tentatives d'accès à lsass.exe pour voler des secrets ;
• certaines phases préparatoires observées dans les campagnes ransomware.

ASR complète très bien AppLocker, WDAC et Defender. Il ne les remplace pas. Un poste bien durci cumule plusieurs couches, chacune traitant un moment différent de la chaîne d'attaque.

2. Prérequis¶

Avant de déployer ASR, trois axes doivent être validés : le moteur Defender, la version de Windows, et le niveau de licence réellement disponible.

2.1 Microsoft Defender Antivirus actif¶

Microsoft documente un prérequis clair : Microsoft Defender Antivirus doit être l'antivirus actif, avec la protection en temps réel activée.

Si un autre antivirus est installé et prend la main, Defender peut se désactiver. Dans ce cas, les règles ASR ne sont pas dans l'état attendu.

Certaines règles s'appuient aussi sur des composants complémentaires, comme AMSI ou la protection cloud. Il faut donc maintenir Defender à jour : plateforme, moteur et intelligence de sécurité.

2.2 Version minimale de Windows¶

ASR est disponible à partir de Windows 10 version 1709. La couverture exacte varie ensuite selon la règle, la version de Windows, et côté serveur selon l'OS.

Toutes les règles ne sont pas uniformément disponibles sur toutes les versions Windows Server. Il faut vérifier la matrice par règle avant de standardiser.

2.3 Licences¶

Microsoft recommande une licence Microsoft Defender XDR E5, Windows E5 ou A5 pour tirer parti du reporting avancé et du pilotage complet à grande échelle.

Pour le jeu complet des règles ASR et leur support officiel, Microsoft renvoie aussi vers un niveau de licence Windows Enterprise. Dans la pratique, certaines fonctions existent sur d'autres éditions, mais il faut distinguer "fonctionne techniquement" et "supporté officiellement".

2.4 Vérifications utiles¶

Ouvrez winver, eventvwr.msc ou powershell.exe via Win + R. Ne commencez pas par la GPO si les prérequis locaux ne sont pas valides.

3. Modes de fonctionnement¶

ASR prend en charge quatre états utiles en exploitation : Disabled, Audit, Block et Warn. Le choix du mode se fait par règle.

Le mode Audit est le mode de départ normal. Il sert à mesurer l'impact réel. Le mode Block ne devrait venir qu'après lecture des événements.

Le mode Warn peut être utile pour accompagner un changement, mais il n'est pas universel. Par exemple, la règle LSASS ne supporte pas Warn.

Il existe aussi la notion Not configured dans certaines interfaces de gestion. Elle ne doit pas être confondue avec un vrai choix de sécurité. Pour une politique maîtrisée, explicitez chaque règle importante.

4. Les règles ASR les plus importantes¶

Les cinq règles ci-dessous offrent un excellent rendement défensif. Elles couvrent des scénarios vus très souvent sur poste de travail.

4.1 Block Office apps from creating child processes¶

GUID : D4F940AB-401B-4EFC-AADC-AD5F3C50688A

Cette règle bloque les applications Office lorsqu'elles tentent de créer des processus enfants. Elle vise les chaînes Word ou Excel -> cmd.exe, powershell.exe, wscript.exe, etc.

Le bénéfice est immédiat contre les macros malveillantes, les documents piégés et les charges utiles lancées via Office. Le risque de faux positif existe dans les environnements où Office déclenche des scripts métiers ou des tâches d'administration.

Microsoft précise aussi que certaines règles Office s'appuient sur des chemins d'installation Office standard, principalement sous %ProgramFiles% ou %ProgramFiles(x86)%.

4.2 Block execution of potentially obfuscated scripts¶

GUID : 5BEB7EFE-FD9A-4556-801D-275E5FFC04CC

Cette règle bloque l'exécution de scripts potentiellement obfusqués. Elle cible les scripts masqués, encodés, compressés ou volontairement rendus illisibles pour contourner les contrôles.

Elle s'appuie sur Defender et AMSI. La protection cloud renforce son efficacité. Elle est très utile contre les chaînes PowerShell opportunistes.

Le faux positif est généralement modéré, mais il faut surveiller certains frameworks internes ou des scripts d'administration anciens fortement encapsulés.

4.3 Block JavaScript or VBScript from launching downloaded executable content¶

GUID : D3E037E1-3EB8-44C8-A917-57927947596D

Cette règle bloque les scripts JavaScript ou VBScript lorsqu'ils essaient de lancer du contenu exécutable téléchargé. Elle coupe un pattern classique de livraison initiale.

Elle est particulièrement pertinente contre les pièces jointes, archives et lanceurs historiques basés sur wscript ou cscript. Elle s'appuie elle aussi sur AMSI.

Dans un environnement moderne, le faux positif est souvent faible. Dans un parc ancien avec scripts .vbs hérités, l'audit préalable reste indispensable.

4.4 Block credential stealing from LSASS¶

GUID : 9E6C4E1F-7D60-472F-BA1A-A39EF669E4B2

Cette règle durcit l'accès à lsass.exe pour empêcher le vol de secrets mémoire. Elle vise des techniques associées à des outils comme Mimikatz.

Microsoft précise un point essentiel : si LSA protection est déjà activée, cette règle ASR devient généralement non nécessaire, voire non applicable. Dans un design moderne, il faut donc l'évaluer avec Credential Guard et la protection LSA.

Autre point important : Warn n'est pas recommandé et n'est pas supporté pour cette règle. Microsoft indique aussi qu'elle peut générer beaucoup de bruit en audit, et qu'un passage direct en blocage sur un petit anneau pilote peut être acceptable.

4.5 Use advanced protection against ransomware¶

GUID : C1DB55AB-C21A-4637-BB3F-A12568109D35

Cette règle ajoute une détection et un blocage agressifs contre des comportements associés aux ransomwares. Elle complète la réduction de surface d'attaque sur la phase de chiffrement ou sur des préparatifs compatibles avec les schémas observés par Defender.

La protection cloud améliore là encore l'efficacité. Le faux positif dépend du parc. Il est plus élevé si vous avez des logiciels qui manipulent massivement des fichiers ou des outils d'automatisation peu communs.

5. Déploiement via GPO¶

Le chemin GPO demandé est :

Computer Configuration > Administrative Templates > Windows Components > Microsoft Defender Antivirus > Microsoft Defender Exploit Guard > Attack Surface Reduction

Dans ce nœud, la stratégie clé est : Configure Attack Surface Reduction rules

Ouvrez gpmc.msc via Win + R, éditez une GPO dédiée, puis saisissez chaque GUID avec son état.

Une stratégie distincte pour ASR simplifie :

• la lecture de l'intention ;
• le dépannage ;
• l'audit de changement ;
• le rollback si une règle pose problème.

Évitez de basculer toutes les règles prioritaires en Block le même jour. Un anneau pilote IT, puis un anneau métier réduit, permettent de lire les événements avant généralisation.

6. Déploiement via registre¶

Le chemin registre demandé est :

HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Windows Defender Exploit Guard\ASR\Rules

Dans ce modèle, chaque nom de valeur est le GUID de la règle, et la donnée est l'état voulu.

Exemple conceptuel :

HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Windows Defender Exploit Guard\ASR\Rules
  D4F940AB-401B-4EFC-AADC-AD5F3C50688A = 2
  5BEB7EFE-FD9A-4556-801D-275E5FFC04CC = 2
  D3E037E1-3EB8-44C8-A917-57927947596D = 2
  9E6C4E1F-7D60-472F-BA1A-A39EF669E4B2 = 1
  C1DB55AB-C21A-4637-BB3F-A12568109D35 = 2

Le registre est pratique pour :

• vérifier l'état effectivement poussé ;
• dépanner un poste ;
• comparer un poste sain et un poste en écart ;
• documenter une baseline de conformité.

Ouvrez regedit via Win + R. Ne modifiez pas directement la production à la main sauf procédure prévue. Le registre sert surtout ici de point de contrôle et de support de déploiement automatisé.

7. Passage de l'audit au blocage¶

Le passage propre d'ASR repose sur les événements Defender. Pour ASR, le journal utile est :

Applications and Services Logs > Microsoft > Windows > Windows Defender > Operational

Microsoft documente notamment :

• 1121 pour certains événements de blocage ;
• 1122 pour certains événements d'audit ;
• 1129 pour les contournements utilisateur en mode Warn ;
• 5007 pour les changements de configuration.

Le schéma opérationnel minimal est le suivant :

flowchart TD
    A["Règle ASR configurée en Audit"] --> B["L'utilisateur ou le processus déclenche l'action ciblée"]
    B --> C["Windows Defender journalise l'événement 1122"]
    C --> D["Analyse des événements et des faux positifs"]
    D --> E["Ajustement des exclusions ou validation métier"]
    E --> F["Passage de la règle en Block"]
    F --> G["Nouvelle tentative de l'action"]
    G --> H["Blocage et événement 1121"]

Ce flux paraît simple. Il échoue pourtant souvent pour une seule raison : les événements ne sont pas relus, pas classés, ou pas corrélés à un contexte métier.

8. Matrice complète des règles ASR¶

La table ci-dessous reprend les règles ASR publiées par Microsoft au moment de cette version du chapitre. Elle sert de matrice de pilotage : GUID, intention, mapping MITRE indicatif, mode de départ et risque de faux positif.

Le mode recommandé n'est pas universel. Il suppose un parc raisonnablement standardisé, un moteur Defender sain, et une équipe capable de lire les événements.

Dans un parc très hétérogène, allongez la phase d'audit pour Office et scripts. Pour LSASS, raisonnez avec Credential Guard et la protection LSA, pas comme une règle isolée.

Exploit Protection¶

Exploit Protection applique des mitigations au niveau système ou par processus : DEP, ASLR, blocage de certains comportements mémoire, restrictions de chargement et paramètres compatibles avec les politiques héritées d'EMET.

En entreprise, le bon modèle consiste à exporter une configuration XML depuis un poste de référence, à la relire, puis à la déployer par GPO, Intune ou outil de configuration. Un mauvais profil global peut casser une application métier, surtout si elle embarque des composants anciens.

Get-ProcessMitigation -RegistryConfigFilePath "C:\Temp\ExploitProtection.xml"

Set-ProcessMitigation -PolicyFilePath "C:\Temp\ExploitProtection.xml"

Network Protection¶

Network Protection étend Microsoft Defender SmartScreen et la protection cloud au trafic sortant. Il peut bloquer ou auditer les connexions vers des domaines et adresses réputés malveillants, notamment depuis des processus autres que le navigateur.

Le paramètre se pilote typiquement en Audit au départ, puis en Block une fois le bruit maîtrisé. La protection cloud et l'état réel de Defender sont déterminants.

Get-MpPreference | Select-Object EnableNetworkProtection

Controlled Folder Access¶

Controlled Folder Access protège des dossiers sensibles contre les modifications par des applications non approuvées. Il est utile contre des comportements de chiffrement ou de modification massive de fichiers, mais il peut produire des faux positifs sur les outils métiers, les scripts et certains agents de sauvegarde.

Les exclusions doivent être rares, justifiées et révisées. Une exclusion trop large transforme la protection en simple affichage de conformité.

Get-MpPreference | Select-Object EnableControlledFolderAccess, ControlledFolderAccessProtectedFolders

Tamper Protection¶

Tamper Protection protège les réglages de sécurité Microsoft Defender contre des modifications non autorisées. Elle limite les changements locaux ou scriptés qui tenteraient de désactiver la protection.

Dans un parc moderne, elle se pilote plutôt via Intune, Microsoft Defender for Endpoint ou le portail de sécurité que par bricolage local. Une GPO qui semble correcte peut ne pas produire l'effet attendu si un mécanisme de protection supérieur verrouille le paramètre.

Smart App Control (mention)¶

Smart App Control est une protection Windows 11 qui aide à bloquer les applications non fiables ou malveillantes. Elle est surtout pertinente sur des installations neuves ou réinitialisées et n'est pas le substitut d'une politique d'entreprise WDAC.

Pour un design administré, utilisez plutôt App Control for Business / WDAC, avec une politique signée, versionnée et testée. Smart App Control peut être mentionné dans la stratégie poste, mais il ne doit pas être votre unique contrôle d'exécution.