Référence de la protection contre les exploits

Exploit Protection fournit des protections avancées pour les applications que les administrateurs d’entreprise et les professionnels de l’informatique peuvent appliquer après qu’un développeur compile et distribue des logiciels.

Cet article vous aide à comprendre le fonctionnement de la protection contre les attaques, tant au niveau de la stratégie qu’au niveau de l’atténuation individuelle, pour vous aider à créer et à appliquer des stratégies de protection contre les attaques.

Comment les atténuations sont appliquées

Les mesures d’atténuation de la protection contre les exploits sont appliquées pour chaque application.

Chaque programme possède sa propre entrée de Registre qui contrôle les mesures d’atténuation qui s’appliquent. Ces paramètres sont stockés dans l’entrée de Registre MitigationOptions (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\*ImageFileName*\MitigationOptions). Ces paramètres d’atténuation prennent effet lorsque vous redémarrez le programme. Ils restent actifs jusqu’à ce que vous les modifiez et redémarrez le programme.

Importante

Les options d’exécution de fichier image vous permettent de spécifier un nom de fichier ou un chemin d’accès. Vous ne pouvez pas spécifier un numéro de version, une architecture ou un autre différentiateur. Cibler des atténuations pour les applications qui ont des noms ou des chemins uniques. Appliquez-les uniquement sur les appareils où vous avez testé cette version et l’architecture de l’application.

Vous pouvez configurer des atténuations via un fichier XML à l’aide de PowerShell, d’une stratégie de groupe ou d’une gestion des appareils mobiles. Lorsque vous utilisez un fichier XML, le système définit les entrées de Registre pour vous.

Réinitialisation de la protection contre les exploits

Importante

Lorsque la stratégie de groupe ou la stratégie GPM qui déploie le fichier XML n’est plus appliquée, les paramètres déployés par ce fichier de configuration XML ne seront pas automatiquement supprimés.

Pour supprimer les paramètres exploit protection, exportez la configuration XML à partir d’un appareil propre Windows 10 ou Windows 11, puis déployez ce nouveau fichier XML. Sinon, Microsoft fournit un fichier XML dans le cadre des bases de référence Sécurité Windows pour réinitialiser les paramètres de protection contre les attaques.

Pour réinitialiser les paramètres de protection contre les attaques à l’aide de PowerShell, exécutez la commande suivante pour appliquer la stratégie de réinitialisation à partir du fichier XML et restaurer les paramètres d’atténuation par défaut :

Set-ProcessMitigation -PolicyFilePath EP-reset.xml

Le fichier XML suivant est le EP-reset.xml distribué avec les bases de référence Sécurité Windows. Ce fichier définit les remplacements d’atténuation par application qui réinitialisent les paramètres de protection contre les attaques par défaut pour les applications courantes telles que les Microsoft Office, les navigateurs web et les lecteurs multimédias :

<?xml version="1.0" encoding="UTF-8"?>
<MitigationPolicy>
  <AppConfig Executable="ONEDRIVE.EXE">
    <DEP OverrideDEP="false" />
    <ASLR OverrideRelocateImages="false" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
    <ImageLoad OverrideBlockRemoteImages="false" />
  </AppConfig>
  <AppConfig Executable="firefox.exe">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
  </AppConfig>
  <AppConfig Executable="fltldr.exe">
    <DEP OverrideDEP="false" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
    <ImageLoad OverrideBlockRemoteImages="false" />
    <ChildProcess OverrideChildProcess="false" />
  </AppConfig>
  <AppConfig Executable="GROOVE.EXE">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
    <ImageLoad OverrideBlockRemoteImages="false" />
    <ChildProcess OverrideChildProcess="false" />
  </AppConfig>
  <AppConfig Executable="Acrobat.exe">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="AcroRd32.exe">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="chrome.exe">
    <DEP OverrideDEP="false" />
  </AppConfig>
  <AppConfig Executable="EXCEL.EXE">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="iexplore.exe">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="INFOPATH.EXE">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="java.exe">
    <DEP OverrideDEP="false" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="javaw.exe">
    <DEP OverrideDEP="false" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="javaws.exe">
    <DEP OverrideDEP="false" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="LYNC.EXE">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="MSACCESS.EXE">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="MSPUB.EXE">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="OIS.EXE">
    <DEP OverrideDEP="false" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="OUTLOOK.EXE">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="plugin-container.exe">
    <DEP OverrideDEP="false" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="POWERPNT.EXE">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="PPTVIEW.EXE">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="VISIO.EXE">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="VPREVIEW.EXE">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="WINWORD.EXE">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="wmplayer.exe">
    <DEP OverrideDEP="false" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="wordpad.exe">
    <DEP OverrideDEP="false" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
</MitigationPolicy>

Informations de référence sur l’atténuation

Les atténuations de protection contre les attaques suivantes incluent chacune une description, des considérations de compatibilité et des options de configuration.

Arbitrary Code Guard

Les sections suivantes décrivent le fonctionnement arbitraire de la protection du code, son impact sur la compatibilité et ses options de configuration.

Description

La protection contre le code arbitraire permet de se protéger contre un attaquant malveillant qui charge le code de son choix dans la mémoire par le biais d'une vulnérabilité de sécurité de la mémoire et qui est en mesure d'exécuter ce code.

La protection de code arbitraire protège une application contre l’exécution de code généré dynamiquement (code qui n’est pas chargé, par exemple, à partir de l’exe lui-même ou d’une dll). La protection de code arbitraire fonctionne en empêchant la mémoire d’être marquée comme exécutable. Lorsqu’une application tente d’allouer de la mémoire, nous vérifions les indicateurs de protection. (La mémoire peut être allouée avec des indicateurs de protection de lecture, d’écriture et/ou d’exécution.) Si l’allocation tente d’inclure l’indicateur de protection d’exécution, l’allocation de mémoire échoue et retourne un code d’erreur (STATUS_DYNAMIC_CODE_BLOCKED). De même, si une application tente de modifier les indicateurs de protection de la mémoire qui a déjà été alloué et inclut l’indicateur de protection d’exécution, le changement d’autorisation échoue et retourne un code d’erreur (STATUS_DYNAMIC_CODE_BLOCKED).

En empêchant la définition de l’indicateur d’exécution, la fonctionnalité de prévention de l’exécution des données de Windows 10 et Windows 11 peut ensuite se protéger contre le pointeur d’instruction défini sur cette mémoire et exécutant ce code.

Considérations en matière de compatibilité

Arbitrary Code Guard empêche d'allouer de la mémoire avec des droits d'exécution, ce qui pose un problème de compatibilité avec des techniques telles que les compilateurs JIT (juste-à-temps). La plupart des navigateurs modernes, par exemple, compilent JavaScript en code natif afin d’optimiser les performances. Pour prendre en charge cette atténuation, ils doivent être réarchitectés pour déplacer la compilation JIT en dehors du processus protégé. D’autres applications dont la conception génère dynamiquement du code à partir de scripts ou d’autres langages intermédiaires sont également incompatibles avec cette atténuation.

Options de configuration

Autoriser le refus de thread : vous pouvez configurer l’atténuation pour permettre à un thread individuel de refuser cette protection. Le développeur doit écrire l’application avec connaissance de cette atténuation et appeler l’API SetThreadInformation avec le paramètre ThreadInformation défini sur ThreadDynamicCodePolicy afin d’être autorisé à exécuter du code dynamique sur ce thread.

Auditer uniquement : vous pouvez activer cette atténuation en mode audit afin de mesurer l’impact potentiel de la compatibilité sur une application. Les événements d’audit peuvent ensuite être consultés soit dans la Visionneuse d’événements, soit à l’aide de la chasse avancée dans Defender for Endpoint.

Bloquer les images de faible intégrité

Les sections suivantes décrivent le fonctionnement du blocage des images à faible intégrité, son impact sur la compatibilité et ses options de configuration.

Description

Bloquer les images à faible intégrité empêche l’application de charger des fichiers qui ne sont pas approuvés, généralement parce qu’ils ont été téléchargés à partir d’Internet à partir d’un navigateur en bac à sable.

Cette atténuation bloque les chargements d’images si l’image a une entrée Access Control (ACE) qui accorde l’accès aux processus Low IL et qui n’a pas d’étiquette d’approbation ACE. Il est implémenté par le gestionnaire de mémoire, ce qui empêche le fichier d’être mappé à la mémoire. Si une application tente de mapper une image à faible intégrité, elle déclenche une erreur STATUS_ACCESS_DENIED. Pour plus d’informations sur le fonctionnement des niveaux d’intégrité, consultez Contrôle d'intégrité par mandat.

Considérations en matière de compatibilité

Bloquer les images à faible intégrité empêche l’application de charger les fichiers téléchargés à partir d’Internet. Si votre workflow d’application nécessite le chargement d’images téléchargées, vous souhaitez vous assurer qu’elles sont téléchargées à partir d’un processus de niveau de fiabilité plus élevé ou qu’elles sont explicitement réétiquetées afin d’appliquer cette atténuation.

Options de configuration

Audit uniquement : vous pouvez activer cette atténuation en mode audit afin de mesurer l’impact potentiel de la compatibilité sur une application. Les événements d’audit peuvent ensuite être affichés dans l’observateur d’événements ou à l’aide du repérage avancé dans Microsoft Defender pour point de terminaison.

Bloquer les images distantes

Les sections suivantes décrivent le fonctionnement du blocage des images distantes, son impact sur la compatibilité et ses options de configuration.

Description

Le blocage d’images distantes permet d’empêcher l’application de charger des fichiers hébergés sur un appareil distant, tel qu’un partage UNC. Le blocage d’images distantes permet de se protéger contre le chargement de fichiers binaires en mémoire sur un appareil externe contrôlé par l’attaquant.

Cette atténuation bloque les chargements d’images si l’image est déterminée comme étant sur un appareil distant. Il est implémenté par le gestionnaire de mémoire, ce qui empêche le fichier d’être mappé à la mémoire. Si une application tente de mapper un fichier distant, elle déclenche une erreur de STATUS_ACCESS_DENIED.

Considérations en matière de compatibilité

Bloquer les images distantes empêche l’application de charger des images à partir d’appareils distants. Si votre application charge des fichiers ou des plug-ins à partir d’appareils distants, elle ne sera pas compatible avec cette atténuation.

Options de configuration

Audit uniquement : vous pouvez activer cette atténuation en mode audit afin de mesurer l’impact potentiel de la compatibilité sur une application. Les événements d’audit peuvent ensuite être affichés dans l’observateur d’événements ou à l’aide du repérage avancé dans Microsoft Defender pour point de terminaison.

Bloquer les polices non approuvées

Les sections suivantes décrivent le fonctionnement du blocage des polices non fiables, son impact sur la compatibilité et ses options de configuration.

Description

Le blocage des polices non fiables atténue le risque qu'une faille dans l'analyse des polices permette à l'attaquant d'exécuter du code sur l'appareil. Seules les polices installées dans le répertoire windows\fonts sont chargées pour traitement par GDI.

Cette mesure d'atténuation est implémentée dans la GDI, qui valide l'emplacement du fichier. Si le fichier ne se trouve pas dans le répertoire des polices système, la police ne se charge pas pour l’analyse et l’appel échoue.

Cette mesure d'atténuation s'ajoute à la mesure d'atténuation intégrée fournie dans Windows 10 1607 et versions ultérieures, et Windows 11, qui déplace l'analyse des polices hors du noyau et dans un conteneur d'applications en mode utilisateur. Par conséquent, tout exploit basé sur l'analyse des polices se produit dans un contexte isolé et en bac à sable, ce qui réduit considérablement le risque.

Considérations en matière de compatibilité

L’utilisation la plus courante des polices en dehors du répertoire des polices système est celle des polices web. Les navigateurs modernes, tels que Microsoft Edge, utilisent DirectWrite au lieu de GDI et ne sont pas affectés. Toutefois, les navigateurs hérités, tels que Internet Explorer 11 (et le mode Internet Explorer dans le nouveau Microsoft Edge) peuvent être affectés, en particulier avec les applications telles qu’Office 365, qui utilisent des glyphes de police pour afficher l’interface utilisateur.

Options de configuration

Audit uniquement : vous pouvez activer cette atténuation en mode audit afin de mesurer l’impact potentiel de la compatibilité sur une application. Les événements d’audit peuvent ensuite être affichés dans l’observateur d’événements ou à l’aide du repérage avancé dans Microsoft Defender pour point de terminaison.

Protection de l’intégrité du code

Les sections suivantes décrivent le fonctionnement de la protection de l’intégrité du code, son impact sur la compatibilité et ses options de configuration.

Description

La protection de l’intégrité du code garantit que tous les fichiers binaires chargés dans un processus sont signés numériquement par Microsoft. La protection de l’intégrité du code inclut des signatures WHQL (Windows Hardware Quality Labs), ce qui permet aux pilotes approuvés whQL de s’exécuter dans le processus.

Cette atténuation est implémentée dans le gestionnaire de mémoire, ce qui empêche le binaire d’être mappé en mémoire. Si vous essayez de charger un fichier binaire qui n’est pas signé par Microsoft, le gestionnaire de mémoire retourne l’erreur STATUS_INVALID_IMAGE_HASH. En bloquant au niveau du gestionnaire de mémoire, cela empêche les fichiers binaires chargés par le processus et les fichiers binaires injectés dans le processus.

Considérations en matière de compatibilité

Cette atténuation bloque spécifiquement tout fichier binaire qui n’est pas signé par Microsoft. Par conséquent, il est incompatible avec la plupart des logiciels non-Microsoft, sauf si ce logiciel est distribué par le Microsoft Store (et signé numériquement par) et que l’option permettant d’autoriser le chargement d’images signées par le Microsoft Store est sélectionnée.

Options de configuration

Autorisez également le chargement d’images signées par le Microsoft Store : les applications distribuées par le Microsoft Store sont signées numériquement par le Microsoft Store, et l’ajout de cette configuration permet le chargement des fichiers binaires qui passent par le processus de certification du magasin par l’application.

Audit uniquement : vous pouvez activer cette atténuation en mode audit afin de mesurer l’impact potentiel de la compatibilité sur une application. Les événements d’audit peuvent ensuite être affichés dans l’observateur d’événements ou à l’aide du repérage avancé dans Microsoft Defender pour point de terminaison.

Protection du flux de contrôle (CFG)

Les sections suivantes décrivent le fonctionnement de control flow guard, son impact sur la compatibilité et ses options de configuration.

Description

CFG (Control Flow Guard) atténue le risque d’attaques utilisant des vulnérabilités d’altération de la mémoire en protégeant les appels de fonction indirects. Par exemple, un attaquant peut utiliser une vulnérabilité de dépassement de mémoire tampon pour remplacer la mémoire contenant un pointeur de fonction et remplacer ce pointeur de fonction par un pointeur vers le code exécutable de son choix (qui peut également être injecté dans le programme).

Cette atténuation consiste à injecter une autre vérification lors de la compilation. Avant chaque appel de fonction indirect, d’autres instructions sont ajoutées pour vérifier que la cible est une cible d’appel valide avant d’être appelée. Si la cible n’est pas une cible d’appel valide, l’application est arrêtée. Par conséquent, seules les applications compilées avec prise en charge CFG peuvent bénéficier de cette atténuation.

La vérification d’une cible valide est fournie par le noyau Windows. Lorsque des fichiers exécutables sont chargés, les métadonnées des cibles d’appel indirects sont extraites au moment du chargement et marquées comme cibles d’appel valides. En outre, lorsque la mémoire est allouée et marquée comme exécutable (par exemple pour le code généré), ces emplacements de mémoire sont également marqués comme cibles d’appel valides, pour prendre en charge des mécanismes tels que la compilation JIT.

Considérations en matière de compatibilité

Dans la mesure où les applications doivent être compilées pour prendre en charge CFG, elles déclarent implicitement leur compatibilité avec celle-ci. Par conséquent, la plupart des applications doivent fonctionner avec cette atténuation activée. Étant donné que ces vérifications sont compilées dans le fichier binaire, la configuration que vous pouvez appliquer consiste simplement à désactiver les vérifications dans le noyau Windows. En d’autres termes, l’atténuation est activée par défaut, mais vous pouvez configurer le noyau Windows pour qu’il retourne toujours « oui » si vous déterminez ultérieurement qu’il existe un problème de compatibilité que le développeur de l’application n’a pas détecté lors de ses tests, ce qui devrait être rare.

Options de configuration

Utiliser le mode CFG strict - En mode strict, tous les binaires chargés dans le processus doivent être compilés avec Control Flow Guard (ou ne contenir aucun code exécutable, comme les DLL de ressources) pour être chargés.

Remarque

La protection des flux de contrôle n’a pas de mode d’audit. Les fichiers binaires sont compilés avec cette atténuation activée.

Prévention de l’exécution des données (PED)

Les sections suivantes décrivent le fonctionnement de la prévention de l’exécution des données, son impact sur la compatibilité et ses options de configuration.

Description

La prévention de l’exécution des données (DEP) empêche l’exécution de la mémoire qui n’a pas été explicitement allouée en tant qu’exécutable. DEP permet de se protéger contre un attaquant qui injecte du code malveillant dans le processus, par exemple via un dépassement de mémoire tampon, puis exécute ce code.

Si vous essayez de définir le pointeur d’instruction sur une adresse mémoire non marquée comme exécutable, le processeur lève une exception (violation de protection générale), ce qui provoque le blocage de l’application.

Considérations en matière de compatibilité

Tous les exécutables x64, ARM et Arm64 ont la protection DEP activée par défaut, et elle ne peut pas être désactivée. Étant donné qu’une application n’est pas exécutée sans DEP, la compatibilité est supposée.

Tous les fichiers binaires x86 (32 bits) ont DEP activé par défaut, mais DEP peut être désactivé par processus. Certaines anciennes applications héritées, généralement développées avant Windows XP SP2, peuvent ne pas être compatibles avec DEP. Ces applications génèrent généralement du code dynamiquement (par exemple, la compilation JIT) ou un lien vers des bibliothèques plus anciennes (telles que des versions antérieures d’ATL) qui génèrent dynamiquement du code.

Options de configuration

Activer l’émulation ATL Thunk : cette option contrôle l’émulation ATL Thunk. ATL, la bibliothèque de modèles ActiveX, est conçu pour être aussi petit et rapide que possible. Pour réduire la taille binaire, elle utilise une technique appelée thunking. Le thunking est souvent associé à l’interaction entre le 32 bits et le 16 bits, mais ATL ne comporte aucun composant 16 bits. Au lieu de cela, pour économiser de l'espace, ATL stocke le code de l'ordinateur en mémoire qui n'est pas aligné sur les mots. Cela crée un binaire plus petit. ATL exécute ensuite ce code directement. Les versions ATL compilées avec Visual Studio 7.1 ou version antérieure (Visual Studio 2003) ne marquent pas cette mémoire comme exécutable. L'émulation de thunk résout ce problème. Les applications avec un modèle d’extension binaire (par exemple, Internet Explorer 11) ont besoin de l’émulation ATL Thunk activée.

Désactiver les points d’extension

Les sections suivantes décrivent le fonctionnement de l’atténuation par désactivation des points d’extension, son impact sur la compatibilité et ses options de configuration.

Description

L’atténuation des points d’extension Disable désactive différents points d’extension pour une application, qui peuvent être utilisés pour établir la persistance ou élever des privilèges de contenu malveillant.

Cela inclut les opérations suivantes :

• DLL AppInit : chaque fois qu’un processus démarre, le système charge la DLL spécifiée dans le contexte du processus nouvellement démarré avant d’appeler sa fonction de point d’entrée. Vous trouverez ici des détails sur les DLL AppInit. Une fois cette atténuation appliquée, les DLL AppInit ne sont pas chargées. À compter de Windows 7, les DLL AppInit doivent être signées numériquement, comme décrit ici. En outre, à compter de Windows 8, les DLL AppInit ne sont pas chargées si SecureBoot est activé, comme décrit ici.
• IME hérités : un éditeur de méthode d'entrée (IME) permet à un utilisateur de taper du texte dans une langue qui comporte plus de caractères que ce qui peut être représenté sur un clavier. Des tiers sont en mesure de créer des IDE. Un IME malveillant pourrait obtenir des informations d'identification ou d'autres informations sensibles à partir de cette capture d'entrée. Certains IME, appelés IME hérités, fonctionnent uniquement avec les applications de bureau Windows, et non avec les applications UWP. Cette mesure d’atténuation empêche également le chargement de cet ancien IME dans l’application de bureau Windows spécifiée.
• Crochets d’événements Windows – une application peut appeler l’API SetWinEventHook pour inscrire son intérêt dans un événement en cours. Une DLL est spécifiée et peut être injectée dans le processus. Cette atténuation force l'envoi du hook au processus qui l'a enregistré, au lieu de l'exécuter dans le processus via une DLL injectée.

Considérations en matière de compatibilité

La plupart de ces points d’extension sont relativement peu utilisés, de sorte que l’effet de compatibilité est généralement faible, en particulier au niveau d’une application individuelle. Le seul point à prendre en considération concerne le cas où les utilisateurs utilisent des anciens IME non Microsoft incompatibles avec l’application protégée.

Options de configuration

Il n’existe aucune option de configuration pour cette atténuation.

Remarque

La désactivation des points d’extension n’a pas de mode d’audit.

Désactiver les appels système Win32k

Les sections suivantes décrivent comment fonctionne l’atténuation « Désactiver les appels système Win32k », son impact sur la compatibilité et ses options de configuration.

Description

Win32k.sys fournit une grande surface d’attaque pour un attaquant. En tant que composant en mode noyau, il est fréquemment ciblé comme vecteur d’échappement pour les applications qui sont en bac à sable. Cette atténuation empêche les appels à win32k.sys en bloquant un thread qui se convertit en un thread GUI, qui a ensuite accès aux fonctions Win32k. Un thread n’est pas une interface graphique utilisateur lors de sa création, mais converti lors du premier appel à win32k.sys, ou via un appel d’API à IsGuiThread.

Considérations en matière de compatibilité

Cette atténuation est conçue pour les processus qui sont des processus dédiés qui ne sont pas des processus d’interface utilisateur. Par exemple, de nombreux navigateurs modernes utilisent l’isolation des processus et incorporent des processus autres que l’interface utilisateur. Toute application qui affiche une interface graphique graphique à l’aide d’un seul processus sera affectée par cette atténuation.

Options de configuration

Audit uniquement : vous pouvez activer cette atténuation en mode audit afin de mesurer l’impact potentiel de la compatibilité sur une application. Les événements d’audit peuvent ensuite être affichés dans l’observateur d’événements ou à l’aide du repérage avancé dans Microsoft Defender pour point de terminaison.

Ne pas autoriser les processus enfants

Les sections suivantes décrivent le fonctionnement de l'atténuation « Ne pas autoriser les processus enfants », son impact en matière de compatibilité et ses options de configuration.

Description

L’option Ne pas autoriser l’atténuation des processus enfants empêche une application de créer de nouvelles applications enfants. Une technique couramment utilisée par les adversaires consiste à lancer un processus de confiance sur l'appareil à l'aide d'une entrée malveillante (une attaque de type « living off the land »), ce qui nécessite souvent de lancer une autre application sur l'appareil. S’il n’existe aucune raison légitime pour laquelle une application lance un processus enfant, cette atténuation atténue ce vecteur d’attaque potentiel. L'atténuation est appliquée en définissant une propriété sur le jeton de processus, qui bloque la création d'un jeton pour le processus enfant avec le message d'erreur STATUS_CHILD_PROCESS_BLOCKED.

Considérations en matière de compatibilité

Si votre application lance d’autres applications pour quelque raison que ce soit, par exemple via des liens hypertexte qui ouvrent un navigateur ou un navigateur externe, ou qui lancent d’autres utilitaires sur l’ordinateur, cette fonctionnalité ne fonctionne plus lorsque cette mesure d’atténuation est appliquée.

Options de configuration

Audit uniquement : vous pouvez activer cette atténuation en mode audit afin de mesurer l’impact potentiel de la compatibilité sur une application. Les événements d’audit peuvent ensuite être affichés dans l’observateur d’événements ou à l’aide du repérage avancé dans Microsoft Defender pour point de terminaison.

Exporter le filtrage d’adresses

Les sections suivantes décrivent le fonctionnement du filtrage des adresses d’exportation, son impact sur la compatibilité et ses options de configuration.

Description

Le filtrage des adresses d’exportation (EAF) réduit le risque de code malveillant en examinant la table d’adresses d’exportation de tous les modules chargés pour rechercher les modules qui contiennent des API utiles pour leur attaque. Il s’agit d’une tactique courante utilisée par shellcode. Afin d'atténuer le risque d'une telle attaque, cette atténuation protège trois modules couramment attaqués :

• ntdll.dll
• kernelbase.dll
• kernel32.dll

L’atténuation protège la page mémoire dans le répertoire d’exportation qui pointe vers la table d’adresses d’exportation. La protection PAGE_GUARD est appliquée à cette page mémoire. Lorsqu’une personne tente d’accéder à cette zone mémoire, une violation STATUS_GUARD_PAGE_VIOLATION est générée. L’atténuation gère cette exception et, si l’instruction d’accès ne passe pas la validation, le processus est terminé.

Considérations en matière de compatibilité

Cette atténuation est principalement un problème pour les applications telles que les débogueurs, les applications bac à sable, les applications utilisant DRM ou les applications qui implémentent la technologie anti-débogage.

Options de configuration

Valider l’accès aux modules couramment exploités – Cette option, également appelée EAF+, ajoute des protections pour d’autres modules fréquemment attaqués :

• mshtml.dll
• flash*.ocx
• jscript*.ocx
• vbscript.dll
• vgx.dll
• mozjs.dll
• xul.dll
• acrord32.dll
• acrofx32.dll
• acroform.api

En outre, en activant EAF+, cette atténuation ajoute la protection PAGE_GUARD à la page contenant l’en-tête « MZ », les 2 premiers octets de l’en-tête DOS dans un fichier PE. Il s’agit d’un aspect du contenu de mémoire connu que shellcode peut rechercher afin d’identifier les modules potentiellement intéressants en mémoire.

Audit uniquement : vous pouvez activer cette atténuation en mode audit afin de mesurer l’impact potentiel de la compatibilité sur une application. Les événements d’audit peuvent ensuite être affichés dans l’observateur d’événements ou à l’aide du repérage avancé dans Microsoft Defender pour point de terminaison.

Forcer la randomisation des images (ASLR obligatoire)

Les sections suivantes décrivent le fonctionnement obligatoire d’ASLR, son impact sur la compatibilité et ses options de configuration.

Description

La randomisation de la disposition de l’espace d’adressage (ASLR) réduit le risque qu’un attaquant utilise sa connaissance de la disposition de la mémoire du système afin d’exécuter du code déjà présent dans la mémoire du processus et déjà marqué comme exécutable. Cela peut atténuer le risque qu’un attaquant utilise des techniques telles que les attaques de type « retour à libc », où l’adversaire définit le contexte, puis modifie l’adresse de retour pour exécuter du code existant avec le contexte qui correspond à l’objectif de l’adversaire.

L'ASLR obligatoire force un rebasement de toutes les DLL dans le processus. Un développeur peut activer ASLR à l’aide de l’option d’éditeur de liens /DYNAMICBASE, et cette atténuation a le même effet.

Lorsque le gestionnaire de mémoire mappe l’image dans le processus, l’ASLR obligatoire forcera le rebasage des DLL et des EXE qui n’activent pas l’ASLR. Notez toutefois que ce rebasement n'a pas d'entropie, et peut donc être placé à un emplacement prévisible en mémoire. Pour le rebasement et le positionnement aléatoire des binaires, cette atténuation doit être associée à la randomisation des allocations mémoire (ASLR ascendant).

Considérations en matière de compatibilité

Cet effet de compatibilité d’ASLR est généralement limité aux applications plus anciennes qui ont été créées à l’aide de compilateurs qui ont fait des hypothèses sur l’adresse de base d’un fichier binaire ou qui ont supprimé les informations de réajustement de base. Cela peut entraîner des erreurs imprévisibles, car le flux d’exécution tente de passer à l’emplacement attendu, plutôt qu’à l’emplacement réel, en mémoire.

Options de configuration

Ne pas autoriser les images dépouillées : cette option bloque le chargement des images dont les informations de déplacement sont supprimées. Le format de fichier Windows PE contient des adresses absolues, et le compilateur génère également une [table de réadressage de base que le chargeur peut utiliser pour rechercher toutes les références mémoire relatives et leur décalage, afin qu’elles puissent être mises à jour si le fichier binaire ne se charge pas à son adresse de base préférée. Certaines applications plus anciennes suppriment ces informations dans les builds de production. Par conséquent, ces fichiers binaires ne peuvent pas être rebasés. Cette atténuation empêche le chargement de ces fichiers binaires (au lieu de les autoriser à se charger à leur adresse de base préférée).

Remarque

Imposer la randomisation des images (ASLR obligatoire) n'a pas de mode d'audit.

Protection de pile appliquée par le matériel.

Description

La protection de pile assurée par le matériel offre une protection robuste contre les exploits de type ROP. Il fonctionne en conservant un enregistrement du flux d’exécution prévu d’un programme. Pour prendre en charge l’adoption fluide et la compatibilité des applications, Windows offre cette protection en tant que modèle d’adhésion. Les développeurs peuvent l’activer à leur propre rythme.

Considérations en matière de compatibilité

La protection de la pile imposée par le matériel fonctionne uniquement sur les jeux de composants prenant en charge les piles fantômes matérielles, la technologie Control-flow Enforcement Technology (CET) d'Intel ou les piles fantômes d'AMD.

Si vous exécutez des applications qui reposent sur le .NET Framework, la protection de la pile imposée par le matériel fonctionne avec .NET Framework 7 (sur activation) ou une version ultérieure. Si vous utilisez une version antérieure, vous risquez de rencontrer des blocages ou une utilisation élevée du processeur. Ces problèmes peuvent également se produire en mode audit ou lors du ciblage de modules compatibles uniquement.

Options de configuration

Auditer uniquement : vous pouvez activer cette atténuation en mode audit afin de mesurer l’impact potentiel de la compatibilité sur une application. Les événements d’audit peuvent ensuite être consultés soit dans la Visionneuse d’événements, soit à l’aide de la chasse avancée dans Defender for Endpoint.

Appliquer pour tous les modules au lieu des modules compatibles : vous pouvez activer cette atténuation sur Appliquer pour tous les modules au lieu des modules compatibles.

Filtrage des adresses importées (IAF)

Description

L’atténuation du filtrage des adresses d’importation (IAF) permet d’atténuer le risque qu’un adversaire modifie le flux de contrôle d’une application en modifiant la table d’adresses d’importation (IAT) pour rediriger vers le code arbitraire du choix de l’attaquant quand cette fonction est appelée. Un attaquant pourrait utiliser cette approche pour pirater le contrôle, ou pour intercepter, inspecter et potentiellement bloquer les appels à des API sensibles.

La protection PAGE_GUARD est appliquée aux pages mémoire de toutes les API protégées. Lorsqu’une personne tente d’accéder à cette zone mémoire, une violation STATUS_GUARD_PAGE_VIOLATION est générée. L’atténuation gère cette exception et, si l’instruction d’accès ne passe pas la validation, le processus est terminé.

Cette atténuation protège les API Windows suivantes :

• GetProcAddress
• GetProcAddressForCaller
• LoadLibraryA
• LoadLibraryExA
• LoadLibraryW
• LoadLibraryExW
• LdrGetProcedureAddress
• LdrGetProcedureAddressEx
• LdrGetProcedureAddressForCaller
• LdrLoadDll
• VirtualProtect
• VirtualProtectEx
• VirtualAlloc
• VirtualAllocEx
• NtAllocateVirtualMemory
• NtProtectVirtualMemory
• CreateProcessA
• CreateProcessW
• WinExec
• CreateProcessAsUserA
• CreateProcessAsUserW
• GetModuleHandleA
• GetModuleHandleW
• RtlDecodePointer
• DecodePointer

Considérations en matière de compatibilité

Les applications légitimes qui effectuent une interception d’API peuvent être détectées par cette atténuation et provoquer le blocage de certaines applications. Les logiciels de sécurité et les shims de compatibilité des applications en sont des exemples.

Options de configuration

Audit uniquement : vous pouvez activer cette atténuation en mode audit afin de mesurer l’impact potentiel de la compatibilité sur une application. Les événements d’audit peuvent ensuite être affichés dans l’observateur d’événements ou à l’aide du repérage avancé dans Microsoft Defender pour point de terminaison.

Randomiser les allocations mémoire (ASLR de bas en haut)

Description

La randomisation des allocations mémoire (ASLR ascendant) ajoute de l’entropie aux relocalisations, ce qui rend leur emplacement aléatoire et donc moins prévisible. Cette atténuation exige que l’ASLR obligatoire prenne effet.

La taille de l'espace d'adressage 32 bits impose des contraintes pratiques sur l'entropie qui peut être ajoutée. Par conséquent, les applications 64 bits rendent plus difficile pour un attaquant de deviner un emplacement dans la mémoire.

Considérations en matière de compatibilité

La plupart des applications qui fonctionnent avec l'ASLR obligatoire (rebasement) fonctionnent également avec l'ASLR ascendant. Certaines applications peuvent avoir des problèmes de troncation de pointeur s’ils enregistrent des pointeurs locaux dans des variables 32 bits. Ces applications s’attendent à une adresse de base inférieure à 4 Go, de sorte qu’elles ne fonctionnent pas avec l’option d’entropie élevée. Vous pouvez désactiver l’entropie élevée si nécessaire.

Options de configuration

N’utilisez pas l’entropie élevée – Cette option désactive l’utilisation d’ASLR à entropie élevée, qui ajoute 24 bits d’entropie (1 To de variance) à l’allocation inférieure pour les applications 64 bits.

Remarque

Allocations de mémoire aléatoires (randomisation du format d'espace d'adresse de bas en haut) n'ont pas de mode d'audit.

Simuler l’exécution (SimExec)

Description

La simulation de l’exécution (SimExec) est une mesure d’atténuation pour les applications 32 bits uniquement. Cela permet de vérifier que les appels aux API sensibles retournent aux fonctions appelantes légitimes. Pour ce faire, il intercepte les appels à des API sensibles, puis simule l'exécution de ces API en parcourant les instructions codées en langage d'assemblage à la recherche de l'instruction RET, qui doit retourner à l'appelant. Il inspecte ensuite cette fonction et remonte dans la mémoire pour trouver l'instruction CALL précédente afin de déterminer si la fonction et l'instruction CALL correspondent, et si la RET n'a pas été interceptée.

Les API interceptées par cette atténuation sont les suivantes :

• LoadLibraryA
• LoadLibraryW
• LoadLibraryExA
• LoadLibraryExW
• LdrLoadDll
• VirtualAlloc
• VirtualAllocEx
• NtAllocateVirtualMemory
• VirtualProtect
• VirtualProtectEx
• NtProtectVirtualMemory
• HeapCreate
• RtlCreateHeap
• CreateProcessA
• CreateProcessW
• CreateProcessInternalA
• CreateProcessInternalW
• NtCreateUserProcess
• NtCreateProcess
• NtCreateProcessEx
• CreateRemoteThread
• CreateRemoteThreadEx
• NtCreateThreadEx
• WriteProcessMemory
• NtWriteVirtualMemory
• WinExec
• CreateFileMappingA
• CreateFileMappingW
• CreateFileMappingNumaW
• NtCreateSection
• MapViewOfFile
• MapViewOfFileEx
• MapViewOfFileFromApp
• LdrGetProcedureAddressForCaller

Si un gadget ROP est détecté, le processus est interrompu.

Considérations en matière de compatibilité

Les applications qui effectuent l’interception d’API, en particulier les logiciels de sécurité, peuvent entraîner des problèmes de compatibilité avec cette atténuation.

Cette atténuation n’est pas compatible avec l’atténuation arbitraire de Code Guard.

Options de configuration

Audit uniquement : vous pouvez activer cette atténuation en mode audit afin de mesurer l’impact potentiel de la compatibilité sur une application. Les événements d’audit peuvent ensuite être affichés dans l’observateur d’événements ou à l’aide du repérage avancé dans Microsoft Defender pour point de terminaison.

Valider l’invocation de l’API (CallerCheck)

Description

Validate API invocation (CallerCheck) est une mesure d'atténuation pour les techniques de programmation orientée retour (ROP) qui valide que les API sensibles ont été appelées par un appelant valide. Cette atténuation inspecte l’adresse de retour passée, puis désassemble de façon heuristique vers l’arrière pour rechercher un appel au-dessus de l’adresse de retour afin de déterminer si la cible d’appel correspond au paramètre passé dans la fonction.

Les API interceptées par cette atténuation sont les suivantes :

• LoadLibraryA
• LoadLibraryW
• LoadLibraryExA
• LoadLibraryExW
• LdrLoadDll
• VirtualAlloc
• VirtualAllocEx
• NtAllocateVirtualMemory
• VirtualProtect
• VirtualProtectEx
• NtProtectVirtualMemory
• HeapCreate
• RtlCreateHeap
• CreateProcessA
• CreateProcessW
• CreateProcessInternalA
• CreateProcessInternalW
• NtCreateUserProcess
• NtCreateProcess
• NtCreateProcessEx
• CreateRemoteThread
• CreateRemoteThreadEx
• NtCreateThreadEx
• WriteProcessMemory
• NtWriteVirtualMemory
• WinExec
• CreateFileMappingA
• CreateFileMappingW
• CreateFileMappingNumaW
• NtCreateSection
• MapViewOfFile
• MapViewOfFileEx
• MapViewOfFileFromApp
• LdrGetProcedureAddressForCaller

Si un gadget ROP est détecté, le processus est interrompu.

Considérations en matière de compatibilité

Les applications qui effectuent l’interception d’API, en particulier les logiciels de sécurité, peuvent entraîner des problèmes de compatibilité avec cette atténuation.

Cette atténuation n’est pas compatible avec l’atténuation arbitraire de Code Guard.

Options de configuration

Audit uniquement : vous pouvez activer cette atténuation en mode audit afin de mesurer l’impact potentiel de la compatibilité sur une application. Les événements d’audit peuvent ensuite être affichés dans l’observateur d’événements ou à l’aide du repérage avancé dans Microsoft Defender pour point de terminaison.

Valider les chaînes d’exception (SEHOP)

Description

La validation des chaînes d'exceptions (SEHOP) constitue une mesure d'atténuation contre la technique d'exploitation par écrasement du gestionnaire d'exceptions structurées (SEH). La gestion structurée des exceptions est le processus par lequel une application peut demander à gérer une exception particulière. Les gestionnaires d’exceptions sont chaînés, de sorte que si un gestionnaire d’exceptions choisit de ne pas gérer une exception particulière, il peut être transmis au gestionnaire d’exceptions suivant dans la chaîne jusqu’à ce qu’il décide de le gérer. Étant donné que la liste du gestionnaire est dynamique, elle est stockée sur la pile. Un attaquant peut utiliser une vulnérabilité de dépassement de capacité de la pile pour remplacer ensuite le gestionnaire d'exceptions par un pointeur vers le code du choix de l'attaquant.

Cette atténuation s’appuie sur la conception de SEH, où chaque entrée SEH contient à la fois un pointeur vers le gestionnaire d’exceptions et un pointeur vers le gestionnaire suivant dans la chaîne d’exceptions. Cette atténuation est appelée par le distributeur d'exceptions, qui valide la chaîne SEH lorsqu'une exception est appelée. Il vérifie que :

• Tous les enregistrements de la chaîne d'exceptions se trouvent à l'intérieur des limites de la pile
• Tous les enregistrements d’exception sont alignés
• Aucun pointeur de gestionnaire d’exceptions ne pointe vers la pile
• Il n’existe aucun pointeur vers l’arrière
• La chaîne d’exceptions se termine à un gestionnaire d’exceptions final connu

Si ces validations échouent, la gestion des exceptions est abandonnée et l’exception ne sera pas gérée.

Considérations en matière de compatibilité

Les problèmes de compatibilité avec SEHOP sont relativement rares. Il est rare qu’une application dépende du fait que la chaîne d’exceptions soit altérée. Toutefois, certaines applications sont affectées par de légères variations de synchronisation, qui peuvent se manifester par une situation de concurrence révélant un bogue latent lié au multithreading dans l’application.

Options de configuration

Remarque

La validation des chaînes d’exception (SEHOP) n’a pas de mode d’audit.

Valider l’utilisation de la poignée

Description

Valider l’utilisation d’un identificateur est une mesure d’atténuation qui aide à protéger contre l’utilisation, par un attaquant, d’un identificateur existant pour accéder à un objet protégé. Un descripteur est une référence à un objet protégé. Si le code de l’application utilise un descripteur non valide, cela pourrait indiquer qu’un adversaire tente d’utiliser un descripteur qu’il a précédemment consigné, mais dont le comptage de références de l’application n’aurait pas connaissance. Si l’application tente d’utiliser un objet non valide, au lieu de simplement retourner null, l’application lève une exception (STATUS_INVALID_HANDLE).

Cette atténuation est automatiquement appliquée aux applications du Windows Store.

Considérations en matière de compatibilité

Les applications qui ne suivaient pas avec précision les références de gestion et qui n’encapsulaient pas ces opérations dans des gestionnaires d’exceptions seront potentiellement affectées par cette atténuation.

Options de configuration

Remarque

La validation de l’utilisation de la poignée n’a pas de mode d’audit.

Valider l'intégrité du tas

Description

L'atténuation Valider l'intégrité du tas augmente le niveau de protection des atténuations du tas dans Windows, en provoquant la fin de l'application si une corruption du tas est détectée. Les atténuations sont les suivantes :

• Empêcher qu'un descripteur HEAP soit libéré
• Exécution d'une autre validation sur les en-têtes de blocs étendus pour les allocations de tas.
• Vérification que les allocations de tas ne sont pas déjà marquées comme étant en cours d'utilisation
• Ajout de pages de garde aux allocations volumineuses, aux segments de tas et aux sous-segments dépassant une taille minimale

Considérations en matière de compatibilité

Cette atténuation est déjà appliquée par défaut pour les applications 64 bits et pour les applications 32 bits ciblant Windows Vista ou version ultérieure. Les applications héritées de Windows XP ou d’une version antérieure sont les plus à risque, bien que les problèmes de compatibilité soient rares.

Options de configuration

Remarque

Valider l'intégrité du tas ne dispose pas de mode d'audit.

Vérification de l’intégrité des dépendances d’image

Description

L'atténuation validation des dépendances d'image aide à se protéger contre les attaques qui tentent de substituer du code aux DLL liées statiquement par des binaires Windows. La technique de dépôt de DLL exploite abusivement le mécanisme de recherche du chargeur afin d'injecter du code malveillant, qui peut ensuite être exécuté avec des privilèges élevés. Lorsque le chargeur charge un fichier binaire signé Windows, puis charge toutes les dll dont dépend le fichier binaire, ces fichiers binaires sont vérifiés pour s’assurer qu’ils sont également signés numériquement en tant que binaire Windows. En cas d'échec à la vérification de la signature, la DLL ne se charge pas, lève une exception et renvoie un statut STATUS_INVALID_IMAGE_HASH.

Considérations en matière de compatibilité

Les problèmes de compatibilité sont rares. Les applications qui dépendent du remplacement des binaires Windows par des versions locales privées sont touchées, et il existe également un faible risque de révéler des bogues temporels subtils dans les applications multithread.

Options de configuration

Audit uniquement : vous pouvez activer cette atténuation en mode audit afin de mesurer l’impact potentiel de la compatibilité sur une application. Les événements d’audit peuvent ensuite être affichés dans l’observateur d’événements ou à l’aide du repérage avancé dans Microsoft Defender pour point de terminaison.

Valider l’intégrité de la pile (StackPivot)

Description

La mesure d'atténuation valider l'intégrité de la pile (StackPivot) aide à se protéger contre l'attaque de type Stack Pivot, une attaque ROP dans laquelle un attaquant crée une pile factice dans la mémoire du tas, puis amène l'application à revenir sur cette pile factice afin d'en contrôler le flux d'exécution.

Cette atténuation intercepte de nombreuses API Windows et inspecte la valeur du pointeur de pile. Si l’adresse du pointeur de pile ne se situe pas entre le bas et le haut de la pile, un événement est enregistré et, s’il n’est pas en mode audit, le processus est arrêté.

Les API interceptées par cette atténuation sont les suivantes :

• LoadLibraryA
• LoadLibraryW
• LoadLibraryExA
• LoadLibraryExW
• LdrLoadDll
• VirtualAlloc
• VirtualAllocEx
• NtAllocateVirtualMemory
• VirtualProtect
• VirtualProtectEx
• NtProtectVirtualMemory
• HeapCreate
• RtlCreateHeap
• CreateProcessA
• CreateProcessW
• CreateProcessInternalA
• CreateProcessInternalW
• NtCreateUserProcess
• NtCreateProcess
• NtCreateProcessEx
• CreateRemoteThread
• CreateRemoteThreadEx
• NtCreateThreadEx
• WriteProcessMemory
• NtWriteVirtualMemory
• WinExec
• CreateFileMappingA
• CreateFileMappingW
• CreateFileMappingNumaW
• NtCreateSection
• MapViewOfFile
• MapViewOfFileEx
• MapViewOfFileFromApp
• LdrGetProcedureAddressForCaller

Considérations en matière de compatibilité

Les applications qui utilisent de fausses piles sont affectées, et il existe également un faible risque de révéler des bogues subtils liés au timing dans les applications multithreads. Les applications qui effectuent l’interception d’API, en particulier les logiciels de sécurité, peuvent entraîner des problèmes de compatibilité avec cette atténuation.

Cette atténuation n’est pas compatible avec l’atténuation arbitraire de Code Guard.

Options de configuration

Audit uniquement : vous pouvez activer cette atténuation en mode audit afin de mesurer l’impact potentiel de la compatibilité sur une application. Les événements d’audit peuvent ensuite être affichés dans l’observateur d’événements ou à l’aide du repérage avancé dans Microsoft Defender pour point de terminaison.