Dissimulation d'une configuration de GPO via altération des fichiers ADMX (Mise à jour)

Bonjour à tous,

Dans un précédent article (Dissimulation d'une configuration de GPO via altération des fichiers ADMX), j'avais montré comment modifier les fichiers ADMX pour pousser des paramètres dans le registre via GPO en dissimulant la configuration.

J'avais indiqué une limitation concernant les données que l'on pouvait pousser via cette méthode (uniquement une valeur décimale).

J'ai voulu recreuser un peu le sujet, j'ai d'abord regardé dans le xsd (Group Policy ADMX Schema files) et j'ai fini par parcourir la doc MS (RTFM quoi) : PolicyDefinitions schema


Dans cette doc, on retrouve notamment l'information suivante : string (in type: Value)

La partie intéressante concerne les parents possibles (disabledValue et enabledValue).

On n'est donc finalement pas limité par une valeur décimale, on peut aussi pousser du texte sur un paramètre "booléen".

Reprenons l'exemple que j'avais utilisé dans le précédent article, Activation ou désactivation du lancement de ServerManager à la connexion.

Voici le fichier ServerManager.admx par défaut.

Modifions-le avec quelque chose de plus intéressant, une clé de Run par exemple.

On peut maintenant créer notre GPO.

On lie la GPO, on force l'application et voilà.

Un petit RSOP pour voir que la configuration est bien dissimulée.

autre exemple, backdoor utilman.exe

Le résultat

Je ne vais pas aller plus loin, je pense que vous avez saisi le truc.

De quoi s'amuser un peu avec la Blue Team quand on a la main sur le domaine...

Mise en place d'une Backdoor LAPS via modification de l'attribut SearchFlags avec DCShadow

Bonjour à tous,

Je vous propose aujourd'hui un article que j'avais commencé il y a un petit moment.

Nous allons voir une technique pour mettre en place une "backdoor" permettant d'accéder aux mots de passe gérés par LAPS sans avoir à modifier les ACLs sur les objets ordinateurs.
Cette technique peut permettre à un attaquant de refaire rapidement une élévation de privilèges.


Concept
Le concept de cette technique est relativement simple.
La protection du mot de passe géré par LAPS est assuré par la confidentialité de l'attribut ms-mcs-admpwd. Toute la solution repose sur ce flag de confidentialité. En désactivant la confidentialité de l'attribut, tout le monde peut lire le mot de passe contenu dans l'attribut.

L'intérêt de cette technique est qu'elle ne nécessite pas de modification des ACL sur les objets et qu'elle n'impacte pas le fonctionnement de la solution.
La probabilité qu'un administrateur se rende compte de cette modification est relativement faible.


Utilisation de DCShadow

Pour être plus discret et faire suite à la présentation de Vincent Le Toux (@mysmartlogon) et Benjamin Delpy (@gentilkiwi) durant la conférence de sécurité BlackHat 2018 (So I Became A Domain Controller), je vais utiliser DCShadow.

Dans la vidéo DCShadow modying the schema without being noticed Vincent montre comment faire des modifications dans le schéma sans modifier l'attribut schemaInfo.

Pour le coup je ne suis pas complètement d'accord avec lui puisque dans son exemple il ne modifie pas les métadonnées de réplication. On peut donc facilement retrouver la modification effectuée dans la vidéo via les métadonnées.

Je note d'ailleurs que le code mis à jour n'utilise plus 42 comme valeur d'USN par défaut mais se base sur la plus haute valeur d'USN émise par le DC. Cette modification permet donc de répliquer les modifications effectuées via DCShadow lorsque l'on ne spécifie pas de numéro USN.


Afin de rester le plus discret possible, je vais altérer les métadonnées.
Il faut donc d'abord récupérer les métadonnées. C'est faisable rapidement avec powershell et le module AD.

On a donc toutes les informations qui nous intéressent.
On peut donc préparer notre commande DCShadow.

Il nous faut juste la valeur à mettre dans l'attribut (voir Search Flags ).
Dans notre cas, il faut enlever le flag de confidentialité. La nouvelle valeur sera donc : 776 (0x308 au lieu de 0x388).

Pour être encore plus discret, je vais cibler un DC qui sera moins suceptible d'être utiliser par les administrateurs (un DC d'un site distant par exemple). Un rapide coup d'oeil au code source d'AdmPwd  ne montre pas de ciblage d'un DC en particulier par les Cmdlets du module.

Je vérifie déjà que mon utilisateur n'a pas accès au mot de passe (j'utilise les Cmdlets du module ActiveDirectory pour cibler le DC).

Je prépare ma commande DCShadow (Je cible un DC en particulier + altération des métadonnées).

Je pousse la modification en ciblant le DC.

On peut vérifier que la modification est effective et qu'une partie des métadonnées n'ont pas changées (LastOriginatingXXX).

On remarque qu'il y a 2 attributs qui ont changé: la version et la valeur de l'USN local.

Si on vérifie avec l'autre DC, les modifications n'ont pas été répliquées (ce qui est voulu dans notre cas). mais les métadonnées sont identiques (sauf la version).

Il ne reste plus qu'à vérifier le bon fonctionnement.
On récupère bien désormais le mot de passe en ciblant le DC.

On a donc un DC qui nous permet de récupérer les mots de passe avec n'importe quel compte (user et computer)  et on n'a pas altéré le fonctionnement de la solution. En ciblant un DC moins susceptible d'être utilisé par les admins il y a moins de risque que la modification soit découverte.

Cet exemple est facilement déclinable à d'autres backdoors déjà connues (DCSync que sur un DC par exemple...).

Plus l'infra de la cible comporte de DC et plus il sera difficile de détecter ce genre de backdoor.


Contre-mesures et détection

Pour la partie LAPS, il est possible de mettre en place un audit de l'accès à l'attribut ms-mcs-admpwd pour savoir qui accède en lecture à l'attribut.

Je ne l'ai pas testé mais il n'y a pas de raison que ce ne soit pas fonctionnelle.

Pour DCShadow ça devient difficile. On a vu que le numéro de version était différent, le LocalChangeUSN aussi.

On peut détecter l'utilisation de cette technique en comparant les métadonnées de l'attribut searchFlags avec celles de l'attribut CN qui n'est pas répliqué mais est créé sur le DC au moment de la création de l'objet.

En comparant la valeur de LocalChangeUSN et la date entre les 2 attributs on peut voir l'incohérence du LocalChangeUSN de l'attribut searchFlags par rapport à celui du CN.

Mais bon, voilà quoi ...

Autant dire quasi impossible en vrai.

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.