Référence de protection contre les codes malveillants exploitant une faille de sécurité
S’applique à :
- Microsoft Defender pour point de terminaison Plan 1
- Microsoft Defender pour point de terminaison Plan 2
- Microsoft Defender XDR
Vous voulez découvrir Microsoft Defender pour point de terminaison ? Inscrivez-vous pour bénéficier d’un essai gratuit.
Exploit Protection fournit des protections avancées pour les applications que les administrateurs d’entreprise et les professionnels de l’informatique peuvent appliquer une fois qu’un développeur a compilé et distribué 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 atténuations d’Exploit Protection sont appliquées par application.
Les mesures d'atténuation sont configurées via une entrée de Registre pour chaque programme pour lequel vous configurez des protections. Ces paramètres sont stockés dans l’entrée de Registre MitigationOptions pour chaque programme (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\*ImageFileName*\MitigationOptions). Elles prennent effet lorsque vous redémarrez le programme et restent effectives jusqu’à ce que vous les modifiiez et redémarrant le programme.
Importante
Les options d’exécution de fichier image vous permettent uniquement de spécifier un nom de fichier ou un chemin d’accès, et non un numéro de version, une architecture ou tout autre élément de différenciation. Veillez à cibler les mesures d'atténuation pour les applications qui ont des noms ou des chemins d'accès uniques, en les appliquant uniquement sur les appareils sur lesquels vous avez testé cette version et cette architecture de l'application.
Si vous configurez des atténuations d’exploit protection à l’aide d’un fichier de configuration XML à l’aide de PowerShell, stratégie de groupe ou GPM, lors du traitement de ce fichier de configuration XML, des paramètres de Registre individuels sont configurés pour vous.
Lorsque la stratégie de distribution du fichier XML n’est plus appliquée, les paramètres déployés par ce fichier de configuration XML ne sont pas automatiquement supprimés. Pour supprimer les paramètres Exploit Protection, exportez la configuration XML à partir d'un appareil Windows 10 ou Windows 11 propre, puis déployez ce nouveau fichier XML. Par ailleurs, Microsoft fournit un fichier XML dans le cadre des lignes de base de la sécurité de Windows pour réinitialiser les paramètres Exploit Protection.
Pour réinitialiser les paramètres exploit protection à l’aide de PowerShell, utilisez la commande suivante :
Set-ProcessMitigation -PolicyFilePath EP-reset.xml
Voici le fichier EP-reset.xml distribué avec les bases de référence de sécurité de Windows :
<?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 sections suivantes détaillent les protections fournies par chaque atténuation Exploit Protection, les considérations de compatibilité pour l'atténuation et les options de configuration disponibles.
Protection du code arbitraire
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é
La protection de code arbitraire empêche l’allocation de mémoire en tant qu’exécutable, ce qui présente un problème de compatibilité avec des approches telles que les compilateurs juste-à-temps (JIT). 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 avoir écrit l’application avec connaissance de cette atténuation et avoir appelé 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 sur la compatibilité d’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 Defender pour point de terminaison.
Bloquer les images de faible intégrité
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 devez 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
Auditer uniquement : vous pouvez activer cette atténuation en mode audit afin de mesurer l’impact potentiel sur la compatibilité d’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
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
Auditer uniquement : vous pouvez activer cette atténuation en mode audit afin de mesurer l’impact potentiel sur la compatibilité d’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
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 n’est pas chargée pour l’analyse et cet 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. Pour plus d’informations sur cette atténuation, consultez le blog Renforcement de Windows 10 grâce aux atténuations des exploits de type vulnérabilité zero-day.
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
Auditer uniquement : vous pouvez activer cette atténuation en mode audit afin de mesurer l’impact potentiel sur la compatibilité d’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
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 tiers, sauf si ce logiciel est distribué par (et signé numériquement par) le Microsoft Store, 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 des 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 ont suivi le processus de certification du magasin par l’application.
Auditer uniquement : vous pouvez activer cette atténuation en mode audit afin de mesurer l’impact potentiel sur la compatibilité d’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)
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 type dépassement de mémoire tampon pour écraser la mémoire contenant un pointeur de fonction, et remplacer ce pointeur de fonction par un pointeur vers un code exécutable de son choix (qui peut également avoir été injecté dans le programme).
Cette atténuation est fournie par l’injection d’une autre vérification au moment 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 une CFG stricte – En mode strict, tous les fichiers binaires chargés dans le processus doivent être compilés pour Flux de contrôle Guard (ou n’avoir aucun code exécutable dans ces derniers, par exemple des DLL de ressource) pour pouvoir être chargés.
Remarque
La protection de 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)
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 ARM-64 ont la protection DEP activée par défaut, et elle ne peut pas être désactivée. Étant donné qu’une application n’a jamais été 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 de configuration désactive 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 généralement considéré pour interagir entre les applications 32 bits et 16 bits, mais il n’y a pas de composants 16 bits dans ATL ici. Au lieu de cela, afin d’optimiser la taille binaire, ATL stocke le code de l’ordinateur en mémoire qui n’est pas aligné sur le mot (créant un fichier binaire plus petit), puis appelle ce code directement. Les composants ATL compilés avec Visual Studio 7.1 ou version antérieure (Visual Studio 2003) n’allouent pas cette mémoire en tant qu’exécutable . L’émulation thunk résout ce problème de compatibilité. Les applications qui ont un modèle d’extension binaire (par exemple, Internet Explorer 11) doivent souvent avoir l’émulation Thunk ATL activée.
Désactiver les points d’extension
Description
Cette atténuation 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.
- EIM héritées – 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 MI, appelés MI, fonctionnent uniquement sur les applications de bureau Windows, et non sur les applications UWP. Cette atténuation empêche également le chargement de cet IME hérité 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 bibliothèque de liens dynamiques est spécifiée et peut être injectée dans le processus. Cette atténuation force la publication du crochet dans le processus d’inscription au lieu d’exécuter in-process 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'impact de la compatibilité est généralement faible, en particulier au niveau d'une application individuelle. La seule considération à prendre en compte est que les utilisateurs utilisent des AUTHENTIFICATION héritées tierces qui ne fonctionnent pas 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
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 à l'aide d'un seul processus est affectée par cette atténuation.
Options de configuration
Auditer uniquement : vous pouvez activer cette atténuation en mode audit afin de mesurer l’impact potentiel sur la compatibilité d’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 le blocage des processus enfants
Description
Cette atténuation 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 des applications enfant pour une raison quelconque, comme la prise en charge d'hyperliens qui lancent un navigateur ou un navigateur externe, ou qui lancent d'autres utilitaires sur l'ordinateur, cette fonctionnalité sera rompue avec l'application de cette atténuation.
Options de configuration
Auditer uniquement : vous pouvez activer cette atténuation en mode audit afin de mesurer l’impact potentiel sur la compatibilité d’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
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. Cette page mémoire se verra appliquer la protection PAGE_GUARD. Lorsqu’une personne tente d’accéder à cette mémoire, elle génère une STATUS_GUARD_PAGE_VIOLATION. 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.dllflash*.ocxjscript*.ocxvbscript.dllvgx.dllmozjs.dllxul.dllacrord32.dllacrofx32.dllacroform.api
En outre, en activant EAF+, cette atténuation ajoute la protection PAGE_GUARD à la page contenant l’en-tête « MZ », les deux premiers octets de l’en-tête DOS dans un fichier PE, qui est un autre aspect du contenu de mémoire connu que shellcode peut rechercher pour identifier les modules susceptibles d’intéresser la mémoire.
Auditer uniquement : vous pouvez activer cette atténuation en mode audit afin de mesurer l’impact potentiel sur la compatibilité d’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 (randomisation du format d’espace d’adresse obligatoire)
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 est mappé dans l’image dans le processus, l’ASLR obligatoire rebasage les DLL et les EXE qui n’ont pas opté pour ASLR. Notez toutefois que ce rebasement n'a pas d'entropie, et peut donc être placé à un emplacement prévisible en mémoire. Pour un emplacement rebasé et aléatoire des binaires, cette atténuation doit être associée àAllocations de mémoire aléatoires (randomisation du format d’espace d’adresse de bas en haut).
Considérations en matière de compatibilité
Cet impact sur la compatibilité d’ASLR est généralement limité aux anciennes applications 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éadressage 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 supprimées – Cette option bloque le chargement des images dont les informations de réadressage ont été 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
Forcer la randomisation des images (randomisation du format d’espace d’adresse obligatoire) n’a pas de mode d’audit.
Protection de pile appliquée par le matériel
Description
La protection de pile appliquée par le matériel offre une protection robuste contre les attaques ROP, car elle conserve un enregistrement du flux d’exécution prévu d’un programme. Pour garantir une adoption fluide de l’écosystème et la compatibilité des applications, Windows offre cette protection en tant que modèle d’acceptation, afin que les développeurs puissent bénéficier de cette protection, à votre rythme.
Considérations en matière de compatibilité
La protection de pile appliquée par le matériel fonctionne uniquement sur les circuits microprogrammés avec prise en charge des piles d’ombres matérielles, de la technologie d’application de flux de contrôle (CET) d’Intel ou des piles d’ombres AMD.
Options de configuration
Auditer uniquement : vous pouvez activer cette atténuation en mode audit afin de mesurer l’impact potentiel sur la compatibilité d’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 Defender pour point de terminaison.
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.
Importer le filtrage d’adresses (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 mémoire, elle génère une STATUS_GUARD_PAGE_VIOLATION. 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 :
GetProcAddressGetProcAddressForCallerLoadLibraryALoadLibraryExALoadLibraryWLoadLibraryExWLdrGetProcedureAddressLdrGetProcedureAddressExLdrGetProcedureAddressForCallerLdrLoadDllVirtualProtectVirtualProtectExVirtualAllocVirtualAllocExNtAllocateVirtualMemoryNtProtectVirtualMemoryCreateProcessACreateProcessWWinExecCreateProcessAsUserACreateProcessAsUserWGetModuleHandleAGetModuleHandleWRtlDecodePointerDecodePointer
Considérations en matière de compatibilité
Les applications légitimes qui effectuent l’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
Auditer uniquement : vous pouvez activer cette atténuation en mode audit afin de mesurer l’impact potentiel sur la compatibilité d’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.
Allocations de mémoire aléatoires (randomisation du format d’espace d’adresse de bas en haut)
Description
Allocations de mémoire aléatoires (randomisation du format d’espace d’adresse de bas en haut) ajoutent une entropie aux réadressages, de sorte que leur emplacement est aléatoire et donc moins prévisible. Cette atténuation nécessite la prise en compte de l’ASLR obligatoire.
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 compatibles avec l'ASLR obligatoire (rebasement) sont également compatibles avec l'autre entropie de l'ASLR ascendant. Certaines applications peuvent rencontrer des problèmes de troncation de pointeur si elles enregistrent des pointeurs locaux dans des variables 32 bits (en attendant une adresse de base inférieure à 4 Go) et sont donc incompatibles avec l’option d’entropie élevée (qui peut être désactivée).
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
Simulez l’exécution (SimExec) est une atténuation pour les applications 32 bits uniquement. Cela permet de vérifier que les appels aux API sensibles retournent aux fonctions d’appelant 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 :
LoadLibraryALoadLibraryWLoadLibraryExALoadLibraryExWLdrLoadDllVirtualAllocVirtualAllocExNtAllocateVirtualMemoryVirtualProtectVirtualProtectExNtProtectVirtualMemoryHeapCreateRtlCreateHeapCreateProcessACreateProcessWCreateProcessInternalACreateProcessInternalWNtCreateUserProcessNtCreateProcessNtCreateProcessExCreateRemoteThreadCreateRemoteThreadExNtCreateThreadExWriteProcessMemoryNtWriteVirtualMemoryWinExecCreateFileMappingACreateFileMappingWCreateFileMappingNumaWNtCreateSectionMapViewOfFileMapViewOfFileExMapViewOfFileFromAppLdrGetProcedureAddressForCaller
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
Auditer uniquement : vous pouvez activer cette atténuation en mode audit afin de mesurer l’impact potentiel sur la compatibilité d’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 :
LoadLibraryALoadLibraryWLoadLibraryExALoadLibraryExWLdrLoadDllVirtualAllocVirtualAllocExNtAllocateVirtualMemoryVirtualProtectVirtualProtectExNtProtectVirtualMemoryHeapCreateRtlCreateHeapCreateProcessACreateProcessWCreateProcessInternalACreateProcessInternalWNtCreateUserProcessNtCreateProcessNtCreateProcessExCreateRemoteThreadCreateRemoteThreadExNtCreateThreadExWriteProcessMemoryNtWriteVirtualMemoryWinExecCreateFileMappingACreateFileMappingWCreateFileMappingNumaWNtCreateSectionMapViewOfFileMapViewOfFileExMapViewOfFileFromAppLdrGetProcedureAddressForCaller
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
Auditer uniquement : vous pouvez activer cette atténuation en mode audit afin de mesurer l’impact potentiel sur la compatibilité d’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’exception (SEHOP) est une atténuation contre la technique d’exploitation de remplacement SEH (Structured Exception Handler). 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 chaîne d’exception se trouvent dans les 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 de l’endommagement de la chaîne d’exceptions. Toutefois, certaines applications sont affectées par les modifications subtiles du minutage, qui peuvent se manifestent sous la forme d’une condition de concurrence qui révèle un bogue multithreading latent 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’une poignée est une atténuation qui permet de se protéger contre un attaquant à l’aide d’une poignée existante pour accéder à un objet protégé. Une poignée est une référence à un objet protégé. Si le code d’application fait référence à une poignée non valide, cela peut indiquer qu’un adversaire tente d’utiliser une poignée qu’il a enregistré précédemment (mais dont le comptage des références d’application ne serait pas pris en compte). 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 segment de mémoire
Description
L'atténuation Valider l’intégrité du segment de mémoire augmente le niveau de protection des atténuations du segment de mémoire dans Windows, en provoquant la fin de l'application si une corruption du segment de mémoire est détectée. Les atténuations sont les suivantes :
- Empêcher la libération d'un handle HEAP
- Exécution d'une autre validation sur les en-têtes de blocs étendus pour les allocations du segment de mémoire.
- 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 à de grandes allocations, segments du segment de mémoire et sous-ensembles au-dessus d’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
Vérifiez que l’intégrité du segment de mémoire n’a pas de mode d’audit.
Valider l’intégrité des dépendances d’image
Description
L’atténuation valider dépendances d’image permet de se protéger contre les attaques qui tentent de remplacer le code par des DLL liées statiquement par des fichiers binaires Windows. La technique de la DLL abuse du mécanisme de recherche du chargeur pour injecter du code malveillant, qui peut être utilisé pour exécuter du code malveillant dans un contexte élevé. 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 de la signature case activée, la dll n’est pas chargée et lève une exception, renvoyant une status de 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 fichiers binaires Windows par des versions privées locales sont affectées, et il existe également un faible risque de révéler des bogues de minutage subtils dans les applications multithread.
Options de configuration
Auditer uniquement : vous pouvez activer cette atténuation en mode audit afin de mesurer l’impact potentiel sur la compatibilité d’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
L’atténuation valider l’intégrité de la pile (StackPivot) permet de se protéger contre l’attaque Stack Pivot, une attaque ROP dans laquelle un attaquant crée une pile factice dans la mémoire du tas, puis insère l’application dans la pile factice qui contrôle 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 :
LoadLibraryALoadLibraryWLoadLibraryExALoadLibraryExWLdrLoadDllVirtualAllocVirtualAllocExNtAllocateVirtualMemoryVirtualProtectVirtualProtectExNtProtectVirtualMemoryHeapCreateRtlCreateHeapCreateProcessACreateProcessWCreateProcessInternalACreateProcessInternalWNtCreateUserProcessNtCreateProcessNtCreateProcessExCreateRemoteThreadCreateRemoteThreadExNtCreateThreadExWriteProcessMemoryNtWriteVirtualMemoryWinExecCreateFileMappingACreateFileMappingWCreateFileMappingNumaWNtCreateSectionMapViewOfFileMapViewOfFileExMapViewOfFileFromAppLdrGetProcedureAddressForCaller
Considérations en matière de compatibilité
Les applications qui utilisent des piles factices sont affectées, et il existe également un petit risque de révéler des bogues de minutage subtils dans les applications multithread. 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
Auditer uniquement : vous pouvez activer cette atténuation en mode audit afin de mesurer l’impact potentiel sur la compatibilité d’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.
Conseil
Voulez-vous en savoir plus ? Engage avec la communauté Microsoft Security dans notre communauté technique : Microsoft Defender pour point de terminaison Tech Community.