ACL des objets ordinateur Active Directory : revue des DACL

Que sont les abus des ACL des objets ordinateur dans Active Directory ?

Les revues des abus des ACL des objets ordinateur dans Active Directory cherchent à déterminer qui peut modifier l’objet d’annuaire d’une identité machine. GenericAll, WriteDACL et WriteOwner peuvent ouvrir des chemins vers la délégation contrainte basée sur les ressources (RBCD), des informations d’identification par clé non autorisées ou une réinitialisation du mot de passe machine. Identifier une autorisation dangereuse établit une exposition ; prouver son exploitation exige des preuves de modification et d’authentification.

L’introduction à la surface d’attaque des objets ordinateur explique déjà le chemin d’ACL vers la RBCD, ainsi que la délégation, les droits de réplication et l’appartenance à des groupes privilégiés. Ce guide prolonge cette base par une revue opérationnelle : inspecter la DACL et le propriétaire, distinguer trois chemins d’abus, recueillir les preuves de modification de l’annuaire et corriger à la fois le chemin de permissions et toute configuration non autorisée.

La revue porte sur les droits sur un objet ordinateur. Un compte machine détenant des privilèges ailleurs correspond à une autre relation. Consignez le DN et le GUID de l’objet contrôlé, le principal bénéficiaire de l’autorisation, sa portée et l’objectif administratif attendu avant de décider quoi supprimer.

Fonctionnement : examiner la DACL et le propriétaire

Une liste de contrôle d’accès discrétionnaire (DACL) contient des entrées de contrôle d’accès (ACE). Chaque entrée identifie un principal et des droits ; les entrées spécifiques à un objet peuvent limiter la propriété, le droit étendu ou la classe d’objet qui hérite. Lire uniquement le nom affiché d’une permission ne permet pas de saisir cette portée. L’énumération des droits d’accès AD de Microsoft définit ces champs ainsi que les droits WriteDACL et WriteOwner.

GenericAll ne se réduit pas à un bit brut à rechercher. Le mappage des droits d’accès MS-ADTS convertit les droits génériques en droits spécifiques lors de l’enregistrement d’un descripteur de sécurité. Un audit qui recherche uniquement 0x10000000 peut manquer le contrôle total après mappage. Interprétez les droits obtenus avec le type d’ACE, la portée des propriétés et l’héritage.

La propriété nécessite son propre contrôle. Microsoft documente le blocage des droits implicites du propriétaire sur les objets ordinateur, avec des conditions liées au système d’exploitation et à BlockOwnerImplicitRights. Ne supposez pas que devenir propriétaire ouvre toujours un chemin d’écriture sans restriction sur la DACL. Vérifiez les droits effectifs sur la configuration réelle du DC. De même, supprimer une ACE de contrôle total évidente ne prouve pas que la situation est saine si un propriétaire inattendu ou une autre autorisation applicable subsiste.

Pourquoi les objets ordinateur nécessitent une revue dédiée des ACL

Un inventaire de délégation indique quelles machines acceptent actuellement des identités déléguées. Une revue des ACL cherche qui pourrait modifier cette réponse demain. Un attribut RBCD vide ne clôt donc pas un constat concernant un principal capable d’y écrire. La même distinction vaut pour les informations d’identification par clé : inventoriez les valeurs enregistrées et la capacité à en ajouter.

Partez du contexte métier plutôt que d’une interdiction générale de l’administration. Un service de déploiement peut avoir besoin de droits particuliers de provisionnement ; cela ne justifie pas un contrôle total permanent sur chaque objet serveur. Demandez au responsable de préciser l’opération, les objets concernés, le principal approuvé et la date d’expiration ou de revue. Comparez ce besoin à l’ACE réelle.

Les permissions directes et héritées nécessitent des corrections différentes. Si une autorisation indésirable provient d’une OU parente, modifier un seul ordinateur laisse les autres bénéficiaires exposés. Retrouvez la source de l’héritage et inspectez la portée par classe d’objet avant de la modifier. Associez les responsables administratifs de l’OU et de ses charges de travail afin que la délégation de remplacement permette la tâche légitime.

Chaîne d’attaque : trois chemins à partir du contrôle de l’objet

1. Configuration RBCD

Un attaquant disposant d’un accès effectif en écriture à msDS-AllowedToActOnBehalfOfOtherIdentity peut tenter d’insérer une identité de service qu’il contrôle dans la configuration de délégation de la ressource. WriteDACL peut constituer une étape préalable permettant d’accorder le droit d’écriture nécessaire. La référence de schéma Microsoft décrit cet attribut comme le contrôle d’accès permettant d’agir au nom d’autres identités auprès des services exécutés sous ce compte.

La présentation Microsoft de la délégation contrainte explique l’autorisation côté ressource et l’échange de tickets de service S4U2Proxy. La conséquence est un accès par les services éligibles sur la ressource cible, sous réserve de l’environnement et des autorisations du service. Cela ne garantit pas automatiquement les droits d’administrateur local ou de Domain Admin. Examinez les services de destination et les privilèges de l’identité usurpée pour évaluer l’impact.

2. Informations d’identification fantômes

Une clé publique non autorisée dans msDS-KeyCredentialLink peut créer une voie d’authentification distincte par clé lorsque l’environnement prend en charge le flux de confiance de clé concerné et que l’attaquant détient la clé privée correspondante. MS-PKCA Key Trust exige que les implémentations adossées à AD confirment la présence de la même clé publique dans l’attribut du compte.

Distinguez l’accès étendu en écriture aux attributs des écritures validées. Ces dernières imposent des vérifications supplémentaires au-delà du schéma de l’attribut. La spécification des écritures validées pour les ordinateurs exige SELF, le droit d’écriture validée pertinent et des contraintes précises sur le blob pour ajouter une valeur, notamment l’absence de valeur existante. Ces conditions ne signifient pas que tout tiers disposant d’une écriture validée puisse installer une clé.

L’authentification par clé publique des appareils joints au domaine explique aussi le provisionnement légitime des clés d’ordinateur. Un attribut renseigné constitue une donnée de triage, pas un verdict de compromission. Le guide des informations d’identification fantômes développe cette distinction et explique pourquoi une remédiation limitée au mot de passe peut laisser subsister une voie par clé non autorisée.

3. Réinitialisation du mot de passe machine

Le contrôle total peut inclure le droit étendu Reset Password. L’entrée de schéma Reset Password de Microsoft cite explicitement Computer parmi les classes concernées. Une réinitialisation non autorisée peut donner à un attaquant le contrôle de l’information d’identification par mot de passe du compte, avec un impact dépendant des privilèges de ce compte et des voies d’authentification disponibles.

Elle peut aussi perturber la relation d’approbation de la machine. La documentation Microsoft de dépannage du canal sécurisé décrit les divergences de mot de passe entre l’appareil et AD. Traitez une réinitialisation inexpliquée comme un incident d’identité et un problème de disponibilité. Coordonnez la récupération avec le responsable du système ; une modification unilatérale du mot de passe côté annuaire n’est pas une expérience de diagnostic sûre.

Énumération : une commande de lecture, puis la revue des droits effectifs

Sur un système Windows d’administration où dsacls est disponible, ouvrez une invite de commandes avec élévation ou une session PowerShell et remplacez le DN de l’ordinateur par celui que vous avez vérifié dans cette unique commande de lecture :

dsacls "CN=APP01,OU=Servers,DC=example,DC=com" /A

La référence dsacls de Microsoft documente l’affichage des ACL et l’option /A pour les informations de propriétaire et d’audit. Utilisez un compte autorisé à lire la DACL, le propriétaire et les informations d’audit ; l’accès ordinaire READ_CONTROL exclut la SACL. Cet exemple n’a pas été exécuté dans un environnement AD.

Résolvez chaque principal inattendu vers une identité actuelle. Consignez les autorisations héritées et explicites, les groupes applicables, la portée des propriétés et le propriétaire. Confirmez les permissions effectives avec les outils de sécurité de l’annuaire plutôt que de traiter chaque entrée d’autorisation comme une attaque indépendante immédiatement exploitable. Examinez les identités non résolues et expliquez les exceptions administratives approuvées dans le compte rendu.

Donnez la priorité aux serveurs sensibles et aux OU qui délèguent leur contrôle, puis étendez la revue à tous les objets ordinateur. Conservez l’état initial afin qu’une modification ultérieure puisse être évaluée sur le même objet et avec la même portée de permissions.

Détection : Event ID 5136 et KQL

La référence Microsoft de l’Event ID 5136 confirme l’audit des modifications d’objets d’annuaire. Activez l’audit des réussites pour Audit Directory Service Changes sur les DC et les entrées SACL d’audit d’écriture appropriées sur les objets ou attributs surveillés. Microsoft indique que les paramètres de schéma peuvent supprimer l’audit pour certains objets et propriétés : validez donc la couverture réelle. Conservez les champs de corrélation de l’acteur, de l’objet, de l’attribut et de l’opération. La suppression et l’ajout d’une valeur peuvent faire partie d’une seule modification ; ne les comptez pas comme deux incidents distincts.

Le KQL suivant est une requête de départ non exécutée pour un espace de travail recevant les événements Security des DC dans WindowsEvent. Il suppose des propriétés nommées dans EventData. Le schéma de la table WindowsEvent de Microsoft définit ce champ comme dynamique et précise que les échecs d’analyse alimentent RawEventData à la place. Inspectez des enregistrements représentatifs avant de vous fier à ce mappage.

WindowsEvent
| where TimeGenerated > ago(7d)
| where Channel == "Security" and EventID == 5136
| extend ObjectClass = tostring(EventData.ObjectClass),
         ObjectDN = tostring(EventData.ObjectDN),
         AttributeName = tostring(EventData.AttributeLDAPDisplayName),
         ActorSID = tostring(EventData.SubjectUserSid),
         ActorName = tostring(EventData.SubjectUserName),
         Operation = tostring(EventData.OperationType),
         OperationCorrelation = tostring(EventData.OpCorrelationID)
| where ObjectClass =~ "computer"
| where AttributeName in~ ("msDS-AllowedToActOnBehalfOfOtherIdentity",
                          "msDS-KeyCredentialLink", "nTSecurityDescriptor")
| project TimeGenerated, Computer, ObjectDN, AttributeName,
          ActorSID, ActorName, Operation, OperationCorrelation
| order by TimeGenerated desc

Vérifiez séparément les événements 5136 dont EventData est vide ou présente une autre structure ; sinon, les lacunes d’analyse deviennent invisibles. Adaptez la requête si le connecteur utilise SecurityEvent ou une autre table. Validez la couverture des SACL et la visibilité des modifications du descripteur de sécurité par une modification administrative contrôlée avant d’affirmer que la couverture est assurée. La requête identifie des modifications candidates, pas une preuve d’abus.

Pour le chemin de réinitialisation, complétez la revue des changements d’annuaire par l’Event ID 4742, sous Audit Computer Account Management. Son champ Password Last Set peut refléter une réinitialisation manuelle ou une rotation normale du mot de passe machine. Microsoft documente aussi des modifications de DACL produisant des champs d’attributs modifiés vides. Une liste de champs vide ne prouve donc pas qu’aucun changement pertinent n’a eu lieu.

Effectuez le triage en comparant les modifications aux changements approuvés de déploiement, d’enrôlement et de délégation. Préservez la configuration précédente lorsqu’elle est disponible, identifiez le compte à l’origine de l’opération et examinez l’activité ultérieure de la machine concernée. Augmentez la priorité lorsqu’un acteur non approuvé modifie un serveur sensible, qu’un propriétaire change de manière inattendue ou qu’une modification de permissions précède un ajout de délégation ou de clé. L’absence de données d’audit exige une investigation de la collecte ; elle ne peut pas établir l’absence d’exploitation.

Remédiation (Remediation) : supprimer le chemin de permissions et récupérer l’identité

Étape 1 : préserver les preuves et restreindre la délégation

Capturez la DACL, le propriétaire, la source de l’héritage et les valeurs d’attributs pertinentes avant de les modifier. Supprimez les autorisations non autorisées de contrôle total, d’écriture sur la DACL et de prise de possession. Remplacez les accès de provisionnement nécessaires par des droits limités à l’opération et à la classe d’objet documentées. Corrigez une autorisation héritée à sa source et examinez les autres ordinateurs concernés.

Si vous confirmez qu’un principal précis ne doit conserver aucune ACE sur cet objet, dsacls /R fournit une opération de suppression documentée :

dsacls "CN=APP01,OU=Servers,DC=example,DC=com" /R "EXAMPLE\RetiredProvisioning"

/R supprime toutes les ACE de ce principal ; il ne s’agit pas d’un nettoyage sélectif du contrôle total. Pour un principal qui conserve des droits légitimes, modifiez plutôt l’ACE fautive précise. Confirmez ensuite le propriétaire et les droits effectifs obtenus. Cet exemple fondé sur la documentation n’a pas été exécuté.

Étape 2 : supprimer les délégations et les clés non autorisées

Rapprochez les délégataires RBCD de la liste approuvée par le responsable de la ressource. Set-ADComputer expose PrincipalsAllowedToDelegateToAccount ; utilisez l’ensemble attendu et vérifié en préservant les dépendances applicatives légitimes. Supprimer un délégataire non autorisé sans corriger les permissions du principal qui écrit laisse la configuration susceptible d’être recréée.

Pour une clé confirmée comme non autorisée, la même cmdlet permet de supprimer une valeur exacte d’attribut LDAP :

Set-ADComputer -Identity "APP01" -Remove @{ 'msDS-KeyCredentialLink' = $ConfirmedUnauthorizedValue }

$ConfirmedUnauthorizedValue doit contenir la valeur exacte qui a été préservée et examinée. Il s’agit d’un exemple de syntaxe fondé sur la documentation, pas d’une récupération exécutée. Préservez les clés d’appareil approuvées, documentez la validation de chaque valeur restante et testez l’authentification légitime après le nettoyage.

Étape 3 : rétablir la relation d’approbation et vérifier la clôture

Si les informations d’identification machine ont été compromises, coordonnez leur récupération avec le responsable de l’appareil et examinez les accès en aval. Sur un membre du domaine, la cmdlet Microsoft de canal sécurisé fournit cette commande de vérification :

Test-ComputerSecureChannel -Verbose

Exécutez-la localement dans PowerShell ouvert avec l’option Exécuter en tant qu’administrateur sur le membre du domaine concerné. Cette commande de vérification fondée sur la documentation n’a pas été exécutée. Microsoft avertit qu’elle produit des erreurs faux positifs sur les contrôleurs de domaine ; suivez les procédures propres aux DC dans ce cas. Un canal sécurisé fonctionnel vérifie cette relation, pas la suppression de toutes les valeurs d’annuaire contrôlées par un attaquant.

Ne clôturez le constat qu’après avoir examiné les permissions et le propriétaire obtenus, rapproché les délégations et les clés des valeurs approuvées, vérifié le fonctionnement attendu des services et confirmé que la surveillance reçoit les modifications prévues. Attribuez un responsable et une date de revue à chaque exception conservée.

Comment EtcSec détecte ce problème

L’implémentation d’etc-collector fournit deux vues du catalogue pour cette revue des permissions des objets ordinateur :

• COMPUTER_ACL_GENERICALL inspecte les ACE d’autorisation sur les objets ordinateur à la recherche de GenericAll brut ou du contrôle total AD après mappage, en excluant les principaux administratifs intégrés. Elle associe les DN des ordinateurs lorsque l’inventaire est disponible et utilise une heuristique de localisation moins précise lorsqu’il est absent.
• COMPUTER_ACL_ABUSE signale les ordinateurs portant l’indicateur DangerousACL. Le moteur d’audit déduit cet indicateur des autorisations GenericAll, WriteDACL ou WriteOwner sur les objets ordinateur, en excluant le compte lui-même et les principaux privilégiés attendus.

Considérez-les comme un même contrôle éditorial avec chevauchement : une vue spécifique du contrôle total et une vue agrégée des droits dangereux. Leurs filtres de principaux diffèrent ; ne promettez donc pas des ensembles de constats identiques et n’additionnez pas leurs nombres pour obtenir un total d’expositions indépendantes. Les deux signalent une exposition de configuration ; aucun n’établit qu’une RBCD, une clé malveillante ou une réinitialisation de mot de passe a été exploitée avec succès. Utilisez les objets concernés pour commencer la revue des DACL et corréler les résultats avec les preuves de modification.