Chemins de scripts de connexion AD : examiner scriptPath avant les ACL

Ce que signifient les chemins de scripts de connexion AD

Les chemins de scripts de connexion AD méritent un inventaire et une revue des responsabilités avant toute modification des permissions. Un attribut utilisateur renseigné indique où un script de connexion est configuré ; il ne dit pas si la cible existe, si quelqu'un l'utilise encore ni qui peut modifier son contenu. Considérez le chemin comme le point de départ de la collecte de preuves.

La référence de schéma Script-Path de Microsoft identifie scriptPath comme le chemin du script de connexion de l'utilisateur et autorise une chaîne nulle. Le paramètre ScriptPath de New-ADUser accepte un chemin local absolu ou un chemin UNC (Universal Naming Convention). Une valeur UNC est donc une option de configuration documentée. Sa seule présence ne démontre pas un contrôle d'accès insuffisant.

Les questions utiles sont concrètes : quel utilisateur pointe vers quelle cible, qui est responsable de la fonction métier, quels clients l'utilisent et quels principaux peuvent modifier cette cible ? Le responsable du compte, le mainteneur du script et l'administrateur du serveur de fichiers peuvent être des personnes différentes. Consignez chaque responsabilité plutôt que de supposer que le propriétaire du système de fichiers approuve aussi l'usage métier.

Fonctionnement : distinguer affectation, contenu et usage

La revue comporte trois niveaux. L'attribut d'annuaire affecte un chemin. Le fichier référencé et ses dépendances contiennent les instructions. Le comportement réel du client à la connexion détermine si ces instructions sont utilisées. Les preuves d'un niveau ne peuvent pas remplacer celles des autres.

La technique Network Logon Script de MITRE ATT&CK décrit l'abus de scripts affectés via Active Directory ou une stratégie de groupe et recommande de réserver leur écriture aux administrateurs désignés. Elle décrit une exécution avec les privilèges de l'utilisateur concerné. Ne déduisez pas une exécution SYSTEM d'un constat portant sur un chemin réseau. Pour rechercher un éventuel abus, établissez une capacité non autorisée à modifier le script ou à rediriger son affectation, puis établissez qu'un client pertinent utilise le contenu modifié. Cet article n'affirme pas que l'un ou l'autre de ces événements s'est produit.

Distinguez le scriptPath de l'utilisateur des scripts configurés dans une GPO. Si le déploiement de stratégies intervient, utilisez la revue distincte des droits Read, Apply et du périmètre des GPO. Ses questions concernant Read pour l'ordinateur et Apply ciblé portent sur la récupération et l'application de la stratégie ; elles n'établissent pas qui peut réécrire le fichier référencé par l'attribut d'un utilisateur.

Inspectez aussi le contenu pour rechercher des dépendances et des identifiants exposés selon le processus de revue approprié. La revue existante des identifiants dans les fichiers SYSVOL, y compris les scripts traite de ce sujet. Un inventaire des chemins ne peut pas établir si un script contient un secret, et ce processus ne répète pas l'investigation distincte sur cPassword.

Détection : inventorier les utilisateurs, résoudre les cibles et inspecter les deux ACL

1. Inventorier les chemins configurés sans exclure les utilisateurs désactivés

Exécutez les exemples suivants depuis un environnement d'administration Windows autorisé, doté des modules nécessaires. Ce sont des exemples fondés sur la documentation, pas des commandes exécutées sur un domaine client. Remplacez le serveur, la base de recherche, les identités et les chemins d'exemple par des valeurs approuvées.

La référence Get-ADUser documente -LDAPFilter, -SearchBase, -Server et la récupération d'attributs supplémentaires avec -Properties. Cette requête inventorie les utilisateurs dont scriptPath est présent, y compris les comptes désactivés :

Get-ADUser -LDAPFilter '(scriptPath=*)' -SearchBase 'DC=example,DC=com' -Server 'dc01.example.com' -Properties scriptPath | Format-List -Property DistinguishedName,SamAccountName,Enabled,scriptPath

Une alternative utilisant la syntaxe de filtre du module est :

Get-ADUser -Filter 'scriptPath -like "*"' -SearchBase 'DC=example,DC=com' -Server 'dc01.example.com' -Properties scriptPath | Format-List -Property DistinguishedName,SamAccountName,Enabled,scriptPath

Le motif de présence de l'attribut adapte les exemples de filtres Active Directory de Microsoft. Format-List affiche les propriétés nommées ; conservez aussi l'inventaire sous-jacent dans votre système de preuves approuvé. Consignez le contrôleur de domaine interrogé, la base de recherche, l'heure de collecte et les erreurs éventuelles. Une requête partielle ou échouée ne constitue pas un inventaire complet.

Associez chaque utilisateur au chemin et à un responsable. Gardez les comptes désactivés visibles comme des cas de gestion du cycle de vie : demandez si l'affectation est conservée pour un retour prévu, copiée depuis un modèle ou obsolète. N'activez pas un compte pour tester son script. L'affectation d'un utilisateur désactivé ne démontre pas un usage actuel ; elle peut néanmoins identifier une cible partagée avec d'autres utilisateurs.

2. Résoudre la cible dans le contexte réel du client

Préservez la valeur littérale de l'attribut avant de l'interpréter. Pour une chaîne relative, identifiez sa base de résolution sur le client et dans le processus de connexion concernés ; ne la résolvez pas par rapport au répertoire courant de votre shell d'administration. Pour un chemin local absolu, identifiez le client sur lequel ce fichier doit exister. Pour un chemin réseau, identifiez le serveur, le partage et le fichier réellement atteints par le client de test. Consignez explicitement les cas non résolus.

Demandez au mainteneur de quels scripts, exécutables, fichiers de configuration ou autres ressources dépend le point d'entrée. Examinez aussi ces cibles. Modifier uniquement l'ACL du point d'entrée ne suffit pas si une dépendance non examinée fournit les instructions utilisées par le script.

Après résolution d'un fichier candidat, cet exemple utilise les paramètres documentés de Test-Path :

Test-Path -LiteralPath '\\files01.example.com\LogonScripts\onboarding.cmd' -PathType Leaf

Leaf teste un élément de type fichier ; -LiteralPath évite l'interprétation des caractères génériques. Consignez l'identité, le client et les erreurs avec le résultat. Ce test d'existence ne prouve ni une exécution réussie à la connexion, ni la correction du script, ni la permission de modifier le fichier. Confirmez l'usage réel lors d'un pilote approuvé avec le responsable du script.

3. Inspecter indépendamment les permissions du partage et du système de fichiers

Sur le serveur de fichiers identifié, utilisez Get-SmbShare pour associer le nom du partage à son chemin local. Utilisez ensuite Get-SmbShareAccess pour récupérer son ACL de partage. Ces exemples adaptent les requêtes -Name documentées :

Get-SmbShare -Name 'LogonScripts' | Format-List -Property Name,ScopeName,Path

Get-SmbShareAccess -Name 'LogonScripts'

Exécutez-les sur le serveur qui héberge réellement la cible. Si le partage relève d'un périmètre particulier, identifiez ce périmètre et utilisez le paramètre -ScopeName documenté. Un partage de même nom sur un autre serveur ne constitue pas une preuve pour cette cible. Préservez chaque principal bénéficiaire, entrée Allow ou Deny et niveau d'accès.

Pour NTFS, Get-Acl récupère le descripteur de sécurité de la ressource sous Windows. Après confirmation du véritable chemin local, inspectez le fichier et le répertoire qui le contient :

Get-Acl -LiteralPath 'D:\LogonScripts\onboarding.cmd' | Format-List -Property *

Get-Acl -LiteralPath 'D:\LogonScripts' | Format-List -Property *

Ce sont des exemples, pas l'affirmation que ce partage correspond à D:\LogonScripts. Collectez le propriétaire, les entrées d'accès et l'héritage. Résolvez les groupes derrière chaque principal bénéficiaire avant de conclure quels utilisateurs peuvent modifier le contenu. La liste des ACL est une preuve pour cette revue, pas une simulation de l'accès effectif de chaque identité.

Le modèle de sécurité des fichiers de Microsoft évalue les droits demandés par rapport au jeton de l'appelant et au descripteur de l'objet. Ses constantes de droits d'accès aux fichiers distinguent l'écriture de données dans un fichier, la création de fichiers dans un répertoire et la suppression d'éléments enfants. Examinez la capacité à modifier ou remplacer le contenu ainsi que l'administration des permissions ; la lecture du script est une question différente. Examinez ensemble les preuves du partage et de NTFS pour la voie d'accès précise.

Remédiation : examiner d'abord, puis apporter une correction ciblée (Remediation)

1. Convenir du comportement attendu et des personnes autorisées à écrire

Pour chaque affectation, consignez le responsable métier, la population de clients attendue, les mainteneurs approuvés et les droits de lecture nécessaires. Classez-la comme nécessaire, obsolète ou non résolue. Rendez l'incertitude visible plutôt que de la considérer comme une autorisation de suppression. Une cible partagée peut avoir plusieurs consommateurs : coordonnez donc sa modification avec chaque responsable concerné.

2. Préserver un état de retour arrière et tester la modification sur un pilote

Préservez l'attribut actuel, le contenu cible, les dépendances et les deux ensembles de permissions selon votre processus de sauvegarde approuvé. Choisissez un utilisateur de test activé et un client représentatifs. Définissez le résultat attendu et les conditions d'échec avant le pilote. Pour les comptes désactivés, prenez une décision de cycle de vie plutôt que de forcer un test de connexion.

3. Corriger le problème vérifié à sa source

Si la cible est nécessaire mais qu'un principal non prévu peut la modifier, faites corriger le droit précis du partage ou de NTFS par le responsable du serveur de fichiers, selon la procédure de changement approuvée. Examinez les droits hérités et les dépendances avant de choisir la modification. La mesure d'atténuation de MITRE préconise de restreindre les personnes pouvant écrire les scripts ; elle ne prescrit pas une ACL universelle pour tous les environnements.

Si l'affectation pointe vers une mauvaise cible, ne modifiez l'attribut de cet utilisateur qu'après validation du remplacement. L'aperçu suivant utilise les paramètres ScriptPath et WhatIf documentés de Set-ADUser :

Set-ADUser -Identity 'CN=PilotUser,OU=Users,DC=example,DC=com' -Server 'dc01.example.com' -ScriptPath '\\files01.example.com\LogonScripts\approved.cmd' -WhatIf

-WhatIf prévisualise l'opération sans l'appliquer. Cette commande est une option pour corriger une affectation approuvée, pas une recommandation de migrer tous les utilisateurs vers des chemins UNC. Si une affectation est obsolète, retirez-la selon la procédure de gestion des comptes convenue, après vérification des dépendances partagées. Ne supprimez pas un fichier référencé au seul motif qu'un utilisateur n'en a plus besoin.

4. Relire la configuration et vérifier le comportement autorisé

Interrogez de nouveau l'utilisateur précis après la modification approuvée :

Get-ADUser -Identity 'CN=PilotUser,OU=Users,DC=example,DC=com' -Server 'dc01.example.com' -Properties scriptPath | Format-List -Property DistinguishedName,Enabled,scriptPath

Relisez les deux ACL si les permissions ont changé. Répétez le test client approuvé par le responsable et validez la récupération nécessaire ainsi que le comportement attendu. Lorsque cela convient, vérifiez qu'une personne non prévue pour écrire ne dispose pas d'un accès effectif en modification, selon la procédure de test d'accès autorisée de l'organisation. Conservez le contexte du test, les résultats, les exceptions et la décision de retour arrière avec l'inventaire. La seule relecture de l'attribut ne peut pas valider les effets du script.

Comment EtcSec détecte ce cas

Le contrôle DANGEROUS_LOGON_SCRIPTS d'EtcSec fournit une liste à examiner. Dans le commit 15fc6399c215eabc415c370b762303cfcd7a353a d'etc-collector, dangerous-logon-scripts.go:46 parcourt les utilisateurs fournis et sélectionne un ScriptPath non vide s'il contient deux barres obliques inverses consécutives n'importe où, ou commence par //. La branche des barres obliques inverses n'exige pas un préfixe UNC strict. Le constat est de niveau Medium, et Count correspond au nombre d'utilisateurs correspondants, pas au nombre de fichiers distincts ni de partages vulnérables.

Il n'y a pas de filtre Disabled dans cette méthode Detect(). Des utilisateurs désactivés peuvent donc apparaître lorsqu'ils sont fournis dans les données d'audit. Un chemin vide ne correspond pas ; les chemins relatifs et les autres chaînes hors du prédicat peuvent échapper à cette liste de revue. À l'inverse, une chaîne correspondante ne démontre pas une cible UNC valide et accessible.

Le fournisseur LDAP demande scriptPath dans parser.go:49, le copie dans ScriptPath à parser.go:171 et récupère les utilisateurs via client.go:460. Ce contrôle ne lit ni le fichier cible, ni l'ACL du partage, ni l'ACL NTFS et ne vérifie pas l'exécution effective. Sa sortie ne peut pas confirmer un accès en écriture non autorisé, une persistance réussie ou une exécution SYSTEM. Le périmètre et l'exhaustivité de la collecte limitent également ce que représente cette liste.