Compte de serveur (non) fiable

Persistance dans Active Directory par la manipulation de userAccountControl

J'ai récemment fait des recherches sur les comptes de service gérés par groupe (gMSAs) et j'ai consulté la spécification du protocole MS-SAMR pour obtenir des informations. Je suis tombé par hasard sur des informations intéressantes dans la section userAccountControl qui nous ont fait tout arrêter pour les tester :

Effectivement, lorsque le bit UF_SERVER_TRUST_ACCOUNT est défini dans l'attribut userAccountControl d'un objet ordinateur, alors Active Directory doit définir le primaryGroupId du même objet au RID du groupe Domain Controllers. Par conséquent, simplement changer userAccountControl peut accorder à un objet ordinateur les privilèges d'un contrôleur de domaine.

Enquêtant sur le comportement

Nous avons commencé les tests en utilisant un compte Domain Admin dans notre laboratoire, et avons d'abord tenté d'utiliser la valeur par défaut de userAccountControl pour un contrôleur de domaine de 0x82000 (décimal 532480), qui est la somme des indicateurs de bit pour SERVER_TRUST_ACCOUNT (0x2000, décimal 8192) et TRUSTED_FOR_DELEGATION (0x80000, décimal 524288).

Après avoir modifié la valeur de userAccountControl, nous constatons que le primaryGroupId est mis à jour à 516 (le RID pour le groupe des Contrôleurs de Domaine) et nous commençons très bien ! Ensuite, nous avons voulu savoir si seul le bit SERVER_TRUST_ACCOUNT est nécessaire, donc nous avons de nouveau tenté de définir l'attribut userAccountControl à 8192.

Nous avons donc confirmé l'exactitude de la spécification du protocole, et que c'est uniquement le bit SERVER_TRUST_ACCOUNT qui provoque le changement du primaryGroupId.

Recherche des privilèges requis

Nous commençons à envisager des vecteurs d'abus possibles. Si seule la capacité de modifier l'attribut userAccountControl est requise, alors nous pourrions être sur la piste d'une technique d'escalade de privilèges intéressante. Nous avons commencé les tests avec un compte non privilégié disposant uniquement des permissions pour modifier l'attribut userAccountControl et avons rapidement rencontré des erreurs d'accès refusé.

Il s'avère que nous aurions dû lire quelques lignes de plus dans la documentation MS-SAMR. La section 5 de l'attribut userAccountControl détaille les permissions supplémentaires requises pour configurer certains bits de userAccountControl. Afin de définir le bit UF_SERVER_TRUST_ACCOUNT de userAccountControl, l'acteur doit avoir la permission DS-Install-Replica (« Ajouter/supprimer une réplique dans le domaine ») accordée sur l'objet du domaine.

Nous avons accordé à notre utilisateur non privilégié cette permission et avons tenté notre test à nouveau.

Après avoir accordé le privilège d'écriture userAccountControl sur l'ordinateur et le privilège DS-Install-Replica sur l'objet de domaine à notre utilisateur non privilégié, notre test a été couronné de succès.

Par défaut, la permission DS-Install-Replica est accordée aux groupes « Domain Admins » et « Enterprise Admins ». Ainsi, sauf dans les environnements mal configurés, cette approche ne représente pas un vecteur d'élévation de privilèges. Cependant, étant donné les permissions limitées requises, nous avons commencé à réfléchir aux applications pour la persistance de domaine.

Applications pour la persistance de domaine

Pour évaluer si cela représente une méthode intéressante pour la persistance, nous avons pris en compte plusieurs facteurs : qu'un ensemble limité de privilèges est nécessaire, que ces privilèges ne sont pas souvent examinés, que les comptes (objectClass=computer) sont faciles à créer, que les ordinateurs sont rarement révisés (de nombreuses organisations ont du mal avec les objets informatiques obsolètes), et que l'exploitation du mécanisme est facile et les signes de courte durée.

Configurer ce mécanisme ne nécessite que quelques petites étapes :

1. Créez un faux compte d'ordinateur, MSA ou gMSA. Un compte existant peut également être utilisé, mais l'efficacité du mécanisme de persistance sera limitée par la fréquence des changements de mot de passe. Cependant, un compte d'ordinateur existant mais obsolète (plus utilisé) pourrait être une cible attrayante.
2. Accordez le privilège « Ajouter/supprimer une réplique dans le domaine » à un utilisateur régulier compromis, à un groupe ou à une entité bien connue. Nous avons utilisé « Utilisateurs authentifiés » afin qu'un adversaire puisse compromettre n'importe quel compte d'utilisateur régulier et reprendre la dominance du domaine.
3. Accordez le privilège « Write userAccountControl » sur l'objet ordinateur à la même entité que dans l'étape précédente.

Création d'un compte ordinateur avec un mot de passe connu

Il semble évident, mais tout le monde n'est peut-être pas familier avec la capacité de créer un compte d'ordinateur avec un mot de passe connu en utilisant les cmdlets New-ADComputer ou New-ADServiceAccount, par exemple :

New-ADComputer “ComputerName” -AccountPassword (ConvertTo-SecureString -AsPlainText -Force “Password”)

Connaître le mot de passe en clair est bénéfique pour plusieurs raisons. Plus important encore, nous pouvons calculer les hachages NTLM, AES-128 et AES-256 en utilisant les applets de commande ConvertTo-NTHash et ConvertTo-KerberosKey du module PowerShell DSInternals de Michael Grafnetter. Lorsque l'adversaire choisit d'exploiter la porte dérobée, il devra s'authentifier en tant que compte d'ordinateur pour utiliser ses privilèges et le fera avec la technique de contournement de hachage overpass-the-hash. Spécifier les hachages NTLM et AES permet d'éviter la plupart des détections de contournement de hachage overpass-the-hash.

Reconquérir la dominance du domaine

Après avoir préparé le compte et les permissions, si l'adversaire perd l'accès à ses identifiants administratifs ou est expulsé du réseau, il lui suffit de compromettre n'importe quel utilisateur ordinaire pour reprendre le contrôle du domaine.

Avec n'importe quel compte utilisateur, l'adversaire a seulement besoin de modifier l'attribut userAccountControl de leur ordinateur préparé à 0x2000 (8192). Cette modification provoque également une réplication immédiate, ce qui signifie que l'adversaire n'a pas besoin de cibler des contrôleurs de domaine spécifiques. Une fois le userAccountControl complété, l'adversaire peut utiliser ses privilèges de contrôleur de domaine pour compromettre le domaine.

Par exemple, l'adversaire pourrait utiliser le compte d'ordinateur pour effectuer un DCSync et compromettre le hachage du mot de passe krbtgt. Comme la réplication semble provenir d'un contrôleur de domaine, la plupart des détections de menaces DCSync ne détectent pas l'activité. Une fois qu'ils ont répliqué le secret krbtgt, ils peuvent simplement remettre userAccountControl à 0x1000 (4096) et le compte d'ordinateur apparaîtra comme un compte d'ordinateur normal.

Automatiser la technique

Pour aider à démontrer l'efficacité potentielle de cette méthode, j'ai créé deux nouvelles fonctions PowerShell qui sont available on GitHub.

La première fonction, Add-ServerUntrustAccount, automatise les trois étapes de configuration – la création d'un faux compte d'ordinateur avec un mot de passe connu et l'octroi aux « Utilisateurs authentifiés » des privilèges « Ajouter/retirer une réplique dans le domaine » et « Écrire userAccountControl ».

La deuxième fonction, Invoke-ServerUntrustAccount, automatise l'exploitation de la porte dérobée et est destinée à être exécutée par un utilisateur non privilégié. La fonction définit l'attribut userAccountControl à 0x2000 (8192), puis utilise la technique de pass-the-hash pour s'authentifier en tant que faux compte d'ordinateur, effectue un DCSync des hachages krbtgt, et enfin remet userAccountControl à 0x1000 (4096).

Découverte de mécanismes et détection d'exploitation

Pour trouver ce mécanisme et d'autres similaires, les organisations devraient auditer périodiquement les permissions sensibles d'Active Directory. Surveiller (ou même bloquer) les changements de permissions sensibles (comme l'ajout/suppression de réplique dans le domaine) en temps réel est également bénéfique. Nous avons testé plusieurs outils open-source populaires d'audit de permissions Active Directory, et seul AD ACL Scanner a correctement mis en évidence les permissions problématiques de notre adversaire.

Les journaux d'événements Active Directory – à savoir les identifiants d'événement 5136 et 4662 – permettent une surveillance de base en temps réel des modifications des listes de contrôle d'accès et peuvent être utilisés pour détecter le privilège de niveau domaine « Ajouter/supprimer une réplique dans le domaine ». Cependant, le processus d'analyse de ces événements n'est pas simple.

De plus, il est important de trouver et de supprimer les comptes d'ordinateur (ainsi que les comptes MSA et gMSA) obsolètes, ou qui ne correspondent pas à une machine réelle sur le réseau. Par exemple, vous pouvez rapidement trouver des comptes d'ordinateur inactifs ou non utilisés avec PowerShell (en remplaçant « -90 » par l'âge maximum de compte d'ordinateur de votre domaine) :

$Date = [DateTime]::Today.AddDays(-90); Get-ADComputer -Filter ‘(Enabled -eq $true) -and (PasswordLastSet -le $Date)’ | Select Name

Détection de l'exploitation

La détection de l'utilisation de cette technique par un adversaire repose sur la surveillance des modifications de l'attribut userAccountControl. L'identifiant d'événement 4742 – Computer Account Management peut être utilisé pour surveiller les changements de valeurs de userAccountControl. Toute modification de userAccountControl avec le bit 0x2000 défini en dehors d'une promotion de contrôleur de domaine attendue est préoccupante.

Conclusion

Bien que manifestement pas aussi grave qu'une vulnérabilité critique, ces types de techniques passent souvent inaperçues dans les entreprises et peuvent rendre le travail d'un intervenant en cas d'incident encore plus difficile. Étant donné le faible taux de détection dans les outils d'audit d'Active Directory que nous avons testés, nous pensons qu'il s'agit d'une technique intéressante qui abuse d'un comportement peu connu qui pourrait facilement être manqué. Nous accueillons vos commentaires et questions, et nous manquerions à nos devoirs si nous ne vous dirigions pas vers notre Attack Catalog, où vous pouvez en apprendre davantage sur le fonctionnement de certaines attaques.