Nous allons voir aujourd'hui une autre backdoor basée sur le même type de technique décrite dans l'article précédent (DCSync Backdoor via substitution de l'attribut RightsGuid des droits étendus).
Concept
Cette fois nous allons substituer non pas l'attribut RightsGuid mais l'attribut localizationDisplayId.
Ici nous allons jouer uniquement sur la traduction de l'affichage de certaines consoles.
Cette technique va nous permettre de dissimuler le droit de réinitialiser le mot de passe de comptes protégés par le process SDProp.
Nous aurions pu aussi utiliser la même technique que pour DCSync et inversement.
Prérequis
Cette technique nécessite de modifier la partition de configuration, 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.
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
Voici l'ACL du conteneur AdminSDHolder (j'utilise LDP pour afficher plus finement les ACE).
On remarque rapidement que le groupe "Tout le monde" a le droit étendu "User-Change-Password".
On va donc pouvoir substituer ce droit étendu avec un autre, le plus logique ici étant "User-Force-Change-Password".
On substitue les 2 valeurs de l'attribut localizationDisplayID.
On vérifie que la substitution est bien effective (réouverture de la console nécessaire). On voit bien ici que seul l'affichage (la traduction) est modifié
On modifie l'ACE sur l'AdminSDHolder.
Une fois le process SDProp exécuté, on peut vérifier que la modification a bien été propagée aux comptes protégés. (En passant par LDP on voit bien les droits non traduits ce qu'on n'avait pas avec la substitution de l'attribut RightsGuid.)
Il ne reste plus qu'à réinitialiser le mot de passe du compte administrateur avec un compte standard.
Le problème de cette technique, c'est que la substitution est visible pour les comptes non protégés par le process du SDProp puisque l'ACE n'a pas été modifiée.
On peut toutefois juste remplacer et non substituer les deux attributs.
Le résultat n'est pas vraiment probant puis qu'on voit le droit en double.
On peut donc faire une double substitution avec un droit étendu non applicable à la classe d'objet Utilisateur pour ne pas avoir de doublon sur l'autre classe d'objet.
Et là, le droit semble inoffensif ou éveillera moins les soupçons.
Contre-mesures et détection
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.
En configurant correctement les audits sur la partition de configuration la substitution est bien journalisée. Toutefois cette journalisation peut être éviter avec la technique décrite dans l'article suivant en désactivant l'audit de l'attribut localizationDisplayId: Éviter la journalisation des modifications d'ACL sur les objets Active Directory
Et bien évidemment toujours les metadata qui permettent de détecter ces modifications en l'absence de logs.
Cette technique, qui joue uniquement avec l'affichage des consoles, ne résistera pas dans tous les cas à un audit plus avancé.
Merci de m'avoir lu et à bientôt pour de nouveaux articles sur ces sujets.
Aucun commentaire:
Enregistrer un commentaire