Descripteurs de sécurité $Secure:$SDS

Présentation

Depuis NTFS 3.0 (Windows 2000), les descripteurs de sécurité ne sont plus stockés dans l'enregistrement MFT de chaque fichier. Ils sont dédupliqués dans un fichier système unique, $Secure (enregistrement MFT 9), et chaque fichier ne conserve qu'un Security ID de 32 bits dans son attribut $STANDARD_INFORMATION. $Secure comporte trois parties :

• $SDS (flux de données) : les descripteurs eux-mêmes, chacun avec son hash, son Security ID et son décalage.
• $SII (index) : associe un Security ID au décalage et à la taille du descripteur dans $SDS.
• $SDH (index) : associe le hash d'un descripteur à son décalage, pour que NTFS réutilise un descripteur existant au lieu de le dupliquer.

Pour l'enquêteur, $SDS permet de répondre à « à qui appartient ce fichier et qui pouvait y accéder » à partir d'une image disque, sans monter le volume ni interroger Windows.

Emplacement

$Secure est à la fois un fichier (il possède un flux $DATA) et un objet de type dossier (il possède des attributs d'index), ce qui trompe certains collecteurs basés sur des motifs de chemin. Les copies collectées sont en général nommées $Secure_$SDS.

Ce que l'artefact prouve

• Propriété : le SID propriétaire de tout fichier dont vous connaissez le Security ID grâce à la $MFT. Résolvez ensuite le SID en compte avec la SAM ou les données du domaine.
• Permissions : la DACL (qui peut lire, écrire, exécuter) et la SACL (audit) appliquées au fichier.
• Contrôles d'accès inhabituels : fichiers avec des ACE explicites « Tout le monde : contrôle total », ou fichiers possédés par un compte utilisateur dans des dossiers système.
• Il ne prouve pas que le propriétaire a créé ou ouvert le fichier. La propriété peut être prise ou modifiée, et les fichiers écrits par des processus élevés ou système appartiennent souvent à Administrateurs ou SYSTEM plutôt qu'à l'utilisateur connecté. $SDS ne contient aucun horodatage.

Champs clés

Horodatages

Rétention et effacement

• Un même descripteur sert à tous les fichiers ayant le même propriétaire et la même ACL : le flux contient bien moins d'entrées que le volume ne compte de fichiers.
• Modifier le propriétaire ou l'ACL d'un fichier lui attribue un autre Security ID (un descripteur identique existant ou un nouveau) ; l'ancien descripteur reste dans le flux si d'autres fichiers l'utilisent.
• L'enregistrement MFT d'un fichier supprimé conserve son Security ID : vous pouvez donc tenter de retrouver le propriétaire dans $SDS.
• Aucune commande utilisateur ne vide $SDS ; il n'est reconstruit qu'au reformatage du volume.

Collecte

• Cible KAPE : $SDS (collecte $Secure:$SDS ; incluse aussi dans FileSystem)
• Velociraptor (Windows.Triage.Targets) : $SDS. L'artefact dédié Windows.Triage.SDS remonte le flux en lisant directement l'enregistrement MFT 9, ce qui évite le problème de motifs évoqué plus haut.
• Commandes natives : $SDS est illisible via l'API Windows. Sur un système en fonctionnement, Windows indique toutefois le propriétaire et l'ACL actuels d'un fichier, utiles pour comparer avec l'analyse hors ligne :

Get-Acl C:\Users\Public\tool.exe | Format-List Owner,AccessToString
icacls C:\Users\Public\tool.exe
cmd /c dir /q C:\Users\Public

Outils d'analyse

• MFTECmd (Eric Zimmerman) : MFTECmd.exe -f E:\C\$Secure_$SDS --csv E:\out liste chaque descripteur avec Id, SID propriétaire et de groupe, indicateurs de contrôle, nombre et types d'ACE. --ds 0x100 détaille un Security ID. Joignez la colonne Id à la colonne SecurityId de la sortie $MFT de MFTECmd.
• Velociraptor : Windows.Triage.SDS pour collecter le flux sur les postes en fonctionnement en vue d'une analyse hors ligne.

Conseils d'investigation

• Pour chaque fichier suspect de la sortie $MFT, relevez son SecurityId, cherchez le SID propriétaire dans le CSV $SDS, puis associez ce SID à un profil utilisateur : un moyen rapide d'attribuer des outils déposés à un compte.
• Regroupez les fichiers par Security ID : un dossier malveillant dont tous les fichiers partagent un descripteur inhabituel (par exemple possédés par un utilisateur standard dans C:\Windows) ressort nettement.
• Cherchez les descripteurs accordant l'écriture à Tout le monde, Utilisateurs ou Utilisateurs authentifiés sur des exécutables ou binaires de service : signe de permissions affaiblies pour de la persistance ou une élévation de privilèges.
• Datez la modification d'ACL grâce aux enregistrements SECURITY_CHANGE du journal USN.
• Les enregistrements du journal USN portent aussi un SecurityId : des fichiers visibles seulement dans le journal (déjà supprimés, voir aussi le slack $I30) peuvent encore être rattachés à un propriétaire.