Nous allons voir dans cet article une technique de dissimulation d'objets Active Directory. Dans leur présentation au Black Hat US 2017, An ACE Up the Sleeve (Designing Active Directory DACL Backdoors) , Will Schroeder et Andrew Robbins utilisent une technique basée sur List Contents pour dissimuler par exemple un compte d'attaquant.
Le problème de cette technique est qu'elle n'est pas complètement silentieuse car elle laisse un conteneur vide avec un droit en Deny dessus ce qui peut attirer l'attention.
Pour être plus discret, un attaquant peut tirer avantage de la fonctionnalité List Object Mode.
Je ne vais pas détaillé la fonctionnalité en elle-même car elle est bien documentée.
Vous pouvez vous réferrez aux liens suivants :
Cette fonctionnalité est généralement peu connue des administrateurs.
Concept
Cette technique repose non pas ,comme je l'ai dit précédemment, sur l'ajout d'un droit en Deny mais sur la suppression de droits existants (List Contents et List Object). Il y a en effet peu de chance que l'absence de droit eveille l'attention (contrairement à l'ajout d'un Deny).
Prérequis
Cette technique nécessite de modifier la partition de configuration pour activer le mode List Object, il faut donc avoir des privilèges "Administrateurs de l'Entreprise".
Il faut aussi modifier les ACL de la partition de domaine (création + modification d'ACL), il faut donc avoir les privilèges pour cette modification.
Enfin, afin d'éviter la journalisation de ces modifications, vous pouvez utiliser la technique décrite dans l'article suivant: Éviter la journalisation des modifications d'ACL sur les objets Active Directory
Dans ce cas il faudra aussi avoir les privilèges "Administrateurs du Schéma".
Utilisation de la technique
Nous allons activer tout d'abord le mode List Object. Pour cela, vous pouvez vous rapporter aux liens précédents.
Une fois le mode List Object activé, nous allons créer une OU dans une OU ou un conteneur (de préférence peu utilisé).J'aurais pu directement créer le compte, l'intérêt de passer d'abord par une OU sera abordé dans le prochain article.
Je crée ensuite mon compte dans cette OU.
Puis je m'attribue les droits sur cette OU. En supprimant tous les autres Security Principal je leur enlève de fait le droit List Object qui est à la base de cette méthode.J'aurais très bien pu les conserver et leurs enlever uniquement le droit List Object.
Notre OU est toujours visible.
Nous allons maintenant désactiver l'héritage et copier les droits existants sur l'OU de base.
Puis nous allons retirer le droit List Contents à tous les Security principals dont nous voulons masquer le compte (Domain Admins, Enterprise Admins, Administrators, Authenticated Users, Pre-Windows 2000 ...).
Notre compte et l'OU deviennent "invisibles" pour tous le monde sauf nous. A gauche la vue compte RID-500 et à droite la vue compte Intruder
Les admins voient toujours les autres objets de l'OU DHCP et nous n'avons pas mis d'ACE en Deny qui attirerait l'attention.
Il y a moins de chance qu'un admin se rende compte de la modification de l'ACL sur l'OU DHCP (désactivation de l'héritage et suppression du droit List Contents).
Contre-mesures et détection
Comme toujours, mise à part avec une bonne gestion des comptes à privilèges (via une forêt d'administration par exemple), il est difficile de se prémunir de ce type de technique.
On se concentrera plutôt sur la détection.
Avec en premier lieu la détection de l'activation du mode List Object (dSHeuristics).
Puis la création des objets et la modification des ACL (Log + Metadata).
Le compte ne sera pas listé avec les requètes LDAP mais peut l'être avec une énumération SAM.
Encore faut-il savoir qu'il existe ...
Il ne sera pas non plus listé dans les membres du groupe par défaut Domain Users. A gauche la vue RID-500 et à droite la vue Intruder.
Merci de m'avoir lu.
Dans le prochain article nous allons tirer parti de cette technique pour avoir un compte Domain Admins "invisible".
Aucun commentaire:
Enregistrer un commentaire