Vue à 10 000 pieds :
Beaucoup d'entre nous connaissent la variété d'outils, d'attaques et d'adversaires qui se concentrent sur la violation d'Active Directory. Avec la publication en 2018 de DCShadow, un autre vecteur très efficace a été ajouté à cette liste qui ne cesse de s'allonger. L'équipe de recherche a eu le mérite d'expliquer, en même temps que l'exploit, comment comprendre et potentiellement atténuer l'attaque grâce à une surveillance et une gestion accrues de l'Active Directory. Cependant, comme pour de nombreuses attaques, il ne s'agit pas seulement de comprendre COMMENT on a été touché... mais aussi d'où on l'a été. C'est sur ce point que l'équipe de recherche de Semperis a récemment concentré ses efforts. Nous sommes désormais en mesure de fournir une image beaucoup plus précise du paysage de l'entreprise et d'identifier clairement et précisément les machines côté client qui ont été ou sont en train d'utiliser l'outil d'attaque contre l'Active Directory de votre organisation.
Contexte :
Mimikatz, l'outil d'exploitation des informations d'identification, propose une fonction appelée "DCShadow". On peut considérer que DCShadow fait le contraire de la commande DCSync. Alors que DCSync peut forcer Active Directory (AD) à synchroniser les comptes d'utilisateurs et leurs hachages de mots de passe avec un pirate, DCShadow permet à un pirate d'injecter des modifications dans AD. Pour ce faire, il simule le comportement d'un contrôleur de domaine, c'est-à-dire toute machine compromise au sein d'un domaine Active Directory. Il convient de noter que DCShadow est un outil de persistance de domaine. Pour pouvoir l'utiliser, l'attaquant doit déjà disposer d'un accès Admin de domaine, ou équivalent, sur un domaine AD. Cependant, une fois ce niveau d'accès atteint, il s'agit d'un outil puissant et silencieux pour créer et mettre à jour des objets dans AD dans le but de créer des portes dérobées, d'élever l'accès à des comptes normaux et d'établir un point d'ancrage et d'exercer un contrôle dans l'environnement ciblé.
Détectabilité
Le problème avec DCShadow est que, comme il contourne les mécanismes normaux d'audit des modifications apportées à AD (normalement effectués via le journal des événements de sécurité Windows sur les contrôleurs de domaine), il n'est pas facile de détecter son utilisation. De plus, si l'attaquant effectue des modifications furtives que vous ne recherchez pas (par exemple, en injectant le SID des administrateurs d'entreprise dans l'attribut sidHistory d'un utilisateur non privilégié), il peut s'avérer très difficile de détecter ces portes dérobées. Par exemple, lorsque DCShadow est exécuté, un objet de classe server est temporairement ajouté au contexte de nommage de la configuration dans une forêt donnée, afin de faire croire aux autres contrôleurs de domaine que le faux serveur est un vrai DC. Mais cet objet est rapidement supprimé lorsque DCShadow termine son exécution. Heureusement pour le défenseur, il s'avère que DCShadow laisse des empreintes derrière lui lorsqu'il est exécuté sur un hôte.
Découverte de l'utilisation de DCShadow
Tout d'abord, un peu d'histoire. Un contrôleur de domaine "normal" enregistre un certain nombre de SPN (Service Principal Names) Kerberos lorsqu'il est promu en DC. L'un d'entre eux est un SPN basé sur un GUID, comme indiqué ici :
Ce SPN basé sur un GUID présente une caractéristique intéressante. Si nous l'examinons de près, nous constatons qu'il y a en fait deux GUID dans le SPN. Le premier, à savoir E3514235-4B06-11D1-AB
04-00C04FC2DCD2, est ce que l'on appelle un Well-Known GUID (WKGUID) et est enregistré de la même manière par tous les contrôleurs de domaine dans toutes les forêts AD. Le second GUID, dans notre exemple ici : 8b699bb0-d35e-4199-8dd4-6a296c5fc7db, est propre à un contrôleur de domaine particulier.
[semperis-mid-scroll-cta]
En quoi cela nous aide-t-il dans la détection de DCShadow ? Il s'avère que lorsque DCShadow s'exécute sur un hôte donné, il ajoute quelques SPN à cette machine pour faire croire aux autres DC qu'il s'agit d'un DC. L'un d'entre eux est le SPN basé sur WKGUID. Malheureusement, ce qu'il ne fait pas, c'est nettoyer derrière lui lorsqu'il a fini de fonctionner (heureusement, un DCShadow désordonné). Le résultat est que tout hôte qui a exécuté DCShadow continue à stocker le SPN WKGUID dans l'attribut servicePrincipalName de son compte machine.
Vous pouvez en voir un exemple dans la deuxième capture d'écran ci-dessous. Dans cet exemple, nous avons exécuté DCShadow à plusieurs reprises à partir de cet hôte - remarquez combien de SPN WKGUID apparaissent dans la liste :
La bonne nouvelle, c'est que nous pouvons utiliser cette information pour distinguer les hôtes dans AD qui ont exécuté DCShadow. Tout d'abord, nous savons que seuls les DCs *légitimes* devraient avoir ce SPN WKGUID sur leur compte machine. C'est assez facile à rechercher, mais nous pouvons affiner notre recherche en recherchant également un autre SPN dont nous savons qu'il NE DEVRAIT PAS se trouver sur une machine autre qu'un DC légitime. Le résultat que nous avons obtenu est la requête LDAP suivante :
"(&(objectClass=computer)(servicePrincipalName=E3514235-4B06-11D1-AB04-00C04FC2DCD2*)( !(servicePrincipalName=ldap*)))"
Cette requête recherche tous les objets informatiques dont l'attribut SPN contient le SPN WKGUID (nous utilisons ici un caractère générique pour exclure la partie GUID unique de ce SPN) ET n'inclut pas le SPN LDAP, que chaque DC légitime contient.
Conformément à la nature furtive de DCShadow, l'ajout de ce SPN WKGUID au compte machine du faux DC n'est pas consigné dans le journal des événements de sécurité du vrai DC qui reçoit la demande de réplication du faux DC.
Résumé
En supposant que DCShadow ne fasse pas le ménage de sitôt, cette détection nous permet d'atteindre rapidement toutes les machines utilisées pour héberger des injections DCShadow, de les mettre en quarantaine de manière appropriée et d'exécuter des analyses médico-légales complètes et des processus IR AVANT qu'elles ne puissent faire plus de dégâts.
Démonstration de l'attaque DCShadow
DCShadow exploite un commutateur dans l'utilitaire Mimikatz qui permet aux utilisateurs privilégiés d'injecter des modifications malveillantes dans Active Directory sans être détectés. Regardez cette présentation vidéo pour apprendre comment détecter les contrôleurs de domaine malveillants, annuler rapidement les modifications non désirées et restaurer la vue de votre SIEM. Si vous avez des questions, n'hésitez pas à contacter le personnel de Semperis.
