Dissimulation d'une configuration de GPO via altération des fichiers ADMX

Bonjour à tous,

Nous allons voir dans cet article une technique pour dissimuler une configuration de stratégie de groupe via l'altération des fichiers ADMX.

On va commencer par un rapide rappel de ce que sont les fichiers ADMX.

Les fichiers ADMX sont des fichiers au format XML permettant d'afficher de façon plus intelligible dans la console de gestion des stratégies de groupe les paramètres de GPO basés sur des clefs de registre. Ceux-ci sont présents dans l'arborescence "Modèle d'administration" de la console d'édition des stratégies de groupe.

Si vous voulez creuser le sujet : Managing Group Policy ADMX Files Step-by-Step Guide

Pour faire un gros raccourcis, les fichiers ADMX sont paramètres configurés par clef de registre ce que le DNS est aux adresses IP.


Concept
Le concept est encore une fois très simple. A partir du moment où il y a un fichier définissant l'affichage on peut le modifier et faire afficher ce que l'on veut.
Nous allons de plus exploiter une bonne pratique concernant la gestion des Stratégies de groupe, à savoir la mise en place d'un Central Store.
Le Central Store permet d'héberger de façon centralisée dans le SYSVOL les fichiers ADMX (et ADML qui présentent aussi leurs vulnérabilités). Lors de l'édition d'une stratégie de groupe, la console récupère les informations présentes dans les fichiers ADMX pour les présenter à l'administrateur.
Pour plus d'information sur le central store : Comment faire pour créer et gérer le magasin Central pour les modèles d’administration de stratégie de groupe dans Windows

Comme je l'ai dit supra, les fichiers ADMX font la traduction Clef de registre / Affichage. On va donc modifier ces fichiers pour configurer une autre clef de registre que celle prévue initialement.


Prérequis
Cette technique nécessite de modifier le contenu du SYSVOL et d'avoir suffisament de privilèges sur les GPO pour pouvoir les modifier. Un compte avec les privilèges type "Domain Admins" est donc nécessaire.


Utilisation de la technique
Il faut commencer par trouver quel fichier ADMX on souhaite modifier. Comme vous pouvez le voir il y a pas mal de possibilité. L'objectif est bien évidemment de trouver un paramètre qui n'attirera pas l'attention et qui a du sens d'être configuré sur les machines ciblées par la GPO.

Je suis parti sur le fichier ServerManager.admx qui permet de désactiver le lancement de la console Server Manager à l'ouverture de session (qui, il faut l'avouer, est bien pénible).

On peut voir la clef de registre configurée initialement dans le fichier ADMX.

On modifie la clef de registre par une autre (j'ai pris ici une clef de registre que j'ai en tête permettant la désactivation IPV6 ...). Il est à noter, et c'est important, qu'on ne peut spécifier que des valeurs décimales. On ne peut donc pas pousser n'importe quelle configuration dans le registre par ce moyen.

On crée et on configure notre GPO.

On vérifie que la configuration est correcte.

Puis on lie la GPO à une unité organisationnelle (je n'ai qu'un DC dans ce lab).

On force l'application de la GPO. On peut voir que la clef de registre est bien poussée.

Si on fait un RSOP en GUI ou un export HTML via un gpresult, tout parait normal puisque les informations sont récupérées du Central Store et donc du fichier ADMX.

Seul un export gpresult en mode console permet d'avoir la vraie configuration poussée par la GPO.

Une technique relativement simple, bien que limitée par les valeurs que l'on peut pousser, mais qui peut permettre à un attaquant de dissimuler une configuration poussée par GPO.
Reste à être imaginatif concernant les paramètres ...
On peut aussi détourner les fichiers ADML pour altérer la traduction des paramètres des fichiers ADMX (Changer un "disallow" par un "allow" par exemple).


Contre-mesure et détection
Comme toujours, une bonne gestion des groupes à privilèges pour éviter la compromission initiale.

Il faut ensuite être en mesure d'auditer les modifications des fichiers présents dans le SYSVOL ainsi que les modifications sur les GPO.

On peut aussi directement auditer les fichiers registry.pol présents dans les GPO.

  
Merci de m'avoir lu et à bientôt.

Dissimulation d'une backdoor utilisant les stratégies de groupe via la fonctionnalité List Object Mode

Bonjour à tous,

On continue la série List Object Mode avec une technique ciblant les Stratégies de groupe.

Les articles précédents sont disponibles dans les liens suivants :

• Dissimulation d'objets Active Directory via la fonctionnalité List Object Mode 
• Dissimulation d'un compte Domain Admins via la fonctionnalité List Object Mode et primaryGroupId 

Je ne présente plus le concept ou les prérequis, ils sont disponibles dans les liens supra.


Utilisation de la technique
Nous allons commencer par modifier l'ACL du conteneur AD qui hébergent les Stratégies de groupe. Je passe assez vite ça a déjà été abordé dans les articles précédents.

Notre attaquant peut désormais créer sa GPO et lui affecter les droits qu'il souhaite.

On peut vérifier que les administrateurs ne voient pas la GPO. A gauche la vue rid-500 et à droite la vue Intruder

Toutefois si vous connaissez bien l'architecture des GPO, vous savez qu'elles sont constituées de 2 composants, l'objet de classe GroupPolicyContainer et les fichiers présents dans le SYSVOL.

Si notre administrateur regarde le SYSVOL, il verra la GPO (le répertoire nommé avec le GUID de la GPO bien qu'il ne puisse y accéder.)

Pour éviter cela, l'attaquant va modifier un des attributs de l'objet GroupPolicyContainer. On voit ici le chemin UNC des fichiers de la GPO dans le SYSVOL.

Notre attaquant a juste besoin de modifier cet attribut en hébergeant la GPO ailleurs que dans le SYSVOL (un partage sur une machine qu'il contrôle par exemple) et en supprimant les fichiers du SYSVOL.

Une fois cette modification effectuée, l'attaquant peut configurer sa GPO et la déployer. J'utilise ici la console DSA pour configurer l'application de la GPO (ici Domain Controllers) car la console GPMC ne permet pas de le faire suite à notre manipulation.

On peut vérifier que la GPO s'applique bien.

Nous avons toutefois un problème, c'est que l'information de liaison de la GPO sur une OU est stockée dans un attribut de l'OU (gpLink). Et notre administrateur y a accès. Il voit donc qu'il y a une GPO liée sur l'OU même si il ne voit pas sa configuration et son contenu.

On ne peut pas lui retirer le droit de lecture de l'attribut gpLink car il ne verrait plus aucune des GPO léies sur l'OU.
On peut toutefois dissimuler cette GPO en la liant au Site AD.

En effet, par défaut, les Sites AD ne sont pas visibles dans la console de gestion des GPO.

On peut donc lier notre GPO sur le Site.

Mais le résultat sera le même, même si c'est plus discret que sur une OU.

La différence c'est que contrairement à l'OU, si la cible n'utilise pas les GPO de site on peut désormais interdire l'accès à l'attribut gpLink (Deny read gpLink sur l'objet Site AD).

Et voilà, notre GPO est désormais invisible.

Le seul moyen de détecter la GPO c'est via son application (ou filtrage) sur les machines où elle s'applique.

Le dernier problème avec cette technique, c'est que la GPO va s'appliquer à toutes les machines qui dépendent du site.
On peut contourner ce problème en utilisant une fois de plus le mode List Object en créeant un subnet et un site AD qui ne sera pas visible par les administrateurs.
Si je veux cibler une seule machine, je crée un subnet en /32 avec son IP et je rattache ce subnet à un site dédié. Ma machine se rattachera à ce site AD et appliquera la GPO.


Contre-mesures et détection
Toujours les mêmes préconisations auquelles j'ajoute cette fois la segmentation et le filtrage des réseaux. Si vos machines ne communiquent pas entres elles, elles ne pourront pas aller récupérer les fichiers de configuration de la GPO sur le partage de l'attaquant (sauf si ce partage est hébergé sur un filer ...).

Merci de m'avoir lu.
Le prochain article traitera de LAPS.

Dissimulation d'un compte Domain Admins via la fonctionnalité List Object Mode et primaryGroupId

Bonjour à tous,

Dans cet article, nous allons continuer de voir des cas d'usage de la fonctionnalité List Object Mode. Il fait suite à l'article Dissimulation d'objets Active Directory via la fonctionnalité List Object Mode

Maintenant que notre compte d'attaquant est dissimulé, il faut pouvoir dissimuler son appartenance à un groupe.

Pour cela, nous allons utiliser l'attribut primaryGroupId.


Concept
La documentation technique nous apprend l'information suivante sur cet attribut:

The user is a member of its primary group, although the group is not listed in the user's memberOf attribute. Likewise, a group object's member attribute will not list the user objects whose primaryGroupID is set to the group.

On comprend vite l'intérêt pour un attaquant d'utiliser cet attribut.

Combiné à la technique précédente, nous avons facilement un compte Domain Admins invisible et non "répertorié" comme membre du groupe.


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, il faut donc avoir les privilèges pour cette modification ainsi que l'appartenance au groupe.
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
La technique est relativement simple. On ajoute tout d'abord le compte dans le groupe Domain Admins. J'utilise les commandes net qui se basent sur l'énumération SAM et non LDAP car le compte intruder n'est pas visible.

Si je liste les membres du groupe Domain Admins, avec une commande Powershell par exemple, je ne vois pas le compte.

En revanche si je passe par la console DSA je le vois bien comme membre du groupe.

Ce qui est confirmé par les Metadata.

Je passe ensuite le groupe Domain Admins en tant que groupe primaire du compte de l'attaquant. Pour me faciliter la tâche, j'utilise une Cmdlet Powershell avec le compte Intruder.

Si on vérifie à nouveau l'appartenance au groupe. On voit tout d'abord que le compte est passé en Absent dans les Metadata.

Et qu'il n'est plus visible par la console DSA.

Le seul moyen de retrouver le compte est d'utiliser l'énumération SAM.

Dans l'article précédent, j'ai indiqué qu'il est plus intéressant de dissimuler le compte via une OU que de rendre directement le compte invible. En effet, dans cet exemple, le compte va être protégé par le SDProp et donc l'ACL du compte va être écrasée par celle de l'AdminSDHolder. Si j'avais fait la modification en enlevant les droits List Object sur le compte il serait redevenu visible après traitement par le SDProp.


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 utilisera en priorité la journalisation pour détecter l'ajout dans le groupe "Domain Admins". Les Metadata rapportent l'information bien qu'elles indiquent que le compte est absent du groupe. Elles permettent toutefois de retrouver le compte et son emplacement dans l'annuaire.
On peut aussi utiliser comme on vient de le voir l'énumération SAM.

Un petit rappel toutefois. Dans cet exemple j'ai utilisé le groupe "Domain Admins" qui est normalement plus surveillé. Il faut bien penser que la compromission de l'annuaire est un moyen et non une fin. Si l'attaquant créé plusieurs comptes et utilise la même technique pour les ajouter à des groupes donnant accès à des ressources, il est peu probable que ce soit détecté à moins d'analyser les logs AD, les logs d'accès aux ressources, les Metadata de tous les groupes et les comparer avec une énumération SAM.

Dans le cadre d'une remédiation suite à compromission, il faut donc être en mesure d'identifier ce type de "backdoor" en amont de la remédiation dès le début de la réponse à incident et éviter les actions précipitées inutiles telles que la réinitailisation des mots de passe des comptes de domaine ou du KRBTGT.

Merci de m'avoir lu.
Dans le prochaine article nous utiliserons encore cette technique pour cibler cette fois les Stratégies de groupe.

Dissimulation d'objets Active Directory via la fonctionnalité List Object Mode

Bonjour à tous,

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 :

• Checking Object Visibility
• Active Directory: Controlling Object Visibility – List Object Mode

 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".