← Retour au blog

Anti-forensique NTFS : ce que les attaquants font vraiment, et ce qui les trahit

· Lecture 8 min

Chaque technique anti-forensique sous NTFS laisse quelque chose derrière. La raison est structurelle. La MFT, le journal USN, $LogFile et les Volume Shadow Copies enregistrent chacun une vue différente des mêmes événements, et modifier l'un d'eux est lui-même un événement que les autres enregistrent. Un attaquant qui se cache d'un artefact s'allume presque toujours sur un autre. Un défenseur qui parcourt les quatre ensemble est difficile à battre.

Voici le catalogue. Pour chaque technique : ce que font les attaquants, quel résidu cela laisse, et quel artefact les trahit.

Timestomping

Le classique. Des outils comme SetMACE, timestomp, les scripts PowerShell Invoke-TimeStomp bien connus et un nombre quelconque d'auxiliaires red team appellent SetFileTime ou écrivent directement $STANDARD_INFORMATION pour faire paraître un fichier plus vieux ou plus récent qu'il n'est. Les variantes récentes touchent aussi $FILE_NAME en renommant le fichier (ce qui force NTFS à mettre à jour FN) puis en le renommant à nouveau. Le truc du « double renommage » est ce qui sépare un opérateur compétent d'un script kiddie.

Ce qui le trahit :

  • Divergence SI/FN. Un SetFileTime simple ne touche que SI. Les horodatages FN correspondants sont toujours les vraies heures de création/renommage. Voir les quatre horodatages MFT. Tout enregistrement où SI created est à plus de quelques secondes de FN created est suspect. Quand SI created précède FN created, c'est naturellement impossible : les fichiers ne peuvent pas exister avant d'être nommés.
  • Granularité sous-seconde. NTFS stocke les horodatages en ticks de 100 nanosecondes. Les opérations natives laissent du bruit dans les chiffres du bas. La plupart des outils de timestomping arrondissent à la seconde. Une colonne de suffixes .0000000 alignés à travers plusieurs fichiers est une empreinte.
  • Vérité de $UsnJrnl. Le journal USN enregistre l'heure réelle de modification quand les entrées sont écrites. Un DATA_OVERWRITE USN pour l'attribut $DATA d'un enregistrement avec un horodatage qui ne correspond pas à l'heure SI modified de la MFT est un timestomping pris la main dans le sac.
  • Snapshots VSS. Les Volume Shadow Copies plus anciennes contiennent les valeurs antérieures au stomp. Diffez la $MFT actuelle contre la $MFT du snapshot pour le même enregistrement et le changement est visible.

Le truc du double renommage vainc la divergence SI/FN. Il ne vainc ni les entrées du journal USN ni les diffs VSS.

Alternate Data Streams comme cache de charge utile

Un attribut $DATA avec un nom (legit.docx:payload.exe) est invisible à Explorer, invisible à dir, et utilisé en routine pour planquer des exécutables, des scripts ou de la configuration encodée que le fichier visible ne trahit pas. Lancé via wmic process call create, rundll32 ou Get-Content -Stream plus Invoke-Expression.

Ce qui le trahit :

  • Les parcours de la MFT exposent tous les attributs $DATA. L'énumération par fichier rate les flux sur les fichiers que vous n'avez pas pensé à vérifier. La MFT, non. Voir alternate data streams.
  • Sysmon Event ID 15 (FileCreateStreamHash) est le seul événement Sysmon qui hache la création d'ADS. Si Sysmon est déployé et configuré, ça attrape les dépôts de flux directement.
  • Zone.Identifier. Les téléchargements depuis un navigateur portent cet ADS. Un binaire dans \Downloads\ qui en est dépourvu n'est jamais venu d'un navigateur, ou a été délibérément dépouillé (Unblock-File).

Effacer un seul fichier

Les wipers sophistiqués écrasent les clusters du fichier puis suppriment l'enregistrement MFT. Les moins sophistiqués (SDelete par défaut, cipher /w, del /f) écrasent les données mais laissent l'enregistrement MFT en place.

Ce qui le trahit :

  • L'enregistrement MFT lui-même. Un enregistrement supprimé avec $FILE_NAME et $STANDARD_INFORMATION intacts nomme toujours le fichier, donne son répertoire parent et montre les horodatages au moment de la suppression. Voir ce qui survit à une suppression.
  • Entrées de création et de suppression dans $UsnJrnl. Les deux événements sont enregistrés indépendamment du fait que les données ont été effacées.
  • $LogFile. Les enregistrements de transaction des opérations de métadonnées y restent jusqu'à la rotation.
  • Snapshots VSS. Si un snapshot existait avant le wipe, le fichier y est intact.

Effacer l'enregistrement MFT lui-même

Un attaquant plus agressif écrit de nouveaux fichiers spécifiquement pour forcer NTFS à réutiliser l'emplacement, écrasant l'enregistrement supprimé. Cela réussit : l'emplacement est parti. La suppression reste un événement.

Ce qui le trahit :

  • Incrément du numéro de séquence. Une référence depuis $UsnJrnl ou $LogFile à l'enregistrement R séquence S est maintenant obsolète ; l'enregistrement actuel est en séquence S+1. Un recoupement expose la réutilisation.
  • Historique $UsnJrnl. La création, la modification et la suppression d'origine sont toujours enregistrées. La création du nouveau fichier aussi. La réutilisation laisse une trace USN.
  • Snapshots VSS. Les copies snapshot de $MFT antérieures à la réutilisation contiennent toujours l'enregistrement d'origine à la séquence S.

Troncature de $UsnJrnl

Le journal des changements est fini. Un attaquant qui fait des opérations bruyantes (beaucoup d'écritures fichiers) peut forcer $UsnJrnl à boucler, évinçant les entrées plus anciennes. La taille par défaut est 32 Mo sur la plupart des installations ; plus grande sur Server.

Ce qui le trahit :

  • Un $UsnJrnl court avec une USN de départ élevée. Si le premier enregistrement du journal est de quelques heures ou minutes avant l'incident sur un hôte qui tourne depuis des semaines, il a été tourné anormalement vite. Calculez le taux attendu.
  • $LogFile ne tourne pas de la même manière. Il est dimensionné sur le volume et écrase selon une politique différente. Des opérations qui ont chassé le journal USN sont parfois encore dans $LogFile.
  • Les opérations bruyantes elles-mêmes laissent des milliers d'enregistrements MFT. Les milliers de fichiers brassés nécessaires pour boucler le journal sont visibles dans $MFT. La technique est bruyante.

Suppression de $UsnJrnl

fsutil usn deletejournal /D C: retire le journal entièrement. Le journal recréé commence avec un compteur USN frais. Le numéro de séquence de l'enregistrement MFT $Extend\$UsnJrnl est incrémenté pour refléter la suppression et recréation.

Ce qui le trahit :

  • Première USN suspectement élevée ou premier enregistrement suspectement récent. Un $UsnJrnl fraîchement créé dont le premier enregistrement postdate l'incident est un indice.
  • Numéro de séquence de l'entrée de répertoire $Extend incrémenté. L'enregistrement MFT de $UsnJrnl lui-même a une séquence plus haute que la baseline.
  • Snapshots VSS. Les snapshots antérieurs à la suppression contiennent toujours le journal complet d'origine. Montez-les avec vshadowmount et extrayez.

Renommer un malware avec un nom de fichier système

Cacher un outil sous svchost.exe, lsass.exe, cmd.exe, ou un autre binaire Windows familier. Pas strictement de l'anti-forensique MFT, mais c'est le truc qui embrouille le plus les analystes dans la nature.

Ce qui le trahit :

  • Référence au répertoire parent dans $FILE_NAME. Le svchost.exe légitime vit dans C:\Windows\System32. Un fichier portant ce nom dans \Users\bob\AppData\Local\Temp\ ne l'est pas. Vérifiez la référence parent, pas seulement le nom.
  • Taille et hash $DATA. Le binaire légitime est bien connu. Faites un SHA-256 sur l'imposteur et comparez. Les divergences sont immédiates.
  • ADS Zone.Identifier s'il a été téléchargé.
  • Signature de code. Les binaires Microsoft sont signés. Vérifiez la signature Authenticode sur le fichier on-disk ; l'imposteur n'en aura pas ou en aura une non-Microsoft.

Moins courant mais à connaître. Plusieurs attributs $FILE_NAME sur le même enregistrement MFT permettent à un attaquant de faire apparaître le même payload dans deux répertoires à la fois. Le supprimer d'un seul ne retire qu'un $FILE_NAME ; le fichier vit jusqu'à ce que le dernier link soit parti.

Ce qui le trahit :

  • Champ hardlink_count dans l'en-tête de l'enregistrement. Si un enregistrement a un compteur > 1, chaque $FILE_NAME est l'un des links. La MFT les montre tous.
  • Raison HARD_LINK_CHANGE dans $UsnJrnl à la création et au retrait de hard links.

Manipulation de $LogFile

fsutil n'offre pas d'option « supprimer le fichier log », mais le log tourne tout seul et les opérations qui remplissent le volume peuvent en chasser des entrées. Les opérateurs sophistiqués essaient occasionnellement de récurer $LogFile pour retirer les enregistrements de transaction autour d'un incident.

Ce qui le trahit :

  • $LogFile est verrouillé pendant que Windows tourne. Le manipuler nécessite de démonter le volume, ce qui est lui-même un événement.
  • Snapshots VSS d'avant la manipulation contiennent toujours le log complet.

Gribouillis ransomware dans la MFT

Certaines familles de ransomware (Petya, NotPetya, une poignée depuis) corrompent délibérément $MFT pour rendre le volume non montable. C'est destructif plutôt qu'évasif ; l'objectif est le déni de service, pas la furtivité.

Ce qui le trahit :

  • Enregistrements BAAD où devrait se trouver FILE. La pierre tombale de chkdsk pour les enregistrements irréparables est ce que NTFS laisse après le wipe. Parfois le gribouilleur n'écrit pas BAAD, auquel cas les enregistrements sont non parsables mais scannables par signature.
  • Un système non bootable, mais une image forensiquement précieuse. Les clusters de données sont généralement intacts. Scannez par signature le volume pour les enregistrements FILE et la majeure partie de la table est lisible. Voir motifs de ransomware dans la MFT pour les détails.

Le principe général

Chaque technique anti-forensique sous NTFS laisse un artefact quelque part. La raison est structurelle : $MFT, $UsnJrnl, $LogFile et VSS enregistrent chacun une vue différente des mêmes événements. L'attaquant qui récure la MFT laisse des entrées USN. L'attaquant qui supprime le journal USN laisse un bump frais du numéro de séquence de $Extend\$UsnJrnl et des snapshots VSS intacts. L'attaquant qui lance vssadmin delete shadows laisse des entrées dans le journal d'événements Windows (System 8224, Application VSS 8194) et possiblement Sysmon Event ID 1 pour l'invocation de vssadmin.exe.

Un triage qui parcourt les quatre artefacts NTFS plus les journaux d'événements et VSS est ce qui attrape les opérateurs sophistiqués. Un triage à artefact unique les rate.

Lectures complémentaires

Articles liés

Ressources externes