dimanche 18 février 2018

Détecter DCShadow, impossible ?

Bonjour à tous,

Je vous propose aujourd'hui un article sur l'attaque présentée par Vincent Le Toux (@mysmartlogon) et Benjamin Delpy (@gentilkiwi) durant la conférence de sécurité BluehatIL 2018 qui a eu lieu les 23 et 24 janvier.

Leur présentation s'intitulait Active Directory: What can make your million dollar SIEM go blind?

En effet, l'intérêt pour un attaquant d'utiliser DCSHadow est de ne laisser aucune tracer de ses modifications puisque celles-ci sont effectuées sur une machine compromise par l'attaquant. Ainsi aucun log de modification AD n'est remonté.

Vous pouvez retrouver la vidéo et les slides de la présentation sur le site officiel sur DCShadow https://www.dcshadow.com/.


Un peu d'histoire

La première évocation par Vincent et Benjamin de ce qui allait devenir DCShadow remonte à l'été 2017.

Faisant de la réponse à incident sur Active Directory depuis quelques années le tweet de Vincent m'a forcémment interpelé. La possibilité qu'un attaquant puisse altérer les métadonnées de réplication a toujours été une de nos craintes sur le forensic AD.

J'ai pourtant évoqué en répondant à ses tweets une autre méthode, non forensic mais plus de blue team, les cookies de réplication AD.



Les cookies de réplication AD sont assez méconnus mais utilisés par les équipes de réponse à incident AD lors des remédiations/reconstructions d'environnement Active Directory compromis.
Ils permettent notamment de limiter l'interruption de service lors de la remédiation contrairement aux précédentes méthodologies.

C'est un sujet assez peu documenté mais on peut en trouver une trace dans la présentation de l'ANSSI sur TV5 Monde du SSTIC 2017 Retour technique de l'incident de TV5Monde.


Cookie de réplication AD

Un cookie de réplication est un fichier généré par l'utilisation d'une extension de serveur LDAP, le contrôle DirSync. Il faut d'abord initialiser le cookie pour pouvoir avoir les modifications depuis la dernière utilisation du cookie.


Pour plus d'informations sur comment tracer les modifications vous pouvez consulter le lien suivant : Overview of Change Tracking Techniques.
Vous retrouverez dedans une page dédiée au contrôle DirSync. 


Pour utiliser ce contrôle, il ya plusieurs possibilités.
La plus simple pour tester rapidement, c'est d'utiliser Repadmin avec le switch /showchanges (visible avec l'aide en mode expert de repadmin /experthelp).

C'est ce que je vais utiliser dans cet article.


Pour des résultats plus exploitables, on utilisera les méthodes de la classe System.DirectoryServices.DirectorySynchronization 

Ca marche très bien avec du powershell :



Je ne vais pas m'étender c'est relativement simple à utiliser. Revenons maintenant sur l'attaque DCShadow.


Détection de l'utilisation de DCShadow

Alsid a fait un très bon article sur DCShadow (DCShadow explained: A technical deep dive into the latest AD attack technique) je vais donc revenir dessus très brièvement.   


Détecter l'utilisation de DCShadow peut paraître assez trivial. En effet, pour être utilisé, DCShadow doit au préalable effectuer des modifications sur des objets Active Directory. En journalisant la modification de ces objets, on peut détecter facilement l'utilisation de DCShadow.

Il suffit pour cela de configurer correctement la politique d'audit (audit réplication détaillée et modifications AD) et de configurer quelques SACL (écriture de l'attribut servicePrincipalName des objets Computer ).




Il ya toutefois un gros bémol à cette technique. L'attaquant en capacité d'utiliser DCShadow dispose de privilèges élevés sur l'Active Directory. Rien ne l'empêche de modifier temporairement la politique d'audit sur le contrôleur de domaine qui sera ciblé par DCShadow pour la réactiver par la suite.  

Ca nous laisse donc la détection par le réseau qui est beaucoup moins trivial à mettre en place ou les cookies de réplication.


Il est intéressant d'ailleurs de comparer ce que remonte la journalisation AD avec ce que remonte le cookie de réplication.

J'effectue une modification avec DCShadow.




Voici ce que j'ai dans le log:



On peut voir l'ajout puis la suppression du SPN de catalogue global (GC/).


Voici ce qu'on a avec le cookie de réplication:



Avec le cookie de réplication, on a la valeur finale du SPN, avec le GUID du service DRS mais pas le GC qui a été supprimé.

Ce qui est intéressant c'est que la journalisation ne log pas l'ajout du SPN du service DRS (GUID E35...). 


On peut donc déjà détecter l'utilisation de DCShadow sans utiliser la journalisation ni la capture réseau.

Comme je l'ai déjà dit, l'intérêt de DCShadow est de ne pas laisser de trace sur les modifications en elles-même.

C'est bien de détecter que DCShadow a été utilisé mais ne pas savoir ce qui a été modifié rend la remédiation imposible.

On va voir qu'il y a plusieurs cas en fonction de comment on utilise DCShadow.

Mais avant de voir tout ça nous allons faire un très court rappel sur ce qui déclenche une réplication entre les contrôleurs de domaine car ça a énormément d'importance pour la suite.


Réplication AD et USN

La réplication AD se base sur le numéro USN (Update Sequence Number).

Pour faire très simple, le DC qui demande les réplications à son partenaire demande les modifications effectuées depuis le dernier USN qu'il connait.

Autrement dit, ton dernier USN que je connais est X, envoie-moi les attributs qui ont un numéro USN supérieur.


Pour plus d'informations, vous pouvez vous réferrez à cet article du technet : Tracking updates

Comme je l'ai dit l'USN a beaucoup d'importance pour la suite.

Détection des modifications opérées via DCShadow

Je n'ai pas pu tester tous les cas possibles en quelques heures mais voici déjà un bon aperçu.

Modification d'un attribut existant sur le DC où a eu lieu la dernière modification de l'attribut avec les switchs de DCShadow par défaut

Le premier cas que l'on va voir est l'utilisation de DCShadow telle qu'elle a été faite au début de l'article.

Si l'on regarde les métadonnées de l'objet nous avons ceci :



On peut voir que la valeur du numéro USN de l'attribut Description est 42, nombre assez remarquable.

En regardant le code source, on trouve rapidement que c'est une valeur hardcodée et qu'il ya une branche conditionnelle (switch qu'on verra plus tard).



Ce qui m'a étonné quand j'ai joué la première fois avec DCShadow, c'était que cette modification n'était pas détectée par le cookie de réplication.

Mon premier réflexe a été de me dire qu'il sera catché par le cookie sur mon second DC lors de la réplication, mais je n'avais rien non plus et surtout l'attribut n'était pas modifié sur le second DC.

Je vérifie les réplications et il n'y a pas de problème.



Je compare ensuite les métadonnées de réplication.



Et là on peut voir une différence entre les 2.
Ma modification effectuée avec DCShadow n'a donc pas été repliquée sur les autres contrôleurs de domaine.

La raison est simple, la valeur d'USN étant 42, la modification n'est pas répliquée.


On voit tout de suite un intérêt du point de vue DFIR.

Premièrement, 42 est un marquant fort dans les métadonnées de réplication (mais peut-être modifié dans le code par l'attaquant).
Deuxièmement, les modifications n'ayant pas été repliquées, la remédiation des modifications est très simple, il suffit de reconstruire le DC (après avoir réglé le problème de privilège bien évidemment).

Dans ce cas, on ne se sert pas du cookie de réplication puisqu'il n'y a pas réplication mais on peut retrouver les modifications via les métadonnées (ou comparer les données entre le DC sur lequel DCShadow a été utilisé et un autre DC).

L'intérêt pour l'attaquant est bien évidemment de ne pas utiliser DCShadow dans ce sens. Puisque si on détecte l'utilisation de DCShadow sur ce contrôleur de domaine on retrouvera rapidement les modifications qu'il a effectuées.

On va donc utiliser l'autre branche conditionnelle du code qui est un switch permettant de spécifier le numéro USN.


Modification d'un attribut existant sur le DC où a eu lieu la dernière modification de l'attribut en utilisant le switch replOriginatingUsn de DCShadow

Cette fois, nous allons spécifier la valeur du numéro USN.

On recommence cette fois en utilisant le switch /replOriginatingUsn avec un numéro USN permettant la réplication.




On vérifie les réplications.

Et là, on voit que la modification de l'attribut Description a bien été répliquée.

D'un point de vue DFIR c'est la merde, les modifications ont été répliquées et je n'ai plus le marquant du numéro USN.
Bonne chance pour remédier ...


Mais cette fois, si on regarde le cookie de réplication:



On voit bien la modification avec la valeur de l'attribut modifié.
Il est assez facile de retrouver les modifications opérées avec DCShadow puisqu'elles vont suivre la modification du SPN.


Autre marquant

Je me suis demandé si l'utilisation de DCShadow pouvait provoquer un USN Rollback.
En réflechissant, ça ne peut pas être le cas mais en regardant la valeur de Up-to-dateness Vector j'ai eu la surprise de voir ceci.



A creuser mais ça pourrait être un marquant de l'utilisation de DCShadow si on n'a pas déployé de moyen de détection. 


Conclusion

On peut donc désormais répondre à la question de cet article, est-ce vraiment impossible de détecter DCShadow ?

Il faut bien séparer utilisation de DCShadow et modifications opérées par DCShadow.

Dans les 2 cas on a pu voir qu'il était possible de les détecter (Bien que je n'ai pas pu tester tous les cas possibles).
Cette détection s'avère tout de même très difficile.

Clairement si vous n'êtes pas en capacité d'empêcher l'attaquant de récupérer les privilèges nécessaires à l'utilisation de DCShadow, il est peu probable que vous soyez en capacité de déployer une détection basée sur les cookies de réplication.


mardi 29 août 2017

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.

mercredi 23 août 2017

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 :

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.