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