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

Bonjour à tous.

On continue notre série sur les Metadata de réplication.
Je vous ai parlé rapidement dans la Partie 2  de l'attribut msDS-ReplValueMetaData.

Pour bien comprendre on va repartir des bases.
On va commencer par voir rapidement comment sont stockées les données dans la base Active Directory.

Comme vous le savez sûrement la base Active Directory est stockée physiquement dans le fichier ntds.dit (avec les fichiers de logs qui lui sont associés).

Ce que peu de personnes savent c'est comment sont organisées les données dans ce fichier.

Si l'on se réfère au technet (Data Store Physical Structure), le fichier ntds.dit contient 3 tables : Data Table, Link Table et SD Table

En réalité la base de données Active Directory contient 12 tables.
Christoffer Andersson a publié une série d'articles sur le sujet et il liste toutes les tables dans son premier article sur le sujet : How the Active Directory – Data Store Really Works (Inside NTDS.dit) – Part 1

Si vous avez déjà joué avec Esentutl (à faire en lab), il est déjà possible d'avoir des informations sur le contenu du fichier ntds.dit en utilisant les paramètres de dump (Esentutl /file dump)

On récupère donc déjà pas mal d'informations (tables et index) sur le contenu de la base.

Il est aussi possible de faire un dump de la base avec ldp, How to Use the Online Dbdump Feature in Ldp.exe

Faire ce type de dump est très intéressant pour comprendre la structure et le fonctionnement de la base Active Directory.

Pour aller encore plus loin, il est possible d'utiliser libesedb pour dumper le contenu de toutes les tables.

Une fois le dump effectué, on dispose de toutes les tables de la base.

Si on ouvre par exemple le fichier de la table sd_table.

Pas très lisible au premier abord mais facilement interprétable lorsque l'on s'est penché sur le sujet.

Mais revenons à nos 3 tables, la table qui nous intéresse aujourd'hui est la table Link Table.
Cette table contient les attributs liés (Linked Attributes). L'attribut lié qui nous intéresse ici est l'attribut Member.

Avant Windows Server 2003, lorsqu'un changement était effectué par exemple dans les membres d'un groupe, c'était tout le contenu de l'attribut member qui était répliqué. Si j'avais un groupe avec 1000 membres et que j'en ajoutais 1, tout le contenu de l'attribut Member (1001 groupes) était répliqué.
Windows Server 2003 a introduit un nouveau mécanisme de réplication appelé Linked Value Replication (LVR) qui permet de répliquer les valeurs individuels et non la totalité.

Vous vous demandez peut-être c'est quoi le rapport avec l'audit Forensic Active Directory ?
Qui dit réplication, dit Metadata de réplication.
Avant 2003 je n'aurais eu que la date de dernier changement de l'attribut Member ce qui n'est pas très intéressant.
Avec le mécanisme LVR, j'ai les metadata au niveau de chaque valeur contenue dans l'attribut Member et je peux donc savoir quand un objet a été ajouté ou supprimé de l'attribut Member.

Imaginons que je veux auditer un AD, je vais bien évidemment auditer les groupes à privilèges.

On va donc commencer par lister les membres de ces groupes, par exemple le groupe Domain Admins.

Ok il n'y a que Administrator dedans c'est un bon début.
Mais s'arrêter à ce niveau serait une grave erreur.

Maintenant si je veux savoir qui a été membre de ce groupe ?
Il va falloir rechercher les logs (si l'audit est en place) et tout consolider.
Pas simple et dépendant de beaucoup de facteurs.
Pour gagner du temps on va à nouveau se servir des Metadata de réplication.

On va commencer par réutiliser Repadmin avec le paramètre /ShowObjMeta

On voit dans la seconde partie les membres du groupe et on peut noter qu'un utilisateur nommé Intruder a été membre de ce groupe ce qui est très suspicieux ...

Vous noterez que par défaut l'attribut Member n'est pas renvoyé par la commande Repadmin. Pour cela il faut ajouter le paramètre /Linked.

Le format de sortie de repadmin n'étant pas facilement exploitable, nous allons voir d'autres méthodes.

Tout d'abord avec Windows Server 2012.
Comme nous l'avons vu dans l'article précédent, il existe une Cmdlet dédiée.

C'est très simple de retrouver l'information.

Pour 2008 R2, c'est un peu plus compliqué, c'est ici que nous allons utiliser l'attribut msDS-ReplValueMetaData


Pour récupérer les informations j'ai fait la fonction suivante :

Function Get-ADGroupMembershipMetadata {

 Param(

        [Parameter(Mandatory=$true,Position=1)]

        [String] $GroupDN

        )

    ### Chargement du module ActiveDirectory

    try { Import-Module ActiveDirectory |Out-Null}

    catch { Write-Warning "Cannot load ActiveDirectory module."; Break }

    $Group = Get-ADObject $GroupDN -Properties "msDS-ReplValueMetaData"

    $ReplValueMetaData = $Group."msDS-ReplValueMetaData"

    $ReplValueMetaData = "<root>" + $ReplValueMetaData + "</root>"

    $ReplValueMetaData = $ReplValueMetaData.Replace([char]0," ")

    $ReplValueMetaData = [XML]$ReplValueMetaData

    $ReplValueMetaData = $ReplValueMetaData.root.DS_REPL_VALUE_META_DATA

    $TabMembersMetadata = @()

    $ReplValueMetaData | Foreach {

        $obj = New-Object psobject

        $obj |Add-Member -type NoteProperty -name ObjectDN -value $_.pszObjectDn

        $obj |Add-Member -type NoteProperty -name TimeCreated -value $_.ftimeCreated

        $obj |Add-Member -type NoteProperty -name TimeDeleted -value $_.ftimeDeleted

        $obj |Add-Member -type NoteProperty -name Version -value $_.dwVersion

        $obj |Add-Member -type NoteProperty -name TimeLastOriginatingChange-value $_.ftimeLastOriginatingChange

        $obj |Add-Member -type NoteProperty -name LastOriginatingDsaDN -value $_.pszLastOriginatingDsaDN

        $TabMembersMetadata += $obj

        }

    $TabADGroupMembershipMetadata = New-Object psobject

    $TabADGroupMembershipMetadata |Add-Member -type NoteProperty -name ObjectDN -value $GroupDN

    $TabADGroupMembershipMetadata |Add-Member -type NoteProperty -name Members -value $TabMembersMetadata

    return $TabADGroupMembershipMetadata

    }

Si on reprend notre exemple :

On arrive bien à récupérer les informations.

Maintenant quelques remarques concernant cette méthode.

Tout d'abord, les informations restent disponibles le temps du Tombstone.
En effet, lorsqu'un membre est enlevé d'un groupe, il est marqué comme étant supprimé. L'objet sera supprimé à l'issue du Tombstone.


Ensuite, le lien est supprimée lorsque le membre est supprimé.
Christoffer Andersson a fait un très bon article sur le sujet (How deletion/removal of data really works in Active Directory)

Reprenons notre exemple :

Sauf si vous avez activé la Corbeille Active Directory :

On va s'arrêter ici pour aujourd'hui.

On voit une fois de plus que les Metadata de réplication peuvent être "détournée" de leurs objectifs premiers et se révéler  très utile lors d'audit de type Forensic.

Les Metadata de réplication ont encore beaucoup de chose à nous apprendre, nous verrons cela dans la suite de l'article.

J'espère en tout cas que cet article vous aura intéressé.
A très bientôt.