Attaquer la délégation contrainte pour élever l'accès

Cet article complète une série d'articles sur la Kerberos delegation. Avant de le lire, nous vous suggérons de vous assurer que vous êtes familier avec la Active Directory delegation et la Kerberos delegation, et d'avoir lu les précédents articles de la série qui fournissent un aperçu de la manière dont la resource-based constrained delegation et la unconstrained delegation sont configurées et comment elles peuvent être détournées.

Cet article explique comment une attaque de constrained delegation permet à un adversaire d'obtenir un accès élevé à des services vitaux.

Délégation restreinte

La délégation restreinte permet aux administrateurs de configurer à quels services un compte d'utilisateur ou d'ordinateur Active Directory peut déléguer et quels protocoles d'authentification peuvent être utilisés. Elle est configurée dans l'onglet Délégation de l'objet AD :

Lorsque la délégation restreinte est configurée sur un compte, deux actions se produisent en arrière-plan :

• L'attribut userAccountControl de l'objet est mis à jour avec le drapeau « TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION ».
• L'attribut msDS-AllowedToDelegateTo est renseigné avec le SPN spécifié.

Attaque de délégation restreinte

En théorie, la délégation restreinte limite les dommages qui pourraient résulter si un compte AD est compromis. Mais la délégation restreinte peut être détournée : un adversaire qui compromet le mot de passe en clair ou le hachage de mot de passe d'un compte configuré avec délégation restreinte à un service peut ensuite se faire passer pour n'importe quel utilisateur dans l'environnement pour accéder à ce service. Par exemple, si la délégation restreinte est configurée pour un SPN Microsoft SQL, un attaquant pourrait obtenir un accès privilégié à cette base de données.

Comment se déroule une attaque

Supposons ce qui suit :

• Nous avons gagné un point d'appui dans un environnement informatique.
• Nous avons compromis un compte avec des privilèges d'administrateur local sur un poste de travail.
• Nous avons utilisé Mimikatz pour obtenir un hash de mot de passe laissé en mémoire après une connexion, et le compte associé (le compte ‘notadmin’) a une délégation restreinte configurée.

Ainsi, tout ce que nous avons jusqu'à présent est l'accès à la machine unique sur laquelle nous avons atterri et le hash du mot de passe d'un compte configuré pour une délégation restreinte.

Étape 1. Reconnaissance

Pour exploiter la délégation contrainte, nous avons besoin de trois choses clés :

• Un compte compromis configuré avec une délégation restreinte
• Un compte privilégié cible à usurper lors de la demande d'accès au service
• Informations sur la machine hébergeant le service auquel nous allons accéder

Nous avons le premier, alors allons chercher les deux autres.

1.1 : Tout d'abord, voyons pour quoi est configurée la délégation restreinte du compte 'notadmin' :

1.2 : Nous savons maintenant que la délégation restreinte est configurée pour le SPN CIFS et LDAP sur l'hôte SBPMLAB-DC2. Alors comprenons exactement ce qu'est l'hôte SBPMLAB-DC2 (même si le nom le suggère quelque peu !). Peut-être que l'appartenance à un groupe de l'ordinateur nous dira quelque chose.

1.3 : Nous avons de la chance : La machine à laquelle cet utilisateur peut déléguer l'accès est un contrôleur de domaine (DC). Maintenant, trouvons un bon utilisateur à usurper lors de l'accès à ce service. La commande PowerShell suivante va énumérer les membres du groupe des Domain Admins :

Get-ADGroup ‘Domain Admins’ | Get-ADGroupMember

Nous pouvons voir que le compte ‘KevinJ’ est membre des Domain Admins, donc maintenant nous avons tous les éléments nécessaires pour exploiter la délégation restreinte.

Étape 2. Obtenir l'accès

En utilisant un outil comme Kekeo, nous pouvons demander le ticket granting ticket (TGT) pour le compte avec délégation restreinte configurée, exécuter la demande de service de ticket granting pour le compte que nous voulons usurper, et ensuite accéder au service cible.

Gardez à l'esprit que nous n'avons pas encore accès au partage administratif C$ sur l'hôte cible :

2.1. En utilisant Kekeo, nous demandons le TGT pour le compte ‘notadmin’ en utilisant son hash de mot de passe :

2.2. Maintenant que nous avons le TGT, nous exécutons la demande TGS pour le compte que nous souhaitons usurper pour le service cible auquel le compte ‘notadmin’ est contraint :

2.3. Revenant à Mimikatz, nous pouvons utiliser Pass the Ticket pour accéder au service CIFS sur l'hôte cible :

Comme vous pouvez le voir, après l'importation du ticket, nous pouvons naviguer vers le partage administratif C$ sur le contrôleur de domaine. Cela signifie que nous pourrions potentiellement voler une copie du fichier NTDS.dit et essayer de craquer les mots de passe des utilisateurs hors ligne.

Protection contre les attaques basées sur la délégation

Une technique critique pour se défendre contre les attaques liées à la délégation consiste à placer les comptes sensibles qui ne devraient pas être délégués dans le groupe des Utilisateurs Protégés, ou à cocher la case ‘Le compte est sensible et ne peut pas être délégué’ dans Active Directory Users and Computers sur l'onglet Compte :

Pour une protection plus large, envisagez la Netwrix Active Directory Security Solution. Elle offre des rapports complets qui fournissent une vision claire des configurations de délégations non restreintes et restreintes, ainsi que des comptes de service spécifiques qui sont restreints. En utilisant ces informations, vous pouvez réduire les risques et sécuriser votre environnement plus efficacement. De plus, vous pouvez facilement détecter et automatiser votre réponse aux menaces sophistiquées et atténuer leur impact.

FAQ

Qu'est-ce qu'une attaque par délégation restreinte ?

Une attaque par délégation restreinte est un type de cyberattaque dans laquelle un adversaire obtient un accès non autorisé à un système ou service cible en exploitant les permissions accordées à un compte de service. En compromettant le compte de service ou en interceptant et manipulant le trafic Kerberos entre les services, l'attaquant peut se faire passer pour un utilisateur et obtenir un accès non autorisé à d'autres services auxquels le compte de service a le droit d'accéder. Ce type d'attaque peut être plus difficile à exécuter qu'une attaque par délégation non restreinte, mais c'est toujours une menace sérieuse pour la sécurité du réseau.

Qu'est-ce que la délégation contrainte et non contrainte ?

La délégation limitée et la délégation non limitée sont deux manières dont le protocole d'authentification Kerberos peut être configuré pour permettre à un service d'usurper l'identité d'un utilisateur afin d'accéder à d'autres services. La délégation non limitée permet à un service d'usurper l'identité d'un utilisateur pour accéder à n'importe quel autre service au sein d'un domaine Active Directory. La délégation limitée, d'autre part, limite la portée de la délégation en spécifiant quels services un service peut accéder au nom d'un utilisateur.

Qu'est-ce que cela signifie une délégation sans contrainte ?

La délégation sans restriction est une configuration de délégation Kerberos qui permet à un service d'usurper l'identité d'un utilisateur pour accéder à tout autre service au sein d'un domaine Active Directory. Ce type de délégation peut être exploité par des attaquants pour se déplacer latéralement dans un réseau et accéder à des données ou systèmes sensibles.

Pourquoi la délégation sans contrainte est-elle mauvaise ?

La délégation sans contrainte est considérée comme mauvaise car elle peut permettre aux attaquants de se déplacer latéralement dans un réseau et d'accéder à des données ou systèmes sensibles. Il est recommandé d'utiliser la délégation contrainte à la place, ce qui limite la portée de la délégation et réduit le risque d'attaques réussies.