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.
Aucun commentaire:
Enregistrer un commentaire