De l'intérêt des Metadata de Réplication lors d'audit Forensic Active Directory, Partie 1

Bonjour à tous,

Je vous propose aujourd'hui un sujet autour des audits Forensic d'environnement Active Directory.
Sujet malheureusement d'actualité auquel il faut se préparer car aujourd'hui nul n'est à l'abri d'une compromission de son environnement Active Directory.

On va voir ici l'intérêt d'utiliser les Metadata de réplication pour avoir rapidement un aperçu des modifications qui ont pu être effectuées dans un environnement Active Directory.

Vous allez me dire : Pas besoin, je fais déjà de l'audit sur mon environnement AD, je vais voir toutes les modifications qui sont effectuées. Et vu que je fais les choses bien, c'est même centralisé avec l'Event Forwarding.

Oui mais ... Faisons un petit test.

J'ai un environnement AD avec l'audit des modifications AD activé sur mon DC.

 Dans mon environnement j'ai une OU nommée TEST-METADATA

Sur cette OU j'ai configuré un audit pour toutes les modifications effectuées par tous le monde.

L'audit est donc bien configuré sur le DC et sur l'objet au travers des SACL.

Faisons un test en modifiant la description de l'OU.

Effectivement l'audit fonctionne bien. J'ai bien un event qui est généré pour la modification.

Maintenant, modifions les permissions sur cette OU. Pour simplifier les choses je vais juste modifier la protection contre la suppression accidentelle qui modifie les ACL sur l'objet.

Mon attribut a bien été modifié (les ACL de l'OU en fait) mais pourtant je n'ai pas d'event généré ...
Si je modifie à nouveau la description, les events sont bien générés (2 events, un pour la suppression de l'ancienne valeur, un pour l'ajout de la nouvelle)

Les modifications sur les objets audités ne génèrent donc pas toutes des events ...

Et si il était possible de masquer des actions de modification malveillantes sans qu'elles soient remontées par l'audit ?

Je ne vais pas rentrer dans le détails dans cet article mais je vais juste vous dire ce que j'ai fait pour empêcher l'audit des modifications des ACL.
Vous le savez sûrement, les permissions sont "stockés" dans l'attribut ntSecurityDescriptor

J'ai modifié l'attribut searchFlags de l'objet du schéma nt-security-descriptor.
Et j'ai spécifié de ne pas auditer cet attribut.

Le problème c'est que la modification de cet attribut n'est pas auditée ...
Et donc si une personne malveillante a eu accès a des droits de type "Schema Admins" sur votre environnement, il est possible que qu'elle est effectuée des modifications de ce type pour masquer ses prochaines actions sans que vous vous en rendiez compte ...

Alors on fait toujours confiance aux audits AD ?

Maintenant que l'on est complètement parano, voyons comment détecter ce type de modification.

Encore une fois je ne vais pas rentrer dans le détail, mais la solution c'est les metadata de réplication.
Un simple Repadmin nous donne l'information, l'attribut searchFlags a été modifié 2 fois.

Et si on regarde les metadata de notre OU on voit bien les modifications de la descripption et des ACL (DACL et SACL) :

Je vais m'arrêter ici pour ce premier article. Bien évidement l'attribut searchFlags n'est pas le seul attribut qu'il faut vérifier. Le next step est d'automatiser au maximum ces vérifications sans utiliser repadmin. Nous verrons ce point dans un autre article où je vous proposerai un outil pour effectuer ces vérifications.

A bientôt.