Partager via

Débogage et résolution des problèmes de 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 for Business.

1 - Collecter les données de diagnostic App Control

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

Exécutez les commandes suivantes à partir d’une fenêtre PowerShell avec élévation de privilèges pour collecter les informations de diagnostic dont vous pourriez avoir besoin :

  1. Collectez les données de diagnostic App Control générales 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 App Control 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 dans 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 valeur ou la clé de Registre spécifiée. Cette erreur n’indique pas de problème et peut être ignorée.

  5. Copiez 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. Collectez les informations sur les 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. Exportez la stratégie AppLocker effective :

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

  8. Collectez 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 Core App Control

Les événements App Control sont générés à 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 d’événements Windows qui peuvent être utiles

Parfois, vous pouvez être en mesure de compléter les informations contenues dans les journaux des événements App Control de base par des informations trouvées dans ces autres journaux d’événements. CIDiag.exe ne collecte pas ceux affichés en italique.

  • Journaux des applications et des services - Microsoft - Windows - CodeIntegrity - Verbose
  • Journaux des applications et des 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’applications empaquetées
  • 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 - Utiliser les données de diagnostic et de journal pour identifier les problèmes

Après avoir collecté les informations de diagnostic nécessaires à partir d’un appareil, vous êtes prêt à commencer l’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 qui sont actives et appliquées. Vérifiez que seules les stratégies que vous prévoyez d’être actives sont actuellement actives. Tenez compte des stratégies de boîte de réception Windows qui peuvent également être actives. Vous pouvez utiliser l’une des méthodes suivantes :

    • 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.
    • Passez en revue tous les événements d’activation de stratégie à partir du journal des événements App Control de base qui se trouve 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. Passez en revue tous les événements de blocage pour les exécutables, dll et pilotes à partir du journal des événements App Control de base trouvé 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 leurs événements de détails de signature 3089 corrélés pour examiner les blocs qui sont inexpliqués ou inattendus. Pour plus d’informations, consultez l’exemple d’exécutable bloqué décrit plus loin dans cet article.

  3. Passez en revue tous les événements de blocage pour les applications empaquetées, les programmes d’installation MSI, les scripts et les objets COM à partir du journal des événements d’application de script principal disponible dans Journaux des applications et des 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 leurs événements de détails de signature 8038 corrélés pour examiner les blocs qui sont inexpliqués ou inattendus.

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

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

Voici un exemple d’eventData détaillé à partir d’un événement de bloc de mode d’application App Control 3077 classique et d’un de ses événements d’informations de signature 3089 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. Vous trouverez ci-dessous 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 d’application du contrôle d’application

Exemple d’événement de bloc 3077 pour PowerShell.exe.

Nom d’élément Description
Système - Corrélation - [ActivityID] Non affiché dans la capture d’écran
Utilisez l’Id d’activité de corrélation pour faire correspondre un événement de bloc App Control à un ou plusieurs événements de signature 3089.
Nom de fichier Le chemin d’accès et le nom du fichier sur le disque qui a été bloqué pour s’exécuter. Étant donné que le nom sur le disque est mutable, cette valeur n’est pas celle utilisée lors de la création de règles de fichier App Control avec -Level FileName. Au lieu de cela, consultez 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 devait passer pour s’exécuter. Consultez Niveau de signature demandé et validé.
Niveau de signature validé Niveau d’autorisation de signature Windows attribué au code. Consultez Niveau de signature demandé et validé.
Statut Code status Windows NT. Vous pouvez utiliser certutil.exe -error <status> pour rechercher la signification du code status.
Hachage SHA1 Hachage SHA1 Authenticode pour le fichier bloqué.
Hachage SHA256 Hachage SHA256 Authenticode pour le fichier bloqué.
SHA1 Hachage plat 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 qui a provoqué l’événement de blocage. Un événement de bloc 3077 distinct (ou événement de bloc d’audit 3076) est affiché 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 qui a provoqué l’événement de blocage.
PolicyHash Hachage SHA256 Authenticode du binaire de stratégie App Control qui a provoqué l’événement de blocage.
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 App Control 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.
FileDescription 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.
FileVersion Valeur VersionEx de la stratégie utilisée pour appliquer le contrôle de version aux stratégies signées.
PolicyGUID PolicyId de la stratégie De contrôle d’application qui a provoqué l’événement de blocage.
UserWriteable Valeur booléenne indiquant si le fichier se trouvait à un emplacement accessible 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 pour l’application empaquetée (MSIX) qui inclut le fichier bloqué.

Événement 3089 - Événement d’informations de signature App Control

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

Nom d’élément Description
Système - Corrélation - [ActivityID] Utilisez l’Id d’activité de corrélation 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 App Control 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.
SignatureType Type de signature.
ValidatedSigningLevel Niveau d’autorisation de signature Windows atteint par la signature. Consultez Niveau de signature demandé et validé.
VerificationError La raison pour laquelle cette signature particulière n’a pas réussi à passer la stratégie de contrôle d’application. Consultez VerificationError.
PublisherName Valeur de nom commun (CN) du certificat feuille.
IssuerName Valeur CN du certificat le plus élevé disponible dans la chaîne de certificats. Ce niveau correspond généralement à un certificat sous la racine.
PublisherTBSHash Hachage TBS du certificat feuille.
IssuerTBSHash Hachage TBS du certificat le plus élevé disponible dans la chaîne de certificats. Ce niveau correspond généralement à un certificat sous la racine.

Procédure 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 faisant référence à 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. Tenez compte de 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 les hôtes de script à s’exécuter pour 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 stratégie ne connaissait pas cette contrainte lorsqu’il a choisi le modèle et qu’il considère ce bloc comme inattendu.

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

Une fois de plus, en faisant référence à 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 était non signé. « Non signé » peut signifier que le fichier a été réellement non signé, signé mais avec un certificat non valide ou signé, mais sans aucun certificat autorisé par la stratégie De contrôle d’application.

À présent, examinons le ou les événements 3089 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, validatedSigningLevel a la valeur 12, ce qui signifie qu’elle a une signature de produit Microsoft Windows. La valeur VerificationError de 21 signifie que la signature n’a pas réussi la stratégie De contrôle d’application.

Il est important de passer en revue les informations relatives à chaque événement 3089 corrélé, car chaque signature peut avoir des valeurs ValidatedSigningLevel et VerificationError différentes.

Important

Notez que le niveau de signature validé sur l’événement 3077 est interprété très différemment de validatedSigningLevel sur 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.

En revanche, dans le cas de l’événement 3089, ValidatedSigningLevel nous indique le niveau maximal potentiel que la signature peut recevoir. Nous devons utiliser verificationError 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 App Control, 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 étapes que vous pouvez essayer de résoudre ou d’isoler davantage le problème racine :

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

  • Utilisez les données des principaux journaux des événements App Control 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 est active et 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 à stratégie unique) a été copiée à l’emplacement de la stratégie de format de stratégie multiple avant l’activation, ce qui a entraîné 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é incorrectement déployée sur l’appareil.
  • Un attaquant 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 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 des scripts et effectue un nouveau test.
  • Remplacez temporairement la stratégie De contrôle d’application par une autre stratégie qui autorise tous les objets COM et les tester à nouveau.
  • 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 reteste.

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

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

  • Vérifiez que la stratégie de contrôle d’application qui bloque l’application inclut l’option permettant 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 dans $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerServices.txt créées dans la section 1 de cet article.
  • Vérifiez qu’il existe 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 managé.
  • Redémarrez le processus du programme d’installation managé et case activée qu’un événement 8002 est observé dans le journal des événements AppLocker - EXE et DLL pour le processus d’installation managé avec PolicyName = MANAGEDINSTALLER. Si vous voyez plutôt un événement avec 8003 ou 8004 avec PolicyName = MANAGEDINSTALLER, case activée les règles ManagedInstaller dans le xml de stratégie AppLocker et vérifiez qu’une règle correspond au processus du programme d’installation managé.
  • Utilisez fsutil.exe pour vérifier que les fichiers écrits par le processus du programme d’installation managé ont l’attribut étendu d’origine du programme d’installation managé. Si ce n’est pas le cas, redéployez les fichiers avec le programme d’installation géré et case activée à nouveau.
  • 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 à l’aide d’autres moyens.

Problème : une application que vous attendiez à ce que le graphe de sécurité intelligent (ISG) autorise 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 l’option permettant d’activer le graphe de sécurité intelligent.
  • Vérifiez que les services AppLocker sont en cours d’exécution. Ces informations se trouvent dans $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerServices.txt créées dans la section 1 de cet article.
  • Utilisez fsutil.exe pour vérifier que les fichiers ont l’attribut étendu d’origine ISG. Si ce n’est pas le cas, redéployez les fichiers avec le programme d’installation géré et case activée à nouveau.
  • Vérifiez si l’application rencontre une limitation connue avec ISG.

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

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

  • Les clients disposant du support Microsoft Premier doivent enregistrer une demande de service par le biais de canaux normaux.
  • Tous les autres clients peuvent signaler les 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 routé vers l’équipe produit App Control.

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