Exploit protection : atténuations système et par application

Exploit protection est la partie de Windows qui rend plus difficile la transformation d'un bogue de corruption mémoire en exécution de code. C'est le successeur intégré d'EMET (Enhanced Mitigation Experience Toolkit), livré avec Windows 10 1709 et ultérieur, Windows 11 et Windows Server 2019 et ultérieur. Là où les règles ASR bloquent des comportements suspects (Word qui lance PowerShell), exploit protection bloque les techniques qu'un exploit utilise pour y parvenir : exécuter des données, enchaîner une chaîne de programmation orientée retour, charger une DLL non signée dans un processus durci.

Le pilier ASR ne l'aborde qu'en passant. Ce guide couvre l'ensemble du travail : ce que les valeurs par défaut apportent déjà, quelles atténuations par application valent la peine, comment les tester en mode audit et comment livrer une configuration unique à tout le parc. Pour une vue d'ensemble du domaine, voir Réduction de la surface d'attaque.

Organisation des paramètres

Exploit protection comporte deux niveaux :

• Les paramètres système s'appliquent à tous les processus, sauf si un paramètre d'application les remplace.
• Les paramètres de programme s'appliquent à un exécutable nommé (éventuellement avec son chemin complet) et permettent d'activer des atténuations qui seraient trop perturbatrices à l'échelle du système.

Chaque atténuation peut être activée, désactivée ou par défaut, et plusieurs prennent en charge un état audit qui journalise ce qui aurait été bloqué. Les mêmes paramètres sont visibles dans Windows Security > App & browser control > Exploit protection settings, mais sur les appareils gérés, pilotez-les depuis un fichier XML distribué par stratégie, pas par des clics.

La première tâche consiste simplement à vérifier que rien ne les a désactivées. Les anciens scripts de masterisation, les réglages pour les jeux et les guides « d'optimisation des performances » désactivent parfois DEP ou CFG.

Étape 1 : capturer l'état actuel

Sur une machine de référence, examinez la configuration effective au niveau système et par application :

# Atténuations à l'échelle du système
Get-ProcessMitigation -System

# Une application
Get-ProcessMitigation -Name winword.exe

# Toutes les applications qui ont des paramètres par programme
Get-ProcessMitigation | Where-Object { $_.ProcessName } |
  Select-Object ProcessName -Unique

Windows est livré avec certains paramètres par application, et une installation neuve constitue la meilleure référence. Exportez-la pour pouvoir la comparer plus tard :

Get-ProcessMitigation -RegistryConfigFilePath C:\Temp\ep-baseline.xml

Si vous avez encore une stratégie EMET datant de plusieurs années, convertissez-la et traitez-la comme une liste d'idées, pas comme une configuration à appliquer :

ConvertTo-ProcessMitigationPolicy -EMETFilePath C:\Temp\emet.xml -OutputFilePath C:\Temp\ep-from-emet.xml

Étape 2 : choisir les atténuations par application

C'est dans les atténuations par application qu'exploit protection montre toute sa valeur, mais c'est aussi là qu'il casse des choses. Ciblez les applications qui analysent des entrées non fiables et ne sont pas déjà fortement isolées : lecteurs de documents, clients métier anciens qui ouvrent des fichiers reçus par e-mail, lecteurs multimédias, outils d'archivage et anciens composants serveur exposés à Internet que vous ne pouvez pas encore remplacer.

Les navigateurs et Office de Microsoft activent déjà en interne beaucoup de ces atténuations, et les navigateurs basés sur Chromium gèrent leur propre bac à sable. N'empilez pas ACG ou CIG par-dessus Edge ou Chrome ; configurez plutôt le navigateur (voir le durcissement d'Edge). Microsoft avertit aussi qu'EAF, IAF et les atténuations ROP peuvent entrer en conflit avec les EDR et produits anti-triche qui posent des hooks sur les mêmes fonctions : testez sur des appareils qui exécutent votre véritable pile de sécurité.

Étape 3 : tester en mode audit

Construisez les paramètres par application sur une machine de test, en commençant en audit lorsque l'atténuation le permet :

# Auditer ACG et la création de processus enfants pour une visionneuse héritée
Set-ProcessMitigation -Name "C:\Program Files\Contoso\Viewer\viewer.exe" `
  -Enable AuditDynamicCode, AuditChildProcess

# Appliquer directement les atténuations à faible risque
Set-ProcessMitigation -Name viewer.exe -Enable BlockRemoteImages, BlockLowLabel

Les noms de paramètres correspondent aux options d'atténuation (par exemple DisallowChildProcessCreation, AuditChildProcess, DynamicCode, AuditDynamicCode, MicrosoftSignedOnly, ForceRelocateImages). L'audit d'EAF, d'IAF et des atténuations ROP n'est pas disponible via les applets de commande PowerShell : configurez-le dans l'application Sécurité Windows et exportez le XML. Exécutez Get-Help Set-ProcessMitigation -Full sur votre build pour obtenir la liste prise en charge, car les nouvelles versions ajoutent des options.

Exploit protection écrit dans deux journaux sous Applications and Services Logs > Microsoft > Windows > Security-Mitigations : KernelMode et UserMode. Chaque atténuation auditée a un événement d'audit et un événement d'application ; par exemple, ACG journalise 1 (audit) et 2 (bloqué), et la création de processus enfants 3 (audit) et 4 (bloqué). Consultez la référence des événements exploit protection de Microsoft pour la correspondance complète sur votre build.

Get-WinEvent -LogName "Microsoft-Windows-Security-Mitigations/UserMode",
                       "Microsoft-Windows-Security-Mitigations/KernelMode" -MaxEvents 200 |
  Select-Object TimeCreated, LogName, Id, Message

Utilisez l'application normalement pendant une ou deux semaines : ouvrez les fichiers inhabituels, imprimez, lancez la vérification des mises à jour, utilisez les plug-ins. L'absence d'événements d'audit signifie que l'atténuation peut être appliquée. Des événements liés à un vrai flux de travail signifient qu'il faut soit laisser cette atténuation désactivée, soit demander un correctif à l'éditeur.

Étape 4 : exporter et déployer le XML

Une fois la machine de test stable, exportez la configuration complète. Le fichier contient à la fois les paramètres système et ceux des applications :

Get-ProcessMitigation -RegistryConfigFilePath \\corp.example\NETLOGON\ExploitProtection\ep-settings.xml

Stratégie de groupe. Placez le XML sur un partage lisible par les ordinateurs, puis réglez Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Defender Exploit Guard > Exploit Protection > Use a common set of exploit protection settings sur Enabled avec le chemin UNC. Les ADMX récents peuvent afficher le dossier sous le nom Microsoft Defender Exploit Guard. La stratégie stocke le chemin dans HKLM\SOFTWARE\Policies\Microsoft\Windows Defender ExploitGuard\Exploit Protection et l'appareil applique le fichier à la prochaine actualisation.

Intune. Utilisez Endpoint security > Attack surface reduction > Create policy > Exploit Protection et collez ou téléversez le XML. Le CSP sous-jacent est ExploitGuard/ExploitProtectionSettings.

Verrouiller. Empêchez les modifications locales via l'application Sécurité Windows avec Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Security > App and browser protection > Prevent users from modifying settings (dans Intune, le paramètre Disallow Exploit Protection Override du même profil).

Traitez le XML comme du code : conservez-le sous gestion de versions, modifiez-le via une pull request et déployez-le par anneaux, comme vous le feriez pour des règles ASR ou un référentiel de sécurité.

Ce qui casse

• L'ASLR obligatoire à l'échelle du système est la panne auto-infligée classique : les anciens installeurs et les DLL sans données de relocalisation plantent au chargement. Gardez-le par application.
• CIG et ACG sur des applications avec plug-ins ou JIT échouent silencieusement ou plantent dès la première utilisation du plug-in.
• Do not allow child processes empêche l'application d'ouvrir un navigateur pour les liens d'aide, de lancer son programme de mise à jour ou d'appeler une imprimante PDF.
• Disable extension points casse les méthodes d'entrée des langues d'Asie de l'Est et certains outils d'accessibilité.
• EAF/IAF et les atténuations ROP peuvent entrer en conflit avec les hooks d'EDR. Le symptôme est un plantage dans la DLL du produit de sécurité, pas dans l'application.
• Hardware-enforced stack protection ne fonctionne que sur les processeurs compatibles CET et, en mode strict, bloque les DLL incompatibles chargées dans le processus.

Lorsque quelque chose casse après le déploiement, Get-ProcessMitigation -Name app.exe sur l'appareil concerné indique ce qui est réellement appliqué, et les journaux Security-Mitigations indiquent quelle atténuation s'est déclenchée.

Vérifier

Sur un échantillon d'appareils après actualisation de la stratégie :

# Valeurs système par défaut intactes
Get-ProcessMitigation -System | Format-List DEP, ASLR, CFG, SEHOP, Heap

# Vos paramètres par application appliqués
Get-ProcessMitigation -Name viewer.exe

# Chemin de la stratégie présent
Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender ExploitGuard\Exploit Protection" -ErrorAction SilentlyContinue

Transférez les deux journaux Security-Mitigations vers votre SIEM. Une rafale soudaine d'événements d'application sur un hôte signale soit une mise à jour défectueuse, soit une tentative d'exploitation, et les deux méritent examen.

Sa place dans l'ensemble

Exploit protection est une couche de la sécurité mémoire. Côté noyau, l'intégrité de la mémoire (HVCI) et VBS protègent le noyau contre la même catégorie d'attaques, et sous Windows 11 avec HVCI et un processeur compatible CET, vous pouvez aussi activer la protection de pile appliquée par le matériel en mode noyau depuis Windows Security > Device security > Core isolation. Au-dessus, le contrôle des applications décide de ce qui peut s'exécuter. Pour la définition du terme, voir l'entrée du glossaire exploit protection.

Liste de contrôle

• Atténuations système (DEP, CFG, ASLR ascendant et à haute entropie, SEHOP, intégrité du tas) vérifiées actives sur tout le parc
• Applications héritées exposées identifiées et atténuations par application choisies
• Atténuations testées en mode audit, événements Security-Mitigations examinés
• XML exporté, versionné et déployé par GPO ou Intune
• Remplacement local bloqué avec Prevent users from modifying settings
• Journaux Security-Mitigations transférés et sous alerte