Introduction aux données de réplication de l’Active Directory
Au sein d’un domaine Active Directory se trouvent généralement plusieurs contrôleurs de domaine qui nécessitent de disposer des mêmes informations. Pour parvenir à cela, l’Active Directory dispose d’un mécanisme de réplication qui permet, entre autres, de propager un changement depuis un contrôleur de domaine vers les autres.
Dans son processus de réplication, l’Active Directory utilise des USN (Update Sequence Number) pour déterminer l’état des contrôleurs de domaines. Ces USN représentent un compteur stocké dans la base de données de l’Active Directory, qui est incrémenté à chaque changement de cette base au niveau d’un contrôleur de domaine. Chaque contrôleur de domaine dispose alors d’un USN qui lui est propre.
Lorsqu’un changement d’une information de l’Active Directory intervient sur un contrôleur de domaine, deux cas peuvent se présenter :
- L’information modifiée n’est pas une information répliquée entre les différents contrôleurs de domaines. C’est le cas de l’ensemble des attributs de l’Active Directory qui disposent du flag FLAG_ATTR_NOT_REPLICATED[1] comme par exemple l’attribut « BadPwdCount » qui tient compte du nombre de tentatives de connexion échouées :
Dans ce cas, le contrôleur de domaine effectue la modification dans sa propre base de données, mais ne transmet rien aux autres contrôleurs de domaine. -
L’information modifiée nécessite une réplication entre les différents contrôleurs de domaines. Dans ce cas, le contrôleur de domaine qui a reçu le changement utilise le modèle de réplication de l’Active Directory pour transmettre le changement aux autres contrôleurs du domaine. Ce modèle de réplication ne sera pas détaillé dans cet article, mais permet la diffusion des évolutions à l’ensemble des contrôleurs d’un domaine en limitant le trafic nécessaire et en assurant la gestion des collisions (en cas de changement d’un même attribut sur différents contrôleurs sur une fenêtre de temps réduite).
Le processus de réplication utilise des métadonnées qui sont conservées sous la forme de deux attributs distincts : msDS-ReplAttributeMetaData[2] et msDS-ReplValueMetaData[3]. msDS-ReplAttributeMetaData est utilisé pour les changements effectués sur les attributs non linkés de l’Active Directory alors que msDS-ReplValueMetaData est réservé aux attributs linkés.
Les attributs linkés ont été introduits dans l’Active Directory à partir du niveau fonctionnel Windows Server 2003. Ce sont en fait des paires d’attributs dont la valeur de l’un est basée sur celle de l’autre. C’est par exemple le cas des attributs member d’un groupe et memberof de l’utilisateur.
Quel intérêt pour l’investigation ?
En tant qu’analyste forensic qui intervient suite à un incident de sécurité, le premier réflexe pour permettre d’identifier les actions malveillantes ayant eu lieu au sein d’un Active Directory est l’utilisation des journaux d’événements. Mais que faire si ceux-ci n’étaient pas activés au moment de l’attaque ? Ou si l’attaquant est parvenu à supprimer les journaux générés par ses actions, comme le permet un outil comme mimikatz[4] ?
Dans de telles situations, il est possible d’utiliser les données de réplication pour obtenir une vision partielle des actions des attaquants. En effet, d’après le fonctionnement des données de réplication, toute modification d’un attribut de l’Active Directory aboutit à la création d’une donnée de réplication contenant différentes informations pouvant être utile pour une investigation.
Dans le cas d’un attribut non linké, et donc d’une métadonnée de type msDS-ReplAttributeMetaData, les informations stockées sont la version, qui correspond au nombre de changements de l’attribut depuis sa création, la date à laquelle a été effectuée la modification, l’USN correspondant au changement pour le contrôleur de domaine qui a initié la réplication, l’USN correspondant au changement pour le contrôleur de domaine sur lequel est récupéré la métadonnée, ainsi que l’UUID et le DN du contrôleur de domaine ayant initié le changement :
Pour les attributs linkés, les métadonnées de réplication, cette fois de type msDS-ReplValueMetaData, vont également stocker des informations sur les attributs liés à l’attribut en question. Les métadonnées de réplication vont alors conserver des informations sur chacune des propriétés de l’attribut lié, y compris pour les valeurs précédentes. Dans l’exemple de l’attribut member, les données de réplication conserveront donc à la fois des informations sur les membres actuels du groupe, mais également sur les utilisateurs ayant été membres mais ne l’étant plus :
A un instant donné, il est alors possible grâce à ces données de déterminer la date de dernière modification d’un attribut, ainsi que le nombre de fois où il a été modifié depuis sa création. Ces données, bien que semblant très limitées, peuvent alors servir à identifier différents scénarios d’attaque.
Elévation de privilèges par ajout dans un groupe
L’un des cas où les données de réplication offrent les meilleurs résultats est l’identification d’un scénario où l’attaquant s’est ajouté, puis supprimé d’un groupe, comme par exemple le groupe « Admins du domaine ».
En effet, au sein d’un Active Directory, les groupes possèdent une propriété « member » qui liste les utilisateurs appartenant au groupe. L’ajout d’un utilisateur dans un groupe va alors incrémenter l’USN de son attribut « member » de 1, celui-ci ayant été modifié. De même, le retrait de l’utilisateur incrémentera également cet USN de 1.
Etant donné ces propriétés, deux conclusions sont possibles :
- Les utilisateurs ayant un USN impair sont membres du groupe (chose qu’il est directement possible de voir dans la valeur de l’attribut « member »), et la date de dernier ajout de l’utilisateur au sein du groupe est celle de l’USN ;
- Les utilisateurs ayant un USN pair ont appartenu au groupe, mais n’en font plus parti depuis la date de l’USN.
C’est donc dans le second cas que se retrouverait le compte d’un attaquant s’étant ajouté au groupe « Admins de domaine » pour réaliser des actions malveillantes, puis supprimé du groupe. Il est alors possible de créer un script récupérant les utilisateurs ayant été ajoutés ou supprimés d’un groupe après une date donnée (seule la date de premier et de dernier changement étant conservés, il ne serait pas fiable de limiter la recherche à une date maximale) :
Targeted Kerberoasting
Le kerberoasting est une technique qui exploite le processus d’authentification Kerberos pour permettre à un attaquant de récupérer le mot de passe d’un compte de service (comprendre « compte disposant d’un Service Principal Name »). Le principe de cette attaque est que, comme le montre le schéma suivant, lors d’une demande d’authentification à un service par un utilisateur, le KDC utilise le hash NTLM du compte de service pour chiffrer le TGS renvoyé à l’utilisateur. Dans ce processus, la légitimité de l’utilisateur à accéder au service n’est pas vérifiée, et n’importe quel utilisateur peut donc obtenir le TGS.
Il est alors possible pour l’attaquant d’effectuer une tentative de cassage du hash NTLM du compte de service en tentant de déchiffrer le TGS à partir de hashs successifs.
Supposons maintenant qu’un attaquant soit parvenu à récupérer des privilèges maximums sur un objet utilisateur, à savoir des privilèges de type GenericAll[5], qui donne notamment le droit de modifier le mot de passe du compte, ou encore de modifier les propriétés de l’objet Active Directory associé au compte. Pour usurper l’identité du compte en question, l’attaquant pourrait donc réinitialiser le mot de passe du compte avec une valeur qu’il choisit, et se connecter à l’aide de ce nouveau mot de passe. Néanmoins, une telle attaque serait rapidement détectée par l’utilisateur légitime du compte, qui ne parviendrait plus à se connecter avec son mot de passe habituel.
Une possibilité plus intéressante pour l’attaquant serait alors d’ajouter un Service Principal Name (SPN) au compte de ciblé, puis d’exécuter une attaque de type kerberoasting. C’est ce qu’on appelle le targeted kerberoasting.
La majorité des utilisateurs d’un domaine n’étant jamais supposée avoir de SPN, une telle attaque peut assez simplement être détectée si ce SPN n’est pas supprimé. Si par contre ce SPN est supprimé par l’attaquant une fois l’attaque effectuée, il reste toujours possible d’utiliser les données de réplication !
En effet, l’ajout ou la suppression d’un SPN sont des événements répliqués au sein de l’Active Directory, et génèrent donc des métadonnées de réplication de type msDS-ReplAttributeMetaData :
Il est alors possible de créer un script récupérant les comptes du domaine dont l’attribut SPN a été modifié depuis une date donnée, comptes qui sont donc des victimes potentielles d’une attaque de type targeted kerberoasting.
Bruteforce d’un compte par blocage successif
Un scénario d’attaque par bruteforce pouvant être utilisé par un attaquant au sein d’un Active Directory ne disposant d’aucune alerte est la réalisation de tentatives de connexion en dehors des heures d’utilisation du compte, et ce jusqu’au blocage du compte.
Lors du blocage d’un compte, un flag LOCKOUT[6] est positionné sur l’attribut userAccountControl d’un utilisateur. Cet attribué étant répliqué entre les différents contrôleurs de domaine, des données de réplication de type msDS-ReplAttributeMetaData sont alors générées. Il est alors possible de créer un script permettant d’identifier les comptes du domaine ayant un numéro de version important dans les données de réplication de cet attribut, ce qui pourrait annoncer un tel bruteforce :
Il est cependant à noter que l’attribut userAccountControl dispose de plusieurs autres flags dont la modification entrainerait également la génération de données de réplication, indissociable des précédentes, comme par exemple pour le flag PASSWORD_EXPIRED. Cependant, cet attribut n’est généralement pas amené à évoluer grandement, et un très grand nombre de changements reste un indicateur relativement fiable d’un bruteforce.
Un autre point à noter est qu’en limitant les tentatives de connexion pour éviter le blocage du compte, un attaquant serait invisible à cette méthode d’investigation.
Conclusion
Bien que n’apportant pas une vision aussi complète que les journaux d’événements, les données de réplication peuvent donc être une source d’information non négligeable pour une investigation forensic dans un Active Directory.
Il est cependant à noter que des techniques permettant la modification des données de réplication pourraient exister[7], la confiance accordée aux informations obtenues grâce à celles-ci ne doit donc pas être aveugle.
Sources :
[1] Voir « systemFlags » : https://msdn.microsoft.com/en-us/library/cc223202.aspx
