Registry Parser
← Tous les articles

NTUSER.DAT vs SOFTWARE vs SYSTEM : quelle ruche répond à quelle question

8 min de lecture

L'erreur la plus courante en triage du registre est de prendre la mauvaise ruche. Pas l'échec à prendre une ruche. Prendre une ruche et supposer qu'elle répondra à une question qui vit dans un autre fichier. La carte ci-dessous est celle que j'aurais aimé qu'on m'épingle à côté de mon bureau lors de ma première année.

Les cinq ruches qui comptent

Il y a plus de cinq ruches sur un système Windows, mais cinq portent le poids d'une investigation réelle :

  • C:\Windows\System32\config\SYSTEM : services, drivers, ControlSet vivant, configuration matérielle, Shimcache, identifiants de service de liste de réseaux.
  • C:\Windows\System32\config\SOFTWARE : applications installées, clés Run machine-wide, Winlogon, AppCompatFlags, la carte d'association de fichiers.
  • C:\Windows\System32\config\SECURITY : politique de sécurité locale, configuration d'audit, identifiants de domaine en cache.
  • C:\Windows\System32\config\SAM : comptes utilisateurs locaux, appartenances aux groupes, hashs de mots de passe (besoin de SYSTEM pour déchiffrer).
  • C:\Users\<user>\NTUSER.DAT : paramètres par utilisateur, UserAssist, RecentDocs, clés Run par utilisateur, TypedPaths, RunMRU.

Plus une autre qui est souvent oubliée :

  • C:\Users\<user>\AppData\Local\Microsoft\Windows\UsrClass.dat : enregistrements de classes par utilisateur, y compris ShellBags sous Windows moderne.

Chacune a une paire de journaux de transactions (.LOG1, .LOG2). Prenez-les. Si vous oubliez, vous choisissez d'ignorer les écritures en cours.

SYSTEM : le système nerveux de la machine

SYSTEM est où vous allez quand la question implique services, drivers, périphériques, configuration de démarrage, ou la chronologie locale. Le ControlSet actif est référencé via Select\Current (un DWORD pointant vers ControlSet001, ControlSet002, ou rarement un numéro plus élevé).

Ce qui vit ici :

  • ControlSet001\Services\ : chaque service et driver, avec ImagePath, ServiceDll, Start, et le descripteur de sécurité. La persistance se cache souvent ici en tant que faux service.
  • ControlSet001\Control\Session Manager\AppCompatCache\AppCompatCache : le Shimcache. Liste les exécutables qui ont été sur le système, avec leurs tailles dérivées du MFT et un drapeau "last update". Crucial pour trouver les binaires depuis supprimés.
  • ControlSet001\Control\TimeZoneInformation : le fuseau horaire configuré pour l'hôte. Vous en aurez besoin pour interpréter chaque autre horodatage sur le système. Trompez-vous et vous lirez les preuves de travers de plusieurs heures.
  • ControlSet001\Control\ComputerName\ComputerName\ComputerName : le nom d'hôte. Moins trivial qu'il n'y paraît quand vous travaillez depuis des ruches acquises et avez besoin de savoir quel hôte vous regardez.
  • ControlSet001\Services\Tcpip\Parameters\Interfaces\<GUID> : configurations IP historiques.
  • MountedDevices : attributions de lettres de lecteur et leurs identifiants de volume, utile pour corréler avec l'historique des périphériques USB.
  • Setup\ : métadonnées d'installation initiale, y compris la date d'installation d'origine et l'identifiant du média source.

Si vous n'aviez le temps que de prendre une ruche sur une affaire de persistance de service, c'est SYSTEM.

SOFTWARE : le monde des applications de la machine

SOFTWARE est la grosse pour la persistance de malware et les empreintes d'applications. C'est aussi la plus grande des ruches standard de loin, ce qui signifie que les outils sans bonne indexation prendront plus de temps ici que partout ailleurs.

Où chercher :

  • Microsoft\Windows\CurrentVersion\Run et RunOnce : autoruns machine-wide. Premier endroit où regarder sur tout hôte compromis.
  • Microsoft\Windows NT\CurrentVersion\Winlogon : les valeurs Userinit, Shell, Notify, et LegalNoticeCaption. Userinit modifié est une vieille technique qui marche encore.
  • Microsoft\Windows NT\CurrentVersion\Image File Execution Options\ : la clé débogueur IFEO, abusée pour les détournements de fonctionnalités d'accessibilité.
  • Microsoft\Windows NT\CurrentVersion\ProfileList\<SID> : chaque profil qui s'est connecté à l'hôte, avec le SID, le chemin du nom d'utilisateur, et l'horodatage de dernier chargement. Le moyen le plus rapide d'énumérer les utilisateurs depuis des ruches hors ligne.
  • Microsoft\Windows\CurrentVersion\Uninstall\ : logiciels installés, avec noms d'affichage, dates d'installation, et (parfois) chemins d'installation. Utile pour distinguer applications légitimes des choses qui prétendent être des logiciels installés.
  • Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles\<GUID> : chaque réseau auquel l'hôte s'est connecté, avec le SSID, le MAC de la passerelle, et l'heure de dernière connexion. L'un des meilleurs artefacts de localisation d'hôte sur un endpoint itinérant.
  • Microsoft\Windows\CurrentVersion\Explorer\FileExts\<.ext> : associations d'extensions de fichier configurées par l'utilisateur. Utile pour attraper les détournements d'extensions.

SOFTWARE est aussi où vit AmCache, dans une ruche séparée à C:\Windows\AppCompat\Programs\Amcache.hve. Certains oublient que AmCache est une ruche. Elle l'est. Traitez-la comme tout autre fichier regf.

NTUSER.DAT : par utilisateur, par investigation

L'erreur la plus courante que je vois est de se tourner vers HKLM\Software\Microsoft\Windows\CurrentVersion\Run (ruche SOFTWARE) et de s'arrêter là. L'équivalent par utilisateur est à HKCU\Software\Microsoft\Windows\CurrentVersion\Run, qui vit dans NTUSER.DAT pour l'utilisateur en question. La persistance peut être dans l'un, l'autre, ou les deux. Sur un malware en contexte utilisateur, elle est presque toujours dans le NTUSER de l'utilisateur.

Ce qui vit dans NTUSER :

  • Software\Microsoft\Windows\CurrentVersion\Run et RunOnce : autoruns par utilisateur.
  • Software\Microsoft\Windows NT\CurrentVersion\Windows\Load et Run : valeurs de chargement par utilisateur. Rares en usage légitime.
  • Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist\ : l'historique de lancement de programmes encodé en ROT13. Meilleur artefact d'exécution par utilisateur du système.
  • Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs : fichiers que l'utilisateur a ouverts, par extension.
  • Software\Microsoft\Windows\CurrentVersion\Explorer\TypedPaths : chaque chemin tapé dans Explorer.
  • Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU : chaque commande Win+R. Mine d'or.
  • Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\OpenSavePidlMRU : historique du sélecteur de fichiers sur les apps natives.
  • Software\Microsoft\Office\<version>\<app>\User MRU\ : fichiers récents d'Office, par app. Les sous-clés de version gardent l'historique à travers les mises à niveau d'Office.
  • Software\Microsoft\Terminal Server Client\Default : historique d'hôtes cibles RDP.

Si l'investigation est "qu'a fait cet utilisateur", vous vivez dans NTUSER. Si "qu'est-ce qui tournait sur cet hôte", SYSTEM et SOFTWARE.

Le piège : NTUSER est chargé dans le registre sous HKEY_USERS\<SID> uniquement pendant que l'utilisateur est connecté. Si l'utilisateur n'est pas connecté, la ruche est sur disque mais le noyau en cours n'en a aucune vue. Les outils qui lisent depuis le registre vivant plutôt que le fichier manqueront tout pour les utilisateurs non connectés. C'est la raison la plus courante pour qu'une investigation manque silencieusement la persistance.

UsrClass.dat : la seconde ruche par utilisateur

UsrClass.dat est la contrepartie par utilisateur de la ruche de classe machine. Elle vit à côté de NTUSER mais vous devez savoir la prendre séparément. La plupart des scripts d'acquisition qui disent "prendre NTUSER" ne prennent pas UsrClass sans être explicitement dirigés.

Ce qui vit ici :

  • Local Settings\Software\Microsoft\Windows\Shell\BagMRU et Bags : ShellBags modernes. Sur Windows 7 et ultérieur, c'est ici que vivent les données Bag significatives, pas dans NTUSER. Les outils qui ne regardent que dans NTUSER vous donneront une vue fragmentaire.
  • Local Settings\MuiCache : noms d'affichage en cache pour les exécutables avec lesquels l'utilisateur a interagi via Explorer.
  • Diverses inscriptions de classes spécifiques aux apps par utilisateur.

Si ShellBags compte pour votre affaire, vous avez besoin de UsrClass. L'investigation s'effondrera sans.

SAM et SECURITY : les ruches d'identifiants

SAM tient l'information de compte local. SECURITY tient la politique locale et les identifiants de domaine en cache. Les deux sont chiffrés avec des clés dérivées du sous-arbre LSA\ de SYSTEM, ce qui signifie que le déchiffrement nécessite SYSTEM. Acquérez toujours les trois ensemble. Les séparer est un piège de flux qui attrape les nouveaux enquêteurs.

Clés utiles :

  • SAM\Domains\Account\Users\ : comptes locaux, avec horodatages de dernière connexion, changement de mot de passe, et drapeaux de compte.
  • SAM\Domains\Account\Aliases\Members\ : appartenances aux groupes locaux.
  • SECURITY\Cache\ : identifiants de domaine en cache (MSCASH/DCC2).
  • SECURITY\Policy\Secrets\ : secrets LSA, y compris mots de passe de comptes de service stockés en clair.

Confusions courantes

Trois reviennent sur presque chaque affaire :

Les clés Run existent dans HKLM et HKCU. Quand vous triez Run, vous triez les deux. SOFTWARE a la valeur machine-wide ; les fichiers NTUSER.DAT par utilisateur ont les valeurs par utilisateur. La persistance peut vivre dans l'une, parfois les deux, parfois uniquement la seconde sur une infection en contexte utilisateur qui n'a jamais obtenu admin.

ShellBags a déménagé. Sur Windows 7+ les données bag significatives sont dans UsrClass.dat. Les outils écrits contre les ruches de l'ère XP regardent dans NTUSER et manquent tout.

ControlSet versus CurrentControlSet. HKLM\SYSTEM\CurrentControlSet\ est un lien symbolique. Les vraies données sont dans ControlSet001 (généralement). Quand vous analysez la ruche SYSTEM hors ligne, vous devez lire Select\Current pour savoir quel ControlSet est vivant, puis lire celui-là. Lire CurrentControlSet directement échouera car le lien symbolique n'existe pas sur disque.

Un ordre de triage qui marche

  1. Acquérir SYSTEM, SOFTWARE, SECURITY, SAM, chaque NTUSER.DAT, chaque UsrClass.dat, plus tous leurs .LOG1/.LOG2.
  2. Résoudre le fuseau horaire (SYSTEM Control\TimeZoneInformation) avant de lire le moindre horodatage.
  3. Énumérer les utilisateurs (SOFTWARE Microsoft\Windows NT\CurrentVersion\ProfileList) pour savoir quels fichiers NTUSER correspondent à quels comptes.
  4. Trier la persistance machine-wide dans SOFTWARE et SYSTEM. Recouper avec Prefetch, AmCache, et Shimcache.
  5. Trier l'activité par utilisateur dans chaque NTUSER. Regardez UserAssist, RecentDocs, TypedPaths, RunMRU. Pivotez vers les fichiers LNK et jump lists pour l'accès aux fichiers.
  6. ShellBags depuis UsrClass pour l'historique de navigation.

Faire cela dans le mauvais ordre marche bien. Sauter l'un des six vous mord au troisième appel quand la question se pose et qu'il faut retourner à l'hôte.

Pour aller plus loin

Savoir quelle ruche tient quelle question est la différence entre un triage de quinze minutes et un après-midi de grep sur le mauvais fichier.