Risque de Windows Attachment Manager : vérifier les stratégies utilisateur

Qu’est-ce que le risque de Windows Attachment Manager ?

Le risque de Windows Attachment Manager pose une question de stratégie de traitement des fichiers : quelle pièce jointe déclenche un avertissement ou un blocage, pour quel utilisateur et dans quelle application ? Un inventaire des GPO peut repérer les paramètres à examiner, mais la clôture de cette revue exige des preuves issues du parcours utilisateur visé.

Deux situations appellent des décisions différentes. Un inventaire ne contenant ni DefaultFileTypeRisk ni LowRiskFileTypes soulève la question de la configuration explicite. Une stratégie choisissant un risque par défaut faible ou ajoutant des extensions de script à une liste à faible risque soulève celle d’une exception explicite. Présenter les deux cas comme la preuve que tous les scripts téléchargés s’exécutent sans avertissement dépasserait ce que montrent les éléments disponibles.

Ce guide s’appuie sur la documentation Microsoft Learn et le code etc-collector relu. Les commandes Windows ci-dessous sont des exemples de lecture fondés sur la documentation, et non des commandes exécutées dans un environnement Windows pour cet article. La procédure pilote constitue une méthode de vérification proposée ; aucun test réussi, nombre de postes affectés ou attaque n’est revendiqué.

Fonctionnement : valeurs par défaut, listes et contexte applicatif

La référence des stratégies Attachment Manager de Microsoft situe ces paramètres sous Configuration utilisateur > Modèles d’administration > Composants Windows > Attachment Manager, avec les correspondances de risque et de listes dans Software\Microsoft\Windows\CurrentVersion\Policies\Associations.

Le comportement documenté distingue trois classes de risque :

Une stratégie de risque par défaut non configurée ou désactivée conserve un risque modéré. Une stratégie de faible risque non configurée conserve la logique de confiance par défaut. L’inclusion personnalisée à risque élevé prime sur les inclusions à risque moyen et faible ; l’inclusion à risque moyen prime sur celle à risque faible. L’inclusion à faible risque prime sur la liste intégrée à risque élevé : les chevauchements entre listes personnalisées comptent donc. La logique de confiance par défaut privilégie le gestionnaire ; une stratégie distincte de logique de confiance peut modifier cette évaluation. Définitions des stratégies Microsoft

Le contexte applicatif fait également partie du mécanisme. La référence IAttachmentExecute de Microsoft décrit une interface utilisée par les applications clientes, notamment pour les contrôles de stratégie, les avertissements, l’enregistrement et l’exécution. SetSource fournit les informations de provenance et SetReferrer le contexte de zone ; le client possède aussi ses propres paramètres de pièces jointes. Cela ne démontre pas que toutes les applications utilisent l’interface de manière identique.

Pour une revue, identifiez l’application qui reçoit le fichier, l’action effectuée par l’utilisateur et les informations de provenance disponibles à ce moment. Un résultat de détection ne peut combler ces lacunes. Ne passez pas d’une chaîne de stratégie au niveau du domaine à une affirmation concernant un navigateur, un client de messagerie, une association de fichiers ou un chemin de lancement inconnu.

Détection : inventorier les stratégies utilisateur et comparer le pilote

Étape 1 : conserver la configuration des GPO

Inventoriez les GPO pertinentes avant toute modification. Consignez l’identité de chaque GPO, ses liens, son périmètre utilisateur, son filtrage, l’heure de collecte et ses valeurs de stratégie brutes. Examinez Configuration utilisateur et le fichier User\Registry.pol décodé, sans supposer qu’un rapport de stratégie ordinateur contient les paramètres des pièces jointes. Conservez les configurations contradictoires afin de les réconcilier.

La fiche de revue doit inclure :

Distinguez les valeurs absentes, vides, non collectées et les échecs de lecture. En particulier, le parseur utilisé par les deux contrôles EtcSec ne conserve pas une chaîne LowRiskFileTypes vide. L’absence d’un champ après analyse ne suffit donc pas à reconstituer l’état original de la stratégie.

Nos quatre contrôles de sécurité GPO Active Directory exposent la même discipline pour d’autres paramètres : conserver la configuration, identifier le périmètre destinataire et vérifier les preuves côté client. Leurs contrôles LLMNR, WSUS, LSASS et UNC constituent une méthode de revue utile, tandis que cette investigation porte sur le traitement des pièces jointes utilisateur.

Étape 2 : récupérer le résultat de stratégie de l’utilisateur cible

Sur l’ordinateur pilote, utilisez la session de l’utilisateur visé et obtenez la synthèse du périmètre utilisateur :

gpresult /scope user /r

Pour un relevé plus détaillé, exécutez séparément :

gpresult /scope user /z

La référence gpresult de Microsoft documente le périmètre utilisateur, la sortie synthétique et la sortie détaillée des stratégies. Résolvez les divergences entre l’inventaire des GPO et le résultat rapporté avant d’interpréter les valeurs locales. Conservez les erreurs comme telles ; un rapport indisponible ne peut servir de preuve que la GPO souhaitée s’est appliquée.

Étape 3 : lire les valeurs du registre utilisateur

Exécutez chaque commande séparément dans le contexte de l’utilisateur visé. Ces exemples combinent la syntaxe reg query documentée par Microsoft avec la clé Associations ci-dessus :

reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Associations" /v DefaultFileTypeRisk

reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Associations" /v LowRiskFileTypes

reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Associations" /v HighRiskFileTypes

HKCU désigne la ruche de l’utilisateur actuel. Exécuter la requête en tant qu’autre administrateur change le sujet de l’observation. Conservez la commande, le compte, l’hôte, l’heure, le type de valeur et la sortie ; distinguez une valeur absente d’un échec de commande. Comparez ces lectures à la GPO responsable et au résultat de stratégie, au lieu de remplacer une sortie manquante par une valeur supposée sûre ou dangereuse.

Étape 4 : comparer la configuration au traitement observé

Définissez un pilote autorisé avec des fichiers représentatifs inoffensifs et les responsables des applications. Consignez l’extension, la provenance, les informations de zone lorsqu’elles sont disponibles, l’application destinataire, l’action choisie et si l’accès a été bloqué, a déclenché un avertissement ou a été autorisé. Conservez les résultats inattendus pour investigation ; n’inscrivez pas un avertissement attendu comme s’il avait été observé.

Utilisez une matrice avec une ligne par parcours testé. Incluez une référence de configuration avant/après et le résultat réel. Un résultat obtenu par une action dans un client de messagerie étaye cette observation précise ; il ne démontre pas tous les chemins de lancement locaux ni toutes les populations d’utilisateurs. Ces sources n’établissent aucun Windows Event ID universel pour cette revue de configuration.

Remédiation : examiner les exceptions avant de modifier les avertissements (Remediation)

Étape 1 : attribuer la responsabilité de la configuration

Identifiez l’administrateur responsable de la stratégie utilisateur qui l’emporte et les responsables des applications nécessitant des exceptions. Rassemblez la valeur par défaut brute et toutes les listes d’inclusion pertinentes dans une même revue. Conservez l’export initial afin que la décision puisse être reliée à une configuration réelle plutôt qu’à une description abrégée du résultat de détection.

Classez le cas comme absence de configuration explicite, affaiblissement explicite, conflit de stratégies ou preuves incomplètes. N’appliquez pas la même correction aux quatre cas. Un paramètre absent demande une décision sur le comportement souhaité ; une exception existante exige une justification et une revue de compatibilité ; un échec de collecte exige une mesure réussie.

Étape 2 : supprimer les affaiblissements injustifiés dans une stratégie pilote

Pour un pilote géré par GPO, examinez Niveau de risque par défaut pour les pièces jointes et les paramètres d’inclusion au chemin Attachment Manager indiqué plus haut. Examinez DefaultFileTypeRisk = 6152, la valeur testée par le détecteur d’affaiblissement, ainsi que chaque entrée de script dans LowRiskFileTypes. Supprimez les exceptions injustifiées au moyen de la stratégie responsable et documentez toute dépendance conservée.

Choisissez la valeur par défaut et les listes souhaitées après avoir examiné les exigences applicatives et de provenance. Évitez de substituer une valeur par défaut faible généralisée à une décision de compatibilité propre à une application. Vérifiez les inclusions personnalisées à risque élevé et modéré avec les entrées à faible risque avant de prédire le résultat. La présence d’une sous-chaîne de script dans la chaîne collectée à faible risque déclenche une revue ; elle ne constitue pas une évaluation complète du risque Windows.

Étape 3 : collecter de nouveau les preuves utilisateur et tester le parcours

Répétez les lectures gpresult du périmètre utilisateur et du registre après l’application de la stratégie, avec la même identité pilote. Rejouez les parcours inoffensifs convenus et consignez les résultats réels avec les responsables des applications. Si la configuration a changé mais que le comportement observé ne correspond pas aux attentes, examinez le chemin applicatif, la provenance et les conflits de stratégies avant d’étendre le déploiement.

Étape 4 : maintenir des contrôles d’exécution complémentaires

La seule stratégie de risque des pièces jointes ne peut démontrer un contrôle complet des scripts. Notre guide des règles ASR Defender via GPO couvre des règles de comportement complémentaires, avec vérification séparée des identifiants de règles, actions et exclusions sur les appareils. Une revue réussie de la stratégie des pièces jointes ne valide ni ASR ni AppLocker.

Ne clôturez la remédiation sur le périmètre concerné qu’avec la décision de stratégie, la configuration utilisateur résultante, le comportement applicatif examiné et les responsables des exceptions joints au dossier. Traitez la couverture d’un déploiement plus large comme une question de preuves distincte. Une modification GPO achevée ou un changement du compteur du collecteur ne démontre pas la protection de toute la flotte.

Comment EtcSec détecte cette configuration

Les deux implémentations etc-collector relues sont des contrôles GPO de niveau Medium. Elles examinent les champs de registre collectés, selon ces branches exactes :

Pour le second contrôle, les sous-chaînes testées sont .hta, .js, .vbs, .wsf, .wsh et .ps1. Le code ajoute une raison pour le risque par défaut 6152 et une seule raison combinée si l’une de ces sous-chaînes apparaît. Plusieurs extensions correspondantes ne contribuent toujours qu’à une raison pour la liste. Il s’agit d’une recherche de sous-chaînes, et non d’une analyse stricte de liste d’extensions ; un jeton plus long contenant .js, par exemple, peut correspondre.

Chaque champ est sélectionné indépendamment. Les détecteurs recherchent d’abord dans les paramètres de registre Machine et ne consultent les paramètres User que si le résultat Machine de ce champ est nil. Le helper Machine privilégie Default Domain Controllers Policy, puis Default Domain Policy, puis une autre GPO disponible. Le helper User renvoie la première valeur non-nil rencontrée dans une map Go. Ce parcours de map ne fournit aucune précédence stable des stratégies Windows.

Le parseur de registre associe un DWORD valide nommé defaultfiletyperisk sous une clé contenant associations ; il associe lowriskfiletypes uniquement lorsque la chaîne analysée n’est pas vide. Les contrôles relus n’évaluent pas les listes d’inclusion à risque élevé ou modéré, la logique de confiance du client ni le comportement applicatif. Les deux champs étant sélectionnés séparément, leurs valeurs peuvent aussi provenir de GPO différentes.

Toute valeur non-nil dans l’un des deux champs sélectionnés supprime le compteur d’absence, sans valider sa sécurité. De même, un compteur d’affaiblissement à zéro ne démontre ni une collecte complète, ni une application correcte des stratégies, ni un traitement sûr des pièces jointes. Aucun contrôle ne mesure une exécution universelle sans avertissements, ne valide AppLocker ou ASR, ni ne démontre la sécurité de la flotte. Aucun résultat de détection ne démontre une attaque.

Utilisez le résultat pour ouvrir la revue délimitée décrite ci-dessus. Conservez ensemble l’inventaire des stratégies, les preuves du résultat utilisateur et les observations réelles du pilote, afin que l’éditeur ou l’administrateur puisse distinguer un signal de configuration d’un comportement démontré.