Débogage et dépannage du contrôle d’application

Remarque

Certaines fonctionnalités d’App Control for Business sont disponibles uniquement sur des versions spécifiques de Windows. En savoir plus sur la disponibilité des fonctionnalités de contrôle d’application.

Cet article explique comment déboguer et résoudre les échecs d’application et de script lors de l’utilisation d’App Control pour Entreprise.

1 - Collecter les données de diagnostic du contrôle d’application

Avant de déboguer et de résoudre les problèmes de contrôle d’application, vous devez collecter des informations sur un appareil présentant le comportement problématique.

Exécutez les commandes suivantes à partir d’une fenêtre PowerShell élevée pour collecter les informations de diagnostic dont vous pourriez avoir besoin :

  1. Rassemblez les données de diagnostic générales du contrôle d’application et copiez-les dans %userprofile %\AppData\Local\Temp\DiagOutputDir\CiDiag :

    cidiag.exe /stop

    Si CiDiag.exe n’est pas présent dans votre version de Windows, collectez ces informations manuellement :

  2. Enregistrez les informations système de l’appareil dans le dossier CiDiag :

    msinfo32.exe /report $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\SystemInformation.txt

  3. Utilisez CiTool.exe pour inventorier la liste des stratégies de contrôle d’application sur l’appareil. Ignorez cette étape si CiTool.exe n’est pas présent dans votre version de Windows.

    citool.exe -lp -json > $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\CiToolOutput.json

  4. Exportez les données de clé de Registre AppLocker vers le dossier CiDiag :

    reg.exe query HKLM\Software\Policies\Microsoft\Windows\SrpV2 /s > $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerRegistry.txt; reg.exe query HKLM\Software\Policies\Microsoft\Windows\AppidPlugins /s >> $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerRegistry.txt; reg.exe query HKLM\System\CurrentControlSet\Control\Srp\ /s >> $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerRegistry.txt

    Remarque

    Vous pouvez voir une erreur indiquant que le système n’a pas pu trouver la clé ou la valeur de Registre spécifiée. Cette erreur n’indique pas de problème et peut être ignorée.

  5. Copiez tous les fichiers de stratégie AppLocker de %windir %System32\AppLocker dans le dossier CiDiag :

    Copy-Item -Path $env:windir\System32\AppLocker -Destination $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\ -Recurse -Force -ErrorAction Ignore

  6. Collecter les informations des fichiers de stratégie AppLocker collectés à l’étape précédente :

    Get-ChildItem -Path $env:windir\System32\AppLocker\ -Recurse | select Mode,LastWriteTime,CreationTime,Length,Name >> $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerPolicyFiles.txt

  7. Exporter la stratégie AppLocker effective :

    Get-AppLockerPolicy -xml -Effective > $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLocker.xml

  8. Collecter les informations de configuration et d’état des services AppLocker :

    sc.exe query appid > $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerServices.txt; sc.exe query appidsvc >> $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerServices.txt; sc.exe query applockerfltr >> $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerServices.txt

Journaux des événements du contrôle d’application principal

Les événements de contrôle d’application sont générés sous deux emplacements :

  • Journaux des applications et des services - Microsoft - Windows - CodeIntegrity - Opérationnel
  • Journaux des applications et des services - Microsoft - Windows - AppLocker - MSI et script

Dans le répertoire de sortie CiDiag, ces journaux d’événements sont appelés CIOperational.evtx et ALMsiAndScript.evtx, respectivement.

Autres journaux des événements Windows qui peuvent être utiles

Parfois, vous pouvez compléter les informations contenues dans les journaux d’événements App Control principaux par des informations trouvées dans ces autres journaux d’événements. CiDiag.exe ne collecte pas ceux qui sont affichés en italique.

  • Journaux des applications et des services - Microsoft - Windows - CodeIntegrity - Verbose
  • Journaux d’applications et de services - Microsoft - Windows - AppLocker - EXE et DLL
  • Journaux des applications et des services - Microsoft - Windows - AppLocker - Déploiement d’applications empaquetées
  • Journaux des applications et des services - Microsoft - Windows - AppLocker - Exécution d’application empaquetée
  • Journaux des applications et des services - Microsoft - Windows - AppID - Opérationnel
  • Journaux des applications et des services - Microsoft - Windows - CAPI2 - Opérationnel
  • Journaux des applications et des services - Microsoft - Windows - DeviceGuard - Opérationnel
  • Journaux des applications et des services - Microsoft - Windows - PowerShell - *
  • Windows - Application
  • Windows - Système

2 - Utilisez les données de diagnostic et de journal pour identifier les problèmes

Après avoir rassemblé les informations de diagnostic nécessaires à partir d’un appareil, vous êtes prêt à commencer votre analyse des données de diagnostic collectées dans la section précédente.

  1. Vérifiez l’ensemble des stratégies de contrôle d’application actives et appliquées. Vérifiez que seules les stratégies que vous prévoyez d’être actives sont actives. Prenez connaissance des stratégies de boîte de réception Windows qui peuvent également être actives. Vous pouvez utiliser l’une de ces méthodes :

    • Examinez la sortie de CiTool.exe -lp, le cas échéant, qui a été enregistrée dans le répertoire de sortie CiDiag en tant que CiToolOutput.json. Consultez Utiliser Microsoft Edge pour afficher le fichier json mis en forme.
    • Examinez tous les événements d’activation de stratégie à partir du journal des événements de contrôle d’application principal que vous trouverez dans Journaux des applications et des services - Microsoft - Windows - CodeIntegrity - Opérationnel. Dans le répertoire de sortie CiDiag, ce journal des événements est appelé CIOperational.evtx.

  2. Examinez tous les événements de bloc pour les exécutables, les dll et les pilotes à partir du journal des événements de contrôle d’application principal que vous trouverez dans Journaux des applications et des services - Microsoft - Windows - CodeIntegrity - Opérationnel. Dans le répertoire de sortie CiDiag, ce journal des événements est appelé CIOperational.evtx. Utilisez les informations des événements de bloc et leur(s) événement(s) de détails de signature 3089 corrélés pour examiner les blocs inexpliqués ou inattendus. Pour référence, consultez l’exemple d’exécutable bloqué décrit plus loin dans cet article.

  3. Examinez tous les événements de bloc pour les applications empaquetées, les programmes d’installation MSI, les scripts et les objets COM à partir du journal des événements d’application du script principal trouvés dans Journaux d’applications et de services - Microsoft - Windows - AppLocker - MSI et script. Dans le répertoire de sortie CiDiag, ce journal des événements est appelé ALMsiAndScript.evtx. Utilisez les informations des événements de bloc et leur(s) événement(s) de détails de signature 8038 corrélés pour examiner les blocs inexpliqués ou inattendus.

La plupart des problèmes liés au contrôle d’applications, notamment les échecs d’application et de script, peuvent être diagnostiqués à l’aide des étapes précédentes.

Analyse d’événement pour un exemple d’exécutable bloqué

Voici un exemple d’EventData détaillé à partir d’un événement de bloc 3077 typique du mode d’application App Control et de l’un de ses 3089 événements d’informations de signature corrélés. Les tableaux qui suivent chaque capture d’écran d’événement décrivent certains des éléments contenus dans les événements. Après les descriptions des événements, vous trouverez une procédure pas à pas expliquant comment utiliser les événements pour comprendre pourquoi le blocage s’est produit.

Événement 3077 – Événement de blocage de l’application du contrôle d’application

Exemple 3077 : événement de bloc pour PowerShell.exe.

Nom d’élément Description
Système - Correlation - [ActivityID] Non affiché dans la capture d’écran
Utilisez l’ActivityID de corrélation pour faire correspondre un événement de bloc App Control avec un ou plusieurs événements de signature 3089.
Nom de fichier Le chemin d’accès et le nom du fichier sur le disque dont l’exécution a été bloquée. Étant donné que le nom sur le disque est modifiable, cette valeur n’est pas celle utilisée lors de la création de règles de fichier de contrôle d’application avec -Level FileName. Voir plutôt l’élément OriginalFileName plus loin dans ce tableau.
Nom du processus Chemin d’accès et nom du fichier qui a tenté d’exécuter le fichier bloqué. Également appelé processus parent.
Niveau de signature demandé Niveau d’autorisation de signature Windows que le code doit transmettre pour fonctionner. Voir Niveau de signature demandé et validé.
Niveau de signature validé Niveau d’autorisation de signature Windows attribué au code. Voir Niveau de signature demandé et validé.
Statut Code d’status Windows NT. Vous pouvez l’utiliser certutil.exe -error <status> pour rechercher la signification du code de status.
Hachage SHA-1 Hachage SHA1 Authenticode pour le fichier bloqué.
Hachage SHA-256 Hachage SHA256 Authenticode pour le fichier bloqué.
Hachage plat SHA-1 Hachage de fichier plat SHA1 pour le fichier bloqué.
Hachage plat SHA256 Hachage de fichier plat SHA256 pour le fichier bloqué.
PolicyName Nom convivial de la stratégie de contrôle d’application à l’origine de l’événement de blocage. Un événement de bloc 3077 distinct (ou événement de bloc d’audit 3076) s’affiche pour chaque stratégie qui bloque l’exécution du fichier.
PolicyId Valeur d’ID convivial de la stratégie de contrôle d’application à l’origine de l’événement de blocage.
PolicyHash Hachage SHA256 Authenticode du fichier binaire de stratégie de contrôle d’application à l’origine de l’événement de bloc.
OriginalFileName Nom de fichier immuable défini par le développeur dans l’en-tête de ressource du fichier bloqué. Cette valeur est celle utilisée lors de la création de règles de fichier de contrôle d’application avec -Level FileName.
InternalName Une autre valeur immuable définie par le développeur dans l’en-tête de ressource du fichier bloqué. Vous pouvez remplacer cette valeur par OriginalFileName dans les règles de fichier par -Level FileName -SpecificFileNameLevel InternalName.
Description du fichier Une autre valeur immuable définie par le développeur dans l’en-tête de ressource du fichier bloqué. Vous pouvez remplacer cette valeur par OriginalFileName dans les règles de fichier par -Level FileName -SpecificFileNameLevel FileDescription.
ProductName Une autre valeur immuable définie par le développeur dans l’en-tête de ressource du fichier bloqué. Vous pouvez remplacer cette valeur par OriginalFileName dans les règles de fichier par -Level FileName -SpecificFileNameLevel ProductName.
Version de fichier Valeur VersionEx de la stratégie utilisée pour appliquer le contrôle de version sur les stratégies signées.
PolicyGUID L’ID de stratégie de la stratégie de contrôle d’application à l’origine de l’événement de blocage.
UserWriteable Valeur booléenne indiquant si le fichier se trouvait dans un emplacement modifiable en écriture par l’utilisateur. Ces informations sont utiles pour diagnostiquer les problèmes lors de l’autorisation par les règles FilePath.
PackageFamilyName Nom de la famille de packages de l’application empaquetée (MSIX) qui inclut le fichier bloqué.

Événement 3089 – Événement d’informations sur la signature du contrôle d’application

Exemple 3089 événement d’informations de signature pour PowerShell.exe.

Nom d’élément Description
Système - Correlation - [ActivityID] Utilisez la corrélation ActivityID pour faire correspondre un événement de signature App Control à son événement de bloc.
TotalSignatureCount Nombre total de signatures détectées pour le fichier bloqué.
Signature Nombre d’index, à partir de 0, de la signature actuelle affichée dans cet événement 3089. Si le fichier avait plusieurs signatures, vous trouverez d’autres événements 3089 pour les autres signatures.
Hash Valeur de hachage utilisée par le contrôle d’application pour faire correspondre le fichier. Cette valeur doit correspondre à l’un des quatre hachages affichés sur l’événement de bloc 3077 ou 3076. Si aucune signature n’a été trouvée pour le fichier (TotalSignatureCount = 0), seule la valeur de hachage est affichée.
Type de signature Type de signature.
ValidatedSigningLevel Niveau d’autorisation de signature Windows atteint par la signature. Voir Niveau de signature demandé et validé.
VerificationError Raison pour laquelle cette signature particulière n’a pas réussi à passer la stratégie de contrôle d’application. Voir VerificationError.
Nom de l’éditeur La valeur du nom commun (CN) du certificat feuille.
Nom de l’émetteur Valeur CN du certificat disponible le plus élevé dans la chaîne de certificats. Ce niveau est généralement un certificat sous la racine.
PublisherTBSHash Hachage TBS du certificat feuille.
IssuerTBSHash Hachage TBS du certificat disponible le plus élevé dans la chaîne de certificats. Ce niveau est généralement un certificat sous la racine.

Présentation pas à pas des exemples d’événements 3077 et 3089

Voyons maintenant comment utiliser les données d’événement dans les exemples d’événements 3077 et 3089 pour comprendre pourquoi la stratégie de contrôle d’application a bloqué ce fichier.

Comprendre le fichier bloqué et le contexte de blocage

En ce qui concerne l’événement 3077, recherchez les informations qui identifient la stratégie, le fichier bloqué et le processus parent qui a tenté de l’exécuter. Prenez en compte ces informations de contexte pour déterminer si le bloc est attendu et souhaité.

Dans l’exemple, le fichier bloqué est PowerShell.exe, qui fait partie de Windows et devrait normalement s’exécuter. Toutefois, dans ce cas, la stratégie était basée sur le modèle de stratégie Windows en mode S, qui n’autorise pas l’exécution des hôtes de script afin de limiter la surface d’attaque. Pour le mode S, cet événement de bloc est un succès. Mais supposons que l’auteur de la politique n’était pas conscient de cette contrainte lorsqu’il a choisi le modèle, et traitons ce blocage comme inattendu.

Déterminer pourquoi le contrôle d’application a rejeté le fichier

Toujours en ce qui concerne l’événement 3077, nous voyons que le niveau de signature demandé de 2 signifie que le code doit passer la stratégie de contrôle d’application. Toutefois, le niveau de signature validé de 1 signifie que le code a été traité comme s’il n’était pas signé. « Non signé » peut signifier que le fichier était véritablement non signé, signé mais avec un certificat non valide, ou signé mais sans certificat autorisé par la stratégie de contrôle d’application.

Maintenant, inspectons le ou les 3089 événements corrélés pour le fichier bloqué. Dans l’exemple, nous examinons uniquement la première signature (index de signature 0) trouvée sur un fichier qui avait plusieurs signatures. Pour cette signature, le ValidatedSigningLevel est 12, ce qui signifie qu’il a une signature de produit Microsoft Windows. L’erreur de vérification de 21 signifie que la signature n’a pas passé la stratégie de contrôle d’application.

Il est important d’examiner les informations pour chaque événement 3089 corrélé, car chaque signature peut avoir un ValidatedSigningLevel et une VerificationError différents.

Important

Notez que le niveau de signature validé de l’événement 3077 est interprété de manière très différente de celui de ValidatedSigningLevel de l’événement 3089.

Dans le cas de l’événement 3077, le niveau de signature validé nous indique comment le binaire a été réellement traité par Windows.

Dans le cas de l’événement 3089, en revanche, ValidatedSigningLevel nous indique le niveau maximum potentiel que la signature pourrait recevoir. Nous devons utiliser l’erreur de vérification pour comprendre pourquoi la signature a été rejetée.

3 - Résoudre les problèmes courants

Après avoir analysé les données de diagnostic du contrôle d’application, vous pouvez prendre des mesures pour résoudre le problème ou effectuer d’autres étapes de débogage. Voici quelques problèmes courants et les étapes que vous pouvez essayer pour résoudre ou isoler davantage le problème racine :

Problème : un fichier bloqué que vous souhaitez autoriser

  • Utilisez les données des journaux d’événements principaux du contrôle d’application pour ajouter des règles afin d’autoriser le fichier bloqué.
  • Redéployez le fichier ou l’application à l’aide d’un programme d’installation géré si votre stratégie approuve les programmes d’installation gérés.

Problème : une stratégie active inattendue

Cette condition peut exister si :

  • Une stratégie a été supprimée, mais le système n’a pas été redémarré.
  • Une stratégie a été partiellement supprimée, mais une copie de la stratégie existe toujours dans la partition Système ou EFI.
  • Une stratégie avec PolicyId {A244370E-44C9-4C06-B551-F6016E563076} (format de stratégie unique) a été copiée à l’emplacement de la stratégie de format de stratégie multiple avant l’activation, ce qui entraîne un fichier binaire de stratégie en double sur le disque. Recherchez les fichiers SiPolicy.p7b et {A244370E-44C9-4C06-B551-F6016E563076}.cip dans les partitions système et EFI.
  • Une stratégie a été déployée de manière incorrecte sur l’appareil.
  • Un acteur malveillant disposant d’un accès administrateur a appliqué une stratégie pour provoquer un déni de service pour certains processus critiques.

Pour résoudre ce problème, suivez les instructions pour supprimer les stratégies de contrôle d’application pour la stratégie identifiée.

Problème : une défaillance d’application non gérée se produit et aucun événement de contrôle d’application n’est observé

Certaines applications modifient leur comportement lorsqu’une stratégie de contrôle d’application en mode utilisateur est active, ce qui peut entraîner des échecs inattendus. Il peut également s’agir d’un effet secondaire de l’application de scripts pour les applications qui ne gèrent pas correctement les comportements d’application implémentés par les hôtes de script.

Essayez d’isoler la cause racine en effectuant les actions suivantes :

  • Consultez les autres journaux des événements répertoriés dans la section 1 de cet article pour rechercher les événements correspondant aux échecs inattendus de l’application.
  • Remplacez temporairement la stratégie de contrôle d’application par une autre stratégie qui désactive l’application et le retest du script.
  • Remplacez temporairement la stratégie de contrôle d’application par une autre stratégie qui autorise tous les objets COM et retestez.
  • Remplacez temporairement la stratégie de contrôle d’application par une autre stratégie qui assouplit les autres règles de stratégie et effectuez un nouveau test.

Problème : une application déployée par un programme d’installation géré ne fonctionne pas

Pour déboguer les problèmes à l’aide du programme d’installation géré, procédez comme suit :

  • Vérifiez que la stratégie de contrôle d’application qui bloque l’application inclut la possibilité d’activer le programme d’installation géré.
  • Vérifiez que la stratégie AppLocker effective $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLocker.xml est correcte comme décrit dans Autoriser automatiquement les applications déployées par un programme d’installation géré.
  • Vérifiez que les services AppLocker sont en cours d’exécution. Ces informations se trouvent en $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerServices.txt créés dans la section 1 de cet article.
  • Vérifiez l’existence d’un fichier AppLocker appelé MANAGEDINSTALLER. APPLOCKER existe dans le dossier CiDiag créé précédemment. Si ce n’est pas le cas, répétez les étapes pour déployer et activer la configuration AppLocker du programme d’installation géré.
  • Redémarrez le processus du programme d’installation géré et case activée qu’un événement 8002 est observé dans le journal des événements AppLocker - EXE et DLL pour le processus de programme d’installation géré avec PolicyName = MANAGEDINSTALLER. Si à la place vous voyez un événement avec 8003 ou 8004 avec PolicyName = MANAGEDINSTALLER, vérifiez la case activée des règles ManagedInstaller dans le XML de stratégie AppLocker et assurez-vous qu’une règle correspond au processus de programme d’installation géré.
  • Utilisez fsutil.exe pour vérifier que les fichiers écrits par le processus du programme d’installation géré ont l’attribut étendu Origine du programme d’installation géré. Si ce n’est pas le cas, redéployez les fichiers avec le programme d’installation géré et effectuez une nouvelle case activée.
  • Testez l’installation d’une autre application à l’aide du programme d’installation managé.
  • Ajoutez un autre programme d’installation géré à votre stratégie AppLocker et testez l’installation à l’aide de l’autre programme d’installation géré.
  • Vérifiez si l’application rencontre une limitation connue avec le programme d’installation géré. Si c’est le cas, vous devez autoriser l’application par d’autres moyens.

Problème : Une application que vous attendiez à autoriser par l’éditeur ISG (Intelligent Security Graph) ne fonctionne pas

Pour déboguer les problèmes à l’aide d’ISG, procédez comme suit :

  • Vérifiez que la stratégie de contrôle d’application qui bloque l’application inclut la possibilité d’activer le graphique de sécurité intelligent.
  • Vérifiez que les services AppLocker sont en cours d’exécution. Ces informations se trouvent en $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerServices.txt créés dans la section 1 de cet article.
  • Utilisez fsutil.exe pour vérifier que les fichiers ont l’attribut étendu origine ISG. Si ce n’est pas le cas, redéployez les fichiers avec le programme d’installation géré et effectuez une nouvelle case activée.
  • Vérifiez si l’application rencontre une limitation connue avec ISG.

Problème : l’antivirus Microsoft Defender est en mode passif après l’activation d’App Control ou de l’ISG

Lorsque vous activez le contrôle d’application avec ISG ou Smart App Control, Antivirus Microsoft Defender peut s’exécuter en mode passif ou hybride. Cet état est un comportement attendu, pas un échec. Le contrôle d’application utilise les informations de réputation fournies par Defender dans le cadre de ses décisions d’exécution du code. Cet état ne modifie pas le comportement de Defender sur le système. La protection antivirus en temps réel continue d’être assurée par la solution antivirus que vous avez choisie.

Pour vérifier le mode de fonctionnement de Defender dans une case activée, exécutez la commande suivante dans PowerShell et examinez la AMRunningMode valeur :

Get-MpComputerStatus | Select-Object AMRunningMode

Attendez-vous à une valeur en mode passif ou en mode hybride si vous avez intentionnellement activé App Control avec l’ISG ou Smart App Control activé. Vous devez seulement examiner si vous n’avez pas activé App Control avec l’ISG ou Smart App Control et que vous ne vous attendez pas à ce mode, ou si vous n’avez pas non plus d’antivirus tiers. Dans ce cas, vérifiez quelles stratégies de contrôle d’application sont actives et passez en revue Microsoft Defender Antivirus et Contrôle d’application.

4 - Signalez les problèmes à Microsoft, le cas échéant

Si, après avoir suivi les instructions couvertes dans cet article, vous pensez avoir identifié un problème de produit, signalez-le à Microsoft.

  • Les clients bénéficiant du support Microsoft Premier doivent enregistrer une demande de service via les canaux normaux.
  • Tous les autres clients peuvent signaler des problèmes directement à l’équipe produit App Control via le Hub de commentaires Windows. Sélectionnez la catégorie Sécurité & confidentialité - Contrôle d’application pour vous assurer que le problème est correctement acheminé à l’équipe produit Contrôle des applications.

Lorsque vous signalez des problèmes, veillez à fournir les informations suivantes :

  • Last updated on