La surface d'attaque des objets ordinateur Active Directory est le terme collectif désignant les risques de délégation, de droits de réplication et d'appartenance à des groupes que portent couramment les comptes machine — des comptes qu'Active Directory crée automatiquement pour chaque machine jointe au domaine, et qu'il audite rarement comme il audite les comptes utilisateur. Contrairement aux comptes utilisateur, les comptes machine bénéficient rarement d'une attention individuelle : personne ne revoit leurs paramètres de délégation, leurs appartenances à des groupes, ou leur niveau de correctifs comme on le ferait pour un utilisateur privilégié. C'est précisément cet angle mort qu'exploitent plusieurs techniques d'attaque bien établies.
Cet article traite spécifiquement de la surface d'attaque des objets ordinateur — à distinguer de Délégation Kerberos : Non Contrainte à RBCD, qui explique les mécanismes de délégation eux-mêmes, et de Abus ACL et DCSync : Les Chemins Silencieux vers Domain Admin, qui couvre l'escalade par ACL de façon générale. Ici, le sujet est plus restreint : quels objets ordinateur de votre domaine portent des droits dangereux, et pourquoi c'est si facile à manquer.
Qu'est-ce que la surface d'attaque des objets ordinateur Active Directory ?
Chaque machine Windows jointe au domaine obtient un compte ordinateur dans Active Directory — un principal de sécurité à part entière, avec son propre SID, ses propres identifiants Kerberos (renouvelés automatiquement, généralement tous les 30 jours), et la capacité de porter des appartenances à des groupes et des droits de délégation, exactement comme un compte utilisateur. C'est précisément le principe : les services qui s'exécutent en tant que SYSTEM sur une machine jointe au domaine s'authentifient auprès du reste du domaine en tant que ce compte ordinateur.
Le risque découle directement de cette conception. Un compte ordinateur peut se voir accorder — délibérément ou par dérive — les mêmes catégories de droits dangereux qu'un compte utilisateur : une délégation qui lui permet d'usurper d'autres utilisateurs, des droits de réplication qui permettent DCSync, ou une appartenance à un groupe privilégié. La différence tient à la visibilité : les équipes sécurité vérifient régulièrement quels utilisateurs sont Domain Admins, mais demandent rarement quels ordinateurs peuvent agir comme tel.
Pourquoi les objets ordinateur passent entre les mailles du filet
Les workflows de provisionnement créent des objets ordinateur automatiquement, souvent via l'imagerie, l'enrôlement Autopilot, ou un déploiement SCCM/Intune — sans revue humaine des droits de l'objet résultant au moment de sa création. Des chemins d'attaque comme ceux couverts dans Chemins d'Attaque AD : Mauvaises Configurations en Chaîne enchaînent précisément ce type de droit non revu avec d'autres mauvaises configurations pour atteindre Domain Admin ; les objets ordinateur sont un maillon disproportionnellement fréquent de cette chaîne, précisément parce qu'ils font rarement l'objet d'un cycle de revue dédié, contrairement aux comptes utilisateur privilégiés.
Délégation sans contrainte sur un objet ordinateur
Lorsqu'un compte ordinateur est configuré pour la délégation sans contrainte (le flag UserAccountControl TRUSTED_FOR_DELEGATION), tout utilisateur qui s'authentifie auprès d'un service sur cette machine voit son Ticket Granting Ticket (TGT) complet — pas seulement un ticket de service — mis en cache dans la mémoire de cette machine. Selon l'analyse largement citée du chercheur en sécurité Sean Metcalf sur ce risque, cela signifie qu'un seul hôte compromis en délégation sans contrainte peut accumuler les TGT de tous les utilisateurs qui s'y authentifient, y compris ceux des contrôleurs de domaine eux-mêmes lorsqu'ils sont incités à s'y connecter.
⚠️ Avertissement : la documentation BloodHound de SpecterOps indique qu'un attaquant qui compromet un hôte en délégation sans contrainte peut le combiner avec une technique de coercition d'authentification DC (comme PrinterBug ou PetitPotam) pour capturer le TGT propre d'un contrôleur de domaine — et à partir de là demander des tickets de service en tant que n'importe quel utilisateur, y compris les Domain Admins.
Pourquoi elle est encore présente
La délégation sans contrainte était le modèle de délégation original de Windows 2000 ; elle a été remplacée par la délégation contrainte et RBCD pour les cas d'usage légitimes, et les recommandations de Microsoft déconseillent elles-mêmes son utilisation. Son principal risque aujourd'hui est un héritage historique : des serveurs configurés ainsi il y a des années — souvent pour des serveurs d'impression, des déploiements web précoces, ou des outils d'administration ad hoc — et jamais revisités une fois la justification d'origine oubliée.
Abus de la délégation contrainte basée sur les ressources (RBCD)
La délégation contrainte basée sur les ressources (RBCD) fonctionne différemment des anciens modèles de délégation : au lieu d'être configurée sur le compte qui a besoin de déléguer, elle est configurée sur la ressource cible elle-même, via l'attribut msDS-AllowedToActOnBehalfOfOtherIdentity. Quiconque est listé dans cet attribut peut usurper des utilisateurs arbitraires auprès de cette ressource spécifique.
L'implication en matière de sécurité a été détaillée dans la recherche d'Elad Shamir en 2019, « Wagging the Dog: Abusing Resource-Based Constrained Delegation to Attack Active Directory ». La conclusion clé : tout principal disposant d'un accès en écriture sur l'attribut msDS-AllowedToActOnBehalfOfOtherIdentity d'un objet ordinateur peut configurer RBCD pour celui-ci — sans avoir besoin des privilèges de niveau domain admin qu'exigeaient les anciens modèles de délégation. Cela inclut un principal disposant uniquement des droits GenericAll, GenericWrite, ou WriteDacl/WriteProperty sur l'objet ordinateur cible. La recherche de Shamir a également montré que S4U2Self fonctionne sur tout compte disposant d'un SPN, indépendamment de son paramètre TrustedToAuthForDelegation, et que la réponse de Microsoft à l'époque était que ce n'était « pas un problème qui sera corrigé via une mise à jour de sécurité » — le potentiel d'abus de RBCD est une conséquence de sa conception, pas un bug corrigeable.
Pourquoi RBCD est un problème d'ACL, pas un problème de délégation
Cela fait de l'abus RBCD fondamentalement un problème d'ACL sur les objets ordinateur, pas un problème de configuration de délégation. Un compte ordinateur avec une autorisation ACL apparemment à faible risque, héritée d'un ancien projet ou du comportement par défaut d'un installeur, peut devenir une primitive d'usurpation complète. Ne revoir que la valeur de msDS-AllowedToActOnBehalfOfOtherIdentity elle-même passe à côté de l'exposition — le véritable point de contrôle est de savoir qui est autorisé à y écrire.
Droits DCSync détenus par un compte machine
DCSync abuse des droits étendus DS-Replication-Get-Changes et DS-Replication-Get-Changes-All, normalement réservés aux contrôleurs de domaine, pour extraire les hashes de mot de passe de n'importe quel compte via le protocole de réplication d'annuaire. Les comptes ordinateur des contrôleurs de domaine détiennent ces droits de façon légitime. Le risque traité ici est différent : un compte ordinateur non-DC auquel des droits permettant DCSync ont été accordés, délibérément ou par accident (par exemple via un template ACL trop permissif appliqué à la racine du domaine, ou des droits de réplication accordés à un compte de service de sauvegarde/supervision qui se trouve être lié à une machine).
La documentation BloodHound de SpecterOps décrit l'edge DCSync comme la combinaison de ces deux droits sur n'importe quel principal — utilisateur, groupe, ou ordinateur — et note qu'il peut aussi apparaître indirectement via des mauvaises configurations de délégation contrainte, sans que l'objet ne détienne jamais explicitement les droits de réplication.
Ordinateurs dans des groupes privilégiés
Un compte ordinateur ajouté à un groupe privilégié (Domain Admins, Enterprise Admins, ou un groupe Tier 0 personnalisé) accorde des droits équivalents à Domain Admin à tout ce qui s'exécute en tant que SYSTEM sur cette machine — ce qui, en pratique, signifie quiconque parvient à exécuter du code dessus. C'est un profil d'exposition différent de celui d'un compte utilisateur privilégié : une station de travail ou un serveur applicatif est généralement plus facile à compromettre qu'un poste d'administration durci, et son contexte SYSTEM est accessible à bien plus de chemins de code (tâches planifiées, services, comptes admin locaux) qu'une simple session utilisateur interactive.
C'est le même problème structurel que celui couvert dans Imbrication Dangereuse de Groupes AD : Chemins vers Domain Admin — une appartenance à un groupe qui paraît anodine isolément devient dangereuse dès que l'on retrace qui contrôle effectivement la machine qui la porte.
Systèmes d'exploitation obsolètes toujours présents dans le domaine
Les objets ordinateur exécutant des versions de Windows au-delà de leur cycle de support — Windows XP, Windows Server 2003, ou antérieur — ne reçoivent plus de mises à jour de sécurité de Microsoft, y compris pour des vulnérabilités activement exploitées. Un contrôleur de domaine ou un serveur membre sur un OS obsolète est un point faible permanent et non corrigeable ; et comme ces systèmes sont souvent maintenus en ligne pour une application legacy spécifique, ils ont tendance à être exclus des processus courants de gestion des correctifs et des vulnérabilités, plutôt que signalés comme l'exposition hautement prioritaire qu'ils représentent réellement.
Ces systèmes recoupent fréquemment le schéma décrit dans Comptes Obsolètes et Sur-Privilégiés dans AD : les deux sont des expositions qui persistent précisément parce que personne n'assume la décision de les retirer.
Détection
| Indicateur | Que vérifier | Notes |
|---|---|---|
| Délégation sans contrainte | Objets ordinateur avec TRUSTED_FOR_DELEGATION (bit userAccountControl 0x80000 / ADS_UF_TRUSTED_FOR_DELEGATION) actif | Signaler chaque occurrence ; cela doit être une exception explicite, pas un défaut |
| Configuration RBCD | msDS-AllowedToActOnBehalfOfOtherIdentity non vide sur des objets ordinateur | Recouper qui peut écrire cet attribut, pas seulement qui y figure actuellement |
| Droits permettant DCSync | DS-Replication-Get-Changes / DS-Replication-Get-Changes-All accordés à des principaux non-DC | Auditer à la racine du domaine et sur toute OU où des droits de réplication auraient pu être délégués |
| Appartenance à un groupe privilégié | Comptes ordinateur dans Domain Admins, Enterprise Admins, ou groupes Tier 0 | Toute occurrence mérite une investigation — les cas d'usage légitimes sont rares |
| OS obsolète | Attribut operatingSystem pour les versions au-delà du cycle de support Microsoft | Inclure explicitement les contrôleurs de domaine — ils ne sont pas exemptés |
💡 Astuce : BloodHound (SpecterOps) cartographie la délégation sans contrainte, RBCD, et les droits permettant DCSync comme des arêtes de graphe, ce qui permet de voir concrètement ces expositions comme des chemins d'attaque vers Domain Admin plutôt que comme des constats isolés sur des objets individuels.
Remédiation
1. Marquer les comptes sensibles comme non délégables
Activez le flag « Le compte est sensible et ne peut pas être délégué » sur les comptes à forte valeur, afin qu'ils ne puissent pas être capturés même par un hôte compromis en délégation sans contrainte.
2. Supprimer la délégation sans contrainte partout où c'est possible
Migrez les cas d'usage légitimes vers la délégation contrainte ou RBCD, qui limitent l'usurpation à des services cibles spécifiques.
3. Auditer chaque configuration RBCD — et les ACL qui permettent de la définir
Revoyez msDS-AllowedToActOnBehalfOfOtherIdentity sur tous les objets ordinateur, et — surtout — revoyez qui détient les droits GenericAll/GenericWrite/WriteDacl qui leur permettraient de la configurer en premier lieu.
4. Supprimer les droits permettant DCSync des principaux non-DC
Auditez les accords DS-Replication-Get-Changes / DS-Replication-Get-Changes-All à la racine du domaine et sur toute OU déléguée.
5. Retirer les comptes ordinateur des groupes privilégiés
Sauf raison spécifique, documentée et revue pour cette appartenance, traitez toute occurrence comme un constat à corriger, pas comme une configuration à tolérer indéfiniment.
6. Décommissionner ou isoler les systèmes à OS obsolète
Lorsque le décommissionnement n'est pas immédiatement possible, isolez le système sur le réseau et retirez tout droit privilégié ou appartenance à un groupe qu'il détient.
# Lister les objets ordinateur configurés en délégation sans contrainte
Get-ADComputer -Filter 'TrustedForDelegation -eq $true' -Properties TrustedForDelegation, OperatingSystem
# Lister les objets ordinateur avec une configuration RBCD définie
Get-ADComputer -Filter * -Properties msDS-AllowedToActOnBehalfOfOtherIdentity |
Where-Object { $_.'msDS-AllowedToActOnBehalfOfOtherIdentity' }
Comment EtcSec détecte cela
La catégorie Computers d'EtcSec couvre directement cette surface d'attaque : COMPUTER_UNCONSTRAINED_DELEGATION, COMPUTER_RBCD, COMPUTER_DCSYNC_RIGHTS, et COMPUTER_IN_ADMIN_GROUP signalent les risques de délégation, de droits de réplication et d'appartenance à des groupes décrits ci-dessus, tandis que COMPUTER_OS_OBSOLETE_XP et COMPUTER_OS_OBSOLETE_2003 signalent les systèmes d'exploitation en fin de support encore présents dans le domaine.
ℹ️ Note : EtcSec vérifie automatiquement chaque objet ordinateur du domaine pour ces conditions à chaque audit AD, en traitant les identités machine avec la même rigueur que les comptes utilisateur privilégiés. Lancez un audit gratuit pour voir quels objets ordinateur de votre environnement portent ces droits.
Références principales
- Elad Shamir : Wagging the Dog — Abusing Resource-Based Constrained Delegation to Attack Active Directory
- ADSecurity.org (Sean Metcalf) : Active Directory Security Risk #101 — Kerberos Unconstrained Delegation
- SpecterOps BloodHound Documentation : DCSync edge
- SpecterOps BloodHound Documentation : CoerceToTGT edge
- hackndo : Resource-Based Constrained Delegation — Risks
- Microsoft Learn : Making the second hop in PowerShell Remoting (contexte sur la délégation)
Explorez les pages identité liées à ce sujet