samedi 12 août 2017

Dissimulation d'une Backdoor AdminSDHolder via substitution de l'attribut localizationDisplayId des droits étendus

Bonjour à tous,

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.

mardi 8 août 2017

Dissimulation d'une Backdoor DCSync via substitution de l'attribut RightsGuid des droits étendus

Bonjour à tous,

Je vais aborder dans cet article une technique permettant de dissimuler les droits sur un objet Active Directory et notamment les droits étendus (Extended Rights).

Pour cet exemple, je vais dissimuler les droits étendus permettant d'utiliser la technique DCSync.

Pour rappel, les droits étendus consistent en l'exécution de tâches spécifiques sur certains types d'objet, telles que réinitialiser le mot de passe d'un utilisateur.
Ces droits étendus sont visibles dans le conteneur "Extended Rights" de la partition de Configuration.


Concept
Cette technique repose sur l'échange de l'attribut RightsGuid de deux droits étendus.
Il faut donc au préalable identifier quels sont les droits étendus disponibles pour une classe d'objet Active Directory et qui bénéficie d'une délégation sur ces droits étendus.

Pour utiliser la technique DCSync nous avons besoins de 2 droits étendus (DS-Replication-Get-Changes et DS-Replication-Get-Changes-All)  sur la partition de domaine (objet de classe domainDNS).

La liste des droits étendus s'appliquant à la classe domainDNS est disponible ici : Extended Rights Reference


En vérifiant qui dispose de droits étendus sur la partition de domaine on s'aperçoit que "Utilisateurs Authentifiés" dispose des 3 droits étendus suivants :


Pour comprendre l'utilité de ces droits vous pouvez vous référer à l'article suivant: Vos administrateurs respectent-ils la politique de mot de passe que vous avez définie ?  

Nous avons donc tous les éléments pour mettre en place une backdoor basée sur la substitution de l'attribut RightsGuid de deux droits étendus.

Il nous suffit d'abord d'échanger la valeur de l'attribut RightsGuid entre par exemple DS-Replication-Get-Changes-All et Unexpire-Password puis entre DS-Replication-Get-Changes et Enable-Per-User-Reversibly-Encrypted-Password.

Puis de modifier les droits étendus d'Utilisateurs Authentifiés pour lui affecter les droits pour DCSync.

Au final, l'affichage des droits affectés à Utilisateurs Authentifiés n'aura pas changé alors qu'ils auront des droits pour DCSync.


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
Les modifications peuvent être effectuée via la console ADSIEdit.msc.

On commence par faire la substitution des RightsGuid.





On peut ensuite vérifier que l'affichage des droits a été modifié.



Si on vérifie pour le groupe "Contrôleurs de domaine" on voit que l'affichage a aussi changé.





Il suffit ensuite de modifier les droits de Utilisateurs Authentifiés pour lui réaffecter les droits d'origine qui ont été substitués par les droits DCSync.



La backdoor est désormais en place et résistera à une analyse basique des droits sur la partition de domaine. Il y a en effet peu de chance que les droits des différents groupes Contrôleurs de domaine soient analysés. L'affichage des droits des autres groupes (Administrateurs, administrateurs du domaine, administrateurs de l'entreprise, SYSTEM) ne sera pas affecté car ils bénéficient de tous les droits étendus sur la partition de domaine. La substitution n'a donc pas d'effet sur eux.

Il reste à vérifier que la backdoor est bien fonctionnelle.


Désormais, tous les utilisateurs authentifiés pourront effectuer une attaque DCSync.


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.
Encore une fois les audits par défaut ne remontent pas la substitution des RightsGuid.

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 RightsGuid:  Éviter la journalisation des modifications d'ACL sur les objets Active Directory


De même pour les évènements d'accès qui sont rarement collectés.


Reste ma méthode préférée, les metadata de réplication Active Directory qui permettent de détecter la substitution des RightsGuid.



Encore une fois, l'analyse des Metadata de réplication présente un grand intérêt lors d'analyse forensic Active Directory.

Comme je l'ai dit dans le précédent article, je mettrais prochainement à disposition un module powershell de forensic Active Directory permettant de détecter ce type de technique.

Merci de m'avoir lu et à bientôt pour de nouveaux articles sur ces sujets.

lundi 7 août 2017

Eviter la journalisation des modifications d'ACL sur les objets Active Directory

Bonjour à tous,

Après une très longue pause sur ce blog (3 ans ...), j'ai décidé de reprendre la publication d'articles consacrés à la sécurité et notamment à la sécurité d'Active Directory.

Je vais vous présenter aujourd'hui une technique dont j'avais déjà parlé dans un précédent article (Voir De l'intérêt des Metadata de Réplication lors d'audit Forensic Active Directory, Partie 1).

La détection des modifications d'ACL sur des objets Active Directory passe généralement par la journalisation de ces modifications. Afin de rester le plus discret possible, un attaquant doit éviter de générer des logs ou être en capacité de les altérer.

La technique que je vous présente ici permet d'éviter la journalisation des modifications des ACL.

Par défaut, l'utilisation de cette technique n'est pas journalisée avec les audits de modification Active Directory.


Concept
Cette technique repose sur l'altération de l'attribut SearchFlags de la classe d'attribut dans le Schéma Active Directory.

Les différentes valeurs que peut prendre l'attribut SearchFlags sont décrites dans le lien suivant : [MS-ADTS]: Search Flags .

La valeur qui nous intéresse est la valeur suivante :
NV (fNEVERVALUEAUDIT, 0x00000100): Specifies that auditing of changes to individual values contained in this attribute MUST NOT be performed. Auditing is outside of the state model.

On comprend facilement qu'en ajoutant cette valeur à l'attribut SearchFlags d'une classe d'attribut dans le Schéma Active Directory que les modifications de cet attribut ne seront pas journalisées.
Pour le cas qui nous intéresse ici c'est la classe d'attribut nTSecurityDescriptor que nous allons altérer.

Voici pour le concept, la technique est relativement simple à comprendre. Elle n'est bien évidemment pas limitée à la classe d'attribut nTSecurityDescriptor.


Prérequis
Cette technique nécessite de modifier le Schéma Active Directory mais aussi de mettre à jour le cache du Schéma Active Directory pour pouvoir être utilisée immédiatement (par défaut la mise à jour du cache s'effectue 5 minutes après la modification voir Schema Cache pour plus d'informations).
La mise à jour du cache du Schéma nécessite le droit étendu Update-Schema-Cache.

Pour pouvoir modifier le schéma et mettre à jour le cache du Schéma il faut avoir les privilèges de Schema Admins (RID -518).


Utilisation de la technique
Comme vous l'avez vu, la technique est relativement simple.
Nous allons modifier la valeur de l'attribut SearchFlag de la classe d'attribut nTSecurityDescriptor en y ajoutant le bit NV puis en faisant une mise à jour du cache du Schéma Active Directory.

Les modifications peuvent être effectuée via la console ADSIEdit.msc

On commence d'abord par vérifier que la journalisation des modifications d'ACL est bien fonctionnelle (la protection contre les suppressions accidentelles ajoute une ACE en Deny pour Everyone).



On modifie ensuite la valeur de l'attribut SearchFlag.







On fait ensuite la mise à jour du cache du Schéma.





On peut maintenant faire les modifications sans générer de logs.



On vérifie que la journalisation est bien toujours fonctionnelle pour les autres modifications.




On a donc bien modifié les ACL sans générer de logs.

On peut ensuite faire le rollback de la modification du schéma pour revenir à un état normal et journaliser à nouveau les modifications.


On peut donc mettre en place discrètement une backdoor au travers des ACL Active Directory sans éveiller les soupçons.

Bien évidemment tout ceci peut être automatisé. Je mettrais à disposition ultérieurement un outil permettant de faire ces modifications.


Contre-mesures et détection
Les contre-mesures sont relativement simple.
Le groupe "Schema Admins" doit être utilisé uniquement lors d'opération sur le schéma. Il doit donc être vide en temps normal.
Toutefois, un attaquant pourra injecter le SID -518 dans l'attribut SIDHistory d'un compte ou d'un groupe.
Il est donc difficile de se prémunir de ce type de technique.


Concernant la détection, il y a 2 possibilités.
Tout d'abord, il faut savoir que même en configurant correctement les audits AD sur la partition de Schéma aucun log de modification Active Directory n'est généré ...

Les seuls évènements générés sont les logs d'accès Active Directory.


Le problème avec les logs d'accès Active Directory c'est qu'ils sont générés en grande quantité et peuvent donc être exclus des collectes d'évènements. De même si vous n'avez pas de séquestre de vos logs, il y a de grande chance qu'ils soient écrasés par d'autres logs.

Il y aussi l'évènement suivant qui est généré à la première modification de l'objet.



Les modifications ultérieures du même attribut ne génèrent pas cet évènement.
De même, il y a peu de chance que ces évènements soient collectés.

Dans tous les cas, un attaquant pourra altérer les logs.

Il reste donc la seconde méthode qui a depuis longtemps ma préférence: les metadata de réplication Active Directory.

Elles vont nous permettre de détecter ce type de modification en l'absence de log.


On y retrouve notamment un numéro de version (ici 5) et la date du dernier changement (LastOriginatingChangeTime).
On peut donc savoir combien de fois l'objet a été modifié et de quand date la dernière modification.

Je mettrais prochainement à disposition un module powershell de forensic Active Directory que j'utilise depuis quelques années, je ne détaillerais donc pas la méthode dans cet article.

Merci de m'avoir lu et à bientôt pour de nouveaux articles sur ces sujets.