Comprendre Windows Defender règles de stratégie de contrôle d’application (WDAC) et règles de fichier

Remarque

Certaines fonctionnalités de Windows Defender Contrôle d’application ne sont disponibles que sur des versions spécifiques de Windows. En savoir plus sur la disponibilité des fonctionnalités WDAC.

Windows Defender Contrôle d’application (WDAC) peut contrôler ce qui s’exécute sur vos appareils Windows en définissant des stratégies qui spécifient si un pilote ou une application est approuvé. Une stratégie inclut des règles de stratégie qui contrôlent des options telles que le mode d’audit et des règles de fichier (ou des niveaux de règle de fichier) qui spécifient comment identifier les applications approuvées par votre organization.

Règles des stratégies Windows Defender Application Control

Pour modifier les options de règle de stratégie d’un xml de stratégie WDAC existant, utilisez l’Assistant Stratégie WDAC ou l’applet de commande PowerShell Set-RuleOption .

Vous pouvez définir plusieurs options de règle au sein d’une stratégie WDAC. Le tableau 1 décrit chaque option de règle et indique si des stratégies supplémentaires peuvent les définir. Certaines options de règle sont réservées pour un travail futur ou ne sont pas prises en charge.

Remarque

Nous vous recommandons d’utiliser initialement Enabled :Audit Mode , car il vous permet de tester les nouvelles stratégies WDAC avant de les appliquer. Avec le mode audit, les applications s’exécutent normalement, mais WDAC journalise les événements chaque fois qu’un fichier s’exécute qui n’est pas autorisé par la stratégie. Pour autoriser ces fichiers, vous pouvez capturer les informations de stratégie à partir du journal des événements, puis fusionner ces informations dans la stratégie existante. Lorsque le mode Enabled :Audit est supprimé, la stratégie s’exécute en mode appliqué.

Certaines applications peuvent se comporter différemment même lorsque votre stratégie est en mode audit. Lorsqu’une option peut modifier les comportements en mode audit, cela est indiqué dans le tableau 1. Vous devez toujours tester soigneusement vos applications lors du déploiement de mises à jour significatives de vos stratégies WDAC.

Tableau 1. Stratégie Windows Defender Application Control - options de règle de stratégie

Option de règle Description Option supplémentaire valide
0 - Activé:UMCI Les stratégies WDAC limitent les fichiers binaires en mode noyau et en mode utilisateur. Par défaut, seuls les fichiers binaires en mode noyau sont limités. L’activation de cette option de règle permet de valider les scripts et fichiers exécutables du mode utilisateur. Non
1 - Activé:Protection du menu de démarrage Cette option n’est actuellement pas prise en charge. Non
2 - Requis:WHQL Par défaut, les pilotes de noyau qui ne sont pas signés WHQL (Windows Hardware Quality Labs) sont autorisés à s’exécuter. L’activation de cette règle nécessite que chaque pilote soit signé WHQL et supprime la prise en charge des pilotes hérités. Les pilotes de noyau créés pour Windows 10 doivent être certifiés WHQL. Non
3 - Activé:Mode audit (valeur par défaut) Demande à WDAC de journaliser les informations sur les applications, les fichiers binaires et les scripts qui auraient été bloqués si la stratégie avait été appliquée. Vous pouvez utiliser cette option pour identifier l’impact potentiel de votre stratégie WDAC et utiliser les événements d’audit pour affiner la stratégie avant son application. Pour appliquer une stratégie WDAC, supprimez cette option. Non
4 - Désactivé:Signature de la version d’évaluation Si cette option est activée, les fichiers binaires des builds Windows Insider ne sont pas approuvés. Cette option est utile pour les organisations qui souhaitent uniquement exécuter des fichiers binaires publiés, et non pas préversion des builds Windows. Non
5 - Activé:Hériter la stratégie par défaut Cette option est réservée à une utilisation ultérieure et n’a actuellement aucun effet. Oui
6 - Activé:Stratégie d’intégrité système non signée (par défaut) Permet à la stratégie de rester non signée. Lorsque cette option est supprimée, la stratégie doit être signée et toutes les stratégies supplémentaires doivent également être signées. Les certificats approuvés pour les futures mises à jour de stratégie doivent être identifiés dans la section UpdatePolicySigners. Les certificats approuvés pour les stratégies supplémentaires doivent être identifiés dans la section SupplementalPolicySigners. Non
7 - Autorisé:Stratégie de débogage augmentée Cette option n’est actuellement pas prise en charge. Oui
8 - Requis:Signataires de validation étendue Cette option n’est actuellement pas prise en charge. Non
9 - Activé:Menu des options de démarrage avancées Le menu d’options préalables au démarrage F8 est désactivé par défaut pour toutes les stratégies WDAC. Si vous définissez cette option de règle, le menu F8 s’affiche pour les utilisateurs physiquement présents. Non
10 - Activé:Audit au démarrage en cas d’échec Cette option est utilisée lorsque la stratégie WDAC est en mode de mise en conformité. Lorsqu’un pilote critique au démarrage échoue au démarrage, la stratégie WDAC est placée en mode audit afin que Windows se charge. Les administrateurs peuvent valider la cause de l’échec dans le journal des événements CodeIntegrity. Non
11 - Désactivé:Application de script Cette option désactive les options d’application de script, couvrant PowerShell, l’hôte de script Windows (wscript.exe), l’hôte de script basé sur la console Windows (cscript.exe), les fichiers HTA exécutés dans Microsoft HTML Application Host (mshta.exe) et MSXML. Certains hôtes de script peuvent se comporter différemment même lorsque votre stratégie est en mode audit. Pour plus d’informations sur l’application des scripts, consultez Application de script avec WDAC.
REMARQUE : cette option n’est pas prise en charge sur Windows Server 2016 ou Windows 10 1607 LTSB et ne doit pas être utilisée sur ces systèmes d’exploitation.		 Non
12 - Obligatoire:Appliquer les applications du Store Si cette option de règle est activée, les stratégies WDAC s’appliquent également aux applications Windows universelles. Non
13 - Activé:Programme d’installation géré Utilisez cette option pour autoriser automatiquement les applications installées par un programme d’installation géré. Pour plus d’informations, consultez Autoriser les applications déployées avec un programme d’installation managé WDAC. Oui
14 - Activé:Autorisation de Intelligent Security Graph Utilisez cette option pour autoriser automatiquement les applications dont la réputation est « bonne » telle que définie par l’Intelligent Security Graph (ISG) de Microsoft. Oui
15 - Activé:Invalider les AE au redémarrage Lorsque l’option Intelligent Security Graph (14) est utilisée, WDAC définit un attribut de fichier étendu qui indique que le fichier a été autorisé à s’exécuter. Cette option permet à WDAC de revalider régulièrement la réputation des fichiers précédemment autorisés par l’ISG. Non
16 - Activé:Mettre à jour la stratégie Aucun redémarrage Utilisez cette option pour autoriser les futures mises à jour de stratégie WDAC à appliquer sans exiger de redémarrage du système.
REMARQUE : cette option est uniquement prise en charge sur Windows 10, version 1709 et ultérieure, ou Windows Server 2019 et versions ultérieures.		 Non
17 Activé :Autoriser les stratégies supplémentaires Utilisez cette option sur une stratégie de base pour permettre aux stratégies supplémentaires de la développer.
REMARQUE : Cette option est uniquement prise en charge sur Windows 10, version 1903 et ultérieure, ou Windows Server 2022 et versions ultérieures.		 Non
18 Désactivé :Protection des règles FilePath runtime Cette option désactive le runtime par défaut case activée qui autorise uniquement les règles FilePath pour les chemins d’accès accessibles en écriture uniquement par un administrateur.
REMARQUE : Cette option est uniquement prise en charge sur Windows 10, version 1903 et ultérieure, ou Windows Server 2022 et versions ultérieures.		 Oui
19 Activé :Sécurité du code dynamique Active l’application de stratégie pour les applications .NET et les bibliothèques chargées dynamiquement.
REMARQUE : cette option n’est prise en charge que sur Windows 10, version 1803 et ultérieure, ou Windows Server 2019 et versions ultérieures.
REMARQUE : cette option est toujours appliquée si une stratégie UMCI WDAC l’active. Il n’existe aucun mode d’audit pour le renforcement de la sécurité du code dynamique .NET.		 Non
20 Activé :Révoqué expiré comme non signé Utilisez cette option pour traiter les fichiers binaires signés avec des certificats révoqués ou les certificats arrivés à expiration avec la référence EKU de signature à durée de vie sur la signature, en tant que « fichiers binaires non signés » pour les processus/composants en mode utilisateur, dans les scénarios de signature d’entreprise. Non
Activé :Approbation de code dynamique en mode développeur Utilisez cette option pour approuver les applications UWP qui sont déboguées dans Visual Studio ou déployées via le portail des appareils lorsque le mode développeur est activé sur le système. Non

Niveaux de règle de fichier de Windows Defender Application Control

Les niveaux de règle de fichier permettent aux administrateurs de spécifier le niveau auquel ils souhaitent approuver leurs applications. Ce niveau de confiance peut être aussi granulaire que le hachage de chaque binaire, ou aussi général qu’un certificat d’autorité de certification. Vous spécifiez des niveaux de règle de fichier lors de l’utilisation de l’Assistant WDAC ou des applets de commande WDAC PowerShell pour créer et modifier des stratégies.

Chaque niveau de règle de fichier présente des avantages et des inconvénients. Utilisez le tableau 2 pour sélectionner le niveau de protection approprié pour vos ressources d’administration disponibles et le scénario de déploiement WDAC.

Remarque

Les règles basées sur les signataires WDAC fonctionnent uniquement avec le chiffrement RSA. Les algorithmes ECC, tels que ECDSA, ne sont pas pris en charge. Si vous essayez d’autoriser des fichiers par signature basées sur des signatures ECC, vous verrez VerificationError = 23 sur les événements d’informations de signature 3089 correspondants. Les fichiers peuvent être autorisés à la place par des règles de hachage ou d’attribut de fichier, ou à l’aide d’autres règles de signataire si le fichier est également signé avec des signatures à l’aide de RSA.

Tableau 2. Stratégie Windows Defender Application Control - niveaux de règle de fichier

Niveau de règle Description
Hash Spécifie des valeurs de hachage d’image Authenticode/PE individuelles pour chaque binaire découvert. Ce niveau est le niveau le plus spécifique et nécessite plus d’efforts pour maintenir les valeurs de hachage des versions de produit actuelles. Chaque fois qu’un fichier binaire est mis à jour, la valeur de hachage change, ce qui nécessite la mise à jour de la stratégie.
FileName Spécifie le nom de fichier d’origine pour chaque fichier binaire. Bien que les valeurs de hachage d’une application soient modifiées lors de la mise à jour, les noms de fichiers ne le sont généralement pas. Ce niveau offre une sécurité moins spécifique que le niveau de hachage, mais il ne nécessite généralement pas de mise à jour de stratégie lorsqu’un fichier binaire est modifié. Par défaut, ce niveau utilise l’attribut OriginalFileName de l’en-tête de ressource du fichier. Utilisez -SpecificFileNameLevel pour choisir un autre attribut, tel que ProductName.
FilePath À compter de Windows 10 version 1903, ce niveau permet aux fichiers binaires de s’exécuter à partir d’emplacements de chemin d’accès de fichier spécifiques. Les règles FilePath s’appliquent uniquement aux fichiers binaires en mode utilisateur et ne peuvent pas être utilisées pour autoriser les pilotes en mode noyau. Vous trouverez plus d’informations sur les règles de niveau FilePath plus loin dans cet article.
SignedVersion Ce niveau combine la règle d’éditeur avec un numéro de version. Il permet à tout ce qui est exécuté à partir du serveur de publication spécifié avec une version au-dessus ou au-dessus du numéro de version spécifié.
Éditeur Ce niveau combine le niveau PcaCertificate (généralement un certificat sous la racine) et le nom commun (CN) du certificat feuille. Vous pouvez utiliser ce niveau de règle pour approuver un certificat émis par une autorité de certification particulière et émis à une société spécifique que vous approuvez (comme Intel, pour les pilotes de périphérique).
FilePublisher Ce niveau combine l’attribut « FileName » du fichier signé, plus « Publisher » (certificat PCA avec cn de feuille), ainsi qu’un numéro de version minimal. Cette option permet d’approuver des fichiers spécifiques de l’éditeur spécifié, dont la version est égale ou supérieure au numéro de version spécifié. Par défaut, ce niveau utilise l’attribut OriginalFileName de l’en-tête de ressource du fichier. Utilisez -SpecificFileNameLevel pour choisir un autre attribut, tel que ProductName.
LeafCertificate Ajoute les signataires approuvés au niveau du certificat de signature individuel. L’avantage de l’utilisation de ce niveau par rapport au niveau de hachage individuel est que les nouvelles versions du produit ont des valeurs de hachage différentes, mais généralement le même certificat de signature. Lorsque ce niveau est utilisé, aucune mise à jour de stratégie n’est nécessaire pour exécuter la nouvelle version de l’application. Toutefois, les certificats feuille ont généralement des périodes de validité plus courtes que les autres niveaux de certificat. La stratégie WDAC doit donc être mise à jour chaque fois que ces certificats changent.
PcaCertificate Ajoute le certificat disponible le plus élevé à la chaîne de certificats fournie aux signataires. Ce niveau est généralement un certificat sous la racine, car l’analyse ne résout pas la chaîne de certificats complète via les magasins racines locaux ou avec un case activée en ligne.
RootCertificate Non pris en charge.
WHQL Approuve uniquement les fichiers binaires qui ont été soumis à Microsoft et signés par le Laboratoire de qualification matérielle Windows (WHQL). Ce niveau concerne principalement les fichiers binaires du noyau.
WHQLPublisher Ce niveau combine le niveau WHQL et le cn sur le certificat feuille, et concerne principalement les fichiers binaires du noyau.
WHQLFilePublisher Ce niveau combine l’attribut « FileName » du fichier signé, ainsi que « WHQLPublisher », ainsi qu’un numéro de version minimal. Ce niveau concerne principalement les fichiers binaires du noyau. Par défaut, ce niveau utilise l’attribut OriginalFileName de l’en-tête de ressource du fichier. Utilisez -SpecificFileNameLevel pour choisir un autre attribut, tel que ProductName.

Remarque

Lorsque vous créez des stratégies WDAC avec New-CIPolicy, vous pouvez spécifier un niveau de règle de fichier principal, en incluant le paramètre -Level . Pour les fichiers binaires découverts qui ne peuvent pas être approuvés en fonction des critères de règle de fichier principaux, utilisez le paramètre -Fallback. Par exemple, si le niveau de règle de fichier principal est PCACertificate, mais que vous souhaitez également approuver les applications non signées, l’utilisation du niveau de règle de hachage comme secours ajoute les valeurs de hachage des fichiers binaires qui n’ont pas de certificat de signature.

Remarque

  • WDAC prend uniquement en charge les règles de signataire pour les clés de signature de certificat RSA avec un maximum de 4 096 bits.
  • Le code utilise cn pour les champs CertSubject et CertIssuer dans la stratégie. Vous pouvez utiliser le certutil de boîte de réception pour examiner le format sous-jacent afin de vous assurer que UTF-8 n’est pas utilisé pour le cn. Par exemple, vous pouvez utiliser une chaîne imprimable, IA5 ou BMP.

Remarque

Le cas échéant, les numéros de version minimum et maximal dans une règle de fichier sont référencés respectivement en tant que MinimumFileVersion et MaximumFileVersion dans le code XML de stratégie.

  • MinimumFileVersion et MaximumFileVersion spécifiés : pour les règles Allow, les fichiers dont la version est supérieure ou égale à MinimumFileVersion et inférieure ou égale à MaximumFileVersion sont autorisés. Pour les règles de refus, les fichiers dont la version est supérieure ou égale à MinimumFileVersion et inférieure ou égale à MaximumFileVersion sont refusés.
  • MinimumFileVersion spécifié sans MaximumFileVersion : pour les règles d’autorisation, les fichiers dont la version est supérieure ou égale à la version spécifiée sont autorisés à s’exécuter. Pour les règles de refus, les fichiers dont la version est inférieure ou égale à la version spécifiée sont bloqués.
  • MaximumFileVersion spécifié sans MinimumFileVersion : pour les règles d’autorisation, les fichiers dont la version est inférieure ou égale à la version spécifiée sont autorisés à s’exécuter. Pour les règles de refus, les fichiers dont la version est supérieure ou égale à la version spécifiée sont bloqués.

Exemple de niveaux de règle de fichier en cours d’utilisation

Par exemple, prenons l’exemple d’un professionnel de l’informatique dans un service qui exécute de nombreux serveurs. Ils veulent uniquement exécuter des logiciels signés par les entreprises qui fournissent leur matériel, système d’exploitation, antivirus et autres logiciels importants. Ils savent que leurs serveurs exécutent également une application écrite en interne qui n’est pas signée, mais est rarement mise à jour. Ils souhaitent autoriser l’exécution de cette application.

Pour créer la stratégie WDAC, ils créent un serveur de référence sur leur matériel standard, et installent tous les logiciels que leurs serveurs exécutent habituellement. Ensuite, ils exécutent New CIPolicy avec -Level Publisher (pour autoriser les logiciels de leurs fournisseurs de logiciels, les « éditeurs ») et -Fallback Hash (pour autoriser l’application interne, non signée). Ils déploient la stratégie en mode audit pour déterminer l’impact potentiel de l’application de la stratégie. À l’aide des données d’audit, ils mettent à jour leurs stratégies WDAC pour inclure tout autre logiciel qu’ils souhaitent exécuter. Ensuite, ils activent la stratégie WDAC en mode imposé pour leurs serveurs.

Dans le cadre des opérations normales, ils finiront par installer des mises à jour logicielles, ou peut-être ajouter des logiciels des mêmes fournisseurs de logiciels. Étant donné que le « serveur de publication » reste le même sur ces mises à jour et logiciels, il n’a pas besoin de mettre à jour sa stratégie WDAC. Si l’application interne non signée est mise à jour, elle doit également mettre à jour la stratégie WDAC pour autoriser la nouvelle version.

Ordre de priorité de la règle de fichier

WDAC a une logique de conflit de règle de fichier intégrée qui se traduit par ordre de priorité. Il traite d’abord toutes les règles de refus explicites qu’il trouve. Ensuite, il traite toutes les règles d’autorisation explicites. S’il n’existe aucune règle de refus ou d’autorisation, WDAC recherche une revendication Programme d’installation managée si elle est autorisée par la stratégie. Enfin, WDAC revient à l’ISG si la stratégie l’autorise.

Remarque

Pour faciliter la raison de vos stratégies WDAC, nous vous recommandons de conserver des stratégies ALLOW et DENY distinctes sur les versions de Windows qui prennent en charge plusieurs stratégies WDAC.

Utiliser -SpecificFileNameLevel avec les règles de niveau FileName, FilePublisher ou WHQLFilePublisher

Par défaut, les niveaux de règle FileName, FilePublisher et WHQLFilePublisher utilisent l’attribut OriginalFileName de l’en-tête de ressource du fichier. Vous pouvez utiliser un autre attribut d’en-tête de ressource pour vos règles en définissant -SpecificFileNameLevel. Par instance, un développeur de logiciels peut utiliser le même ProductName pour tous les fichiers binaires qui font partie d’une application. À l’aide de -SpecificFileNameLevel, vous pouvez créer une seule règle pour couvrir tous les fichiers binaires de votre stratégie plutôt que des règles individuelles pour chaque fichier.

Le tableau 3 décrit les options d’attribut d’en-tête de ressource disponibles que vous pouvez définir avec -SpecificFileNameLevel.

Tableau 3. Options -SpecificFileNameLevel

Valeur SpecificFileNameLevel Description
FileDescription Spécifie la description du fichier fournie par le développeur du fichier binaire.
InternalName Spécifie le nom interne du fichier binaire.
OriginalFileName Spécifie le nom de fichier d’origine, ou le nom avec lequel le fichier a été créé pour la première fois, du fichier binaire.
PackageFamilyName Spécifie le nom de la famille de packages du fichier binaire. Le nom de la famille de packages se compose de deux parties : le nom du fichier et l’ID de l’éditeur.
Productname Spécifie le nom du produit avec lequel le fichier binaire est fourni.
Filepath Spécifie le chemin d’accès du fichier binaire.

Plus d’informations sur les règles de chemin de fichier

Les règles filepath ne fournissent pas les mêmes garanties de sécurité que les règles de signataire explicites, car elles sont basées sur des autorisations d’accès mutables. Les règles filepath sont mieux adaptées aux environnements où la plupart des utilisateurs s’exécutent en tant que standard plutôt qu’en tant qu’administrateur. Les règles de chemin sont mieux adaptées pour autoriser les chemins d’accès que vous prévoyez de rester accessibles en écriture par l’administrateur uniquement. Vous souhaiterez peut-être éviter les règles de chemin d’accès pour les répertoires où les utilisateurs standard peuvent modifier les listes de contrôle d’accès sur le dossier.

Chemins de fichiers accessibles en écriture par l’utilisateur

Par défaut, WDAC effectue une case activée d’écriture utilisateur au moment de l’exécution qui garantit que les autorisations actuelles sur le chemin de fichier spécifié autorisent uniquement l’accès en écriture pour les utilisateurs administrateurs.

Il existe une liste définie de SID que WDAC reconnaît en tant qu’administrateurs. Si un chemin de fichier autorise des autorisations d’écriture pour tout SID ne figurant pas dans cette liste, le chemin d’accès est considéré comme pouvant être écrit par l’utilisateur, même si le SID est associé à un utilisateur administrateur personnalisé. Pour gérer ces cas spéciaux, vous pouvez remplacer les case activée d’administration du runtime de WDAC avec l’option Disabled :Runtime FilePath Rule Protection décrite précédemment.

La liste des SID d’administration connus de WDAC est la suivante :

S-1-3-0 ; S-1-5-18 ; S-1-5-19 ; S-1-5-20 ; S-1-5-32-544 ; S-1-5-32-549 ; S-1-5-32-550 ; S-1-5-32-551 ; S-1-5-32-577 ; S-1-5-32-559 ; S-1-5-32-568 ; S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804-1277922394 ; S-1-15-2-95739096-486727260-2033287795-3853587803-1685597119-444378811-2746676523.

Lorsque des règles de chemin d’accès aux fichiers sont générées à l’aide de New-CIPolicy, une règle de chemin d’accès complet unique est générée pour chaque fichier découvert dans le ou les chemins analysés. Pour créer des règles qui autorisent à la place tous les fichiers sous un chemin d’accès de dossier spécifié, utilisez New-CIPolicyRule pour définir des règles contenant des caractères génériques, à l’aide du commutateur -FilePathRules .

Utilisation de caractères génériques dans les règles de chemin de fichier WDAC

Les caractères génériques suivants peuvent être utilisés dans les règles de chemin de fichier WDAC :

Caractère générique Signification Systèmes d’exploitation pris en charge
* Correspond à zéro ou plusieurs caractères. Windows 11, Windows 10 et Windows Server 2022
? Correspond à un caractère unique. Windows 11 uniquement

Vous pouvez également utiliser les macros suivantes lorsque le volume exact peut varier : %OSDRIVE%, %WINDIR%, %SYSTEM32%. Ces macros peuvent être utilisées en combinaison avec les caractères génériques ci-dessus.

Remarque

Sur Windows 11, vous pouvez utiliser un ou plusieurs caractères génériques n’importe où dans une règle de chemin de fichier.

Sur toutes les autres versions de Windows et Windows Server, un seul caractère générique est autorisé par règle de chemin d’accès et doit être au début ou à la fin d’une règle de chemin d’accès.

Exemples de règles de chemin de fichier avec des caractères génériques

Exemples Description Systèmes d’exploitation pris en charge
C:\windows\*
D :\EnterpriseApps\MyApp\*
%OSDRIVE%\Windows\*		 Les caractères génériques placés à la fin d’un chemin autorisent tous les fichiers du chemin d’accès immédiat et ses sous-répertoires de manière récursive. Windows 11, Windows 10 et Windows Server 2022
*\bar.exe Les caractères génériques placés au début d’un chemin d’accès autorisent le nom de fichier exact spécifié à n’importe quel emplacement. Windows 11, Windows 10 et Windows Server 2022
C :\*\CCMCACHE\*\7z ???? -x64.exe
%OSDRIVE%\*\CCMCACHE\*\7z ???? -x64.exe		 Les caractères génériques utilisés au milieu d’un chemin d’accès autorisent tous les fichiers qui correspondent à ce modèle. Examinez soigneusement toutes les correspondances possibles, en particulier si votre stratégie désactive le case activée accessible en écriture par l’administrateur avec l’option Disabled :Runtime FilePath Rule Protection. Dans cet exemple, ces deux chemins hypothétiques correspondent à :
C:\WINDOWS\CCMCACHE\12345\7zabcd-x64.exe
C:\USERS\WDACUSER\Downloads\Malware\CCMCACHE\Pwned\7zhaha-x64.exe		 Windows 11 uniquement

Sans caractère générique, la règle de chemin de fichier autorise uniquement un fichier spécifique (par exemple C:\foo\bar.exe).

Remarque

Lors de la création de stratégies WDAC avec Configuration Manager, il existe une option permettant de créer des règles pour les fichiers et dossiers spécifiés. Ces règles ne sont pas des règles de chemin de fichier WDAC. Au lieu de cela, Configuration Manager effectue une analyse ponctuelle des fichiers et dossiers spécifiés et génère des règles pour tous les fichiers binaires trouvés à ces emplacements au moment de cette analyse. Les modifications apportées aux fichiers et dossiers spécifiés après cette analyse ne seront pas autorisées, sauf si la stratégie de Configuration Manager est réappliquée.

Plus d’informations sur les hachages

WDAC utilise l’algorithme de hachage d’image Authenticode/PE lors du calcul du hachage d’un fichier. Contrairement au hachage de fichier plat plus connu, le calcul de hachage Authenticode omet la somme de contrôle du fichier, la table de certificats et la table de certificats d’attributs. Par conséquent, le hachage Authenticode d’un fichier ne change pas lorsque les signatures et les horodatages du fichier sont modifiés, ou lorsqu’une signature numérique est supprimée du fichier. Avec l’aide du hachage Authenticode, WDAC offre une sécurité accrue et moins de charge de gestion, de sorte que les clients n’ont pas besoin de réviser les règles de hachage de stratégie lorsque la signature numérique sur le fichier est mise à jour.

Le hachage d’image Authenticode/PE peut être calculé pour les fichiers signés numériquement et non signés.

Pourquoi l’analyse crée-t-elle quatre règles de hachage par fichier XML ?

L’applet de commande PowerShell produit un hachage Sha1 Authenticode, un hachage Sha256, un hachage de page Sha1 et un hachage de page Sha256. Lors de la validation, WDAC sélectionne les hachages qui sont calculés en fonction de la façon dont le fichier est signé et du scénario dans lequel le fichier est utilisé. Par exemple, si le fichier est signé par hachage de page, WDAC valide chaque page du fichier et évite de charger le fichier entier en mémoire pour calculer le hachage sha256 authenticode complet.

Dans les applets de commande, au lieu d’essayer de prédire quel hachage sera utilisé, nous précalculons et utilisons les quatre hachages (sha1/sha2 authenticode et sha1/sha2 de la première page). Cette méthode est également résiliente aux changements dans la façon dont le fichier est signé, car votre stratégie WDAC dispose déjà de plusieurs hachages disponibles pour le fichier.

Pourquoi l’analyse crée-t-elle huit règles de hachage pour certains fichiers ?

Des règles distinctes sont créées pour UMCI et KMCI. Si les applets de commande ne peuvent pas déterminer qu’un fichier s’exécute uniquement en mode utilisateur ou dans le noyau, des règles sont créées pour les deux scénarios de déconnexion, ce qui vous permet de faire preuve de prudence. Si vous savez qu’un fichier particulier se charge uniquement en mode utilisateur ou noyau, vous pouvez supprimer les règles supplémentaires en toute sécurité.

Quand WDAC utilise-t-il la valeur de hachage de fichier plat ?

Il existe de rares cas où le format d’un fichier n’est pas conforme à la spécification Authenticode et WDAC revient donc à utiliser le hachage de fichier plat. Ce comportement peut se produire pour de nombreuses raisons, par exemple si des modifications sont apportées à la version en mémoire du fichier au moment de l’exécution. Dans ce cas, vous verrez que le hachage affiché dans l’événement d’informations de signature 3089 corrélé correspond au hachage de fichier plat de l’événement de bloc 3076/3077. Pour créer des règles pour les fichiers dont le format n’est pas valide, vous pouvez ajouter des règles de hachage à la stratégie pour le hachage de fichier plat à l’aide de l’Assistant WDAC ou en modifiant directement le code XML de stratégie.