BAM vs UserAssist : deux preuves d'exécution par utilisateur

TL;DR. Les deux artefacts disent quel utilisateur a lancé quoi. BAM (ruche SYSTEM, par SID) capte les processus quelle que soit la façon dont ils ont été lancés — sauf chemins amovibles/réseau et programmes console lancés en ligne de commande — mais ne garde que le dernier horodatage, pendant une semaine environ. UserAssist (NTUSER.DAT de chaque utilisateur) ne voit que les lancements passés par le shell de l'Explorateur, mais ajoute compteur d'exécutions, compteur et temps de focus, et les garde bien plus longtemps. Quand ils divergent, la différence tient en général au mode de lancement.

La plupart des comparatifs placent BAM à côté d'artefacts globaux au système (Prefetch, ShimCache, Amcache). Le voisin le plus intéressant est pourtant UserAssist, l'autre grand artefact d'exécution par utilisateur. Pour le contexte sur BAM : le guide complet BAM/DAM.

En un coup d'œil

	BAM	UserAssist
Ruche	`SYSTEM` (un fichier par machine)	`NTUSER.DAT` (un par profil utilisateur)
Clé	`Services\bam\State\UserSettings\<SID>`	`Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist\{GUID}\Count`
Attribution	Nom de clé = SID	La ruche appartient à l'utilisateur
Nom de valeur	Chemin de périphérique NT ou nom de package	Chemin obscurci en ROT13, souvent avec un GUID de Known Folder
Horodatages	Un FILETIME (dernière activité enregistrée)	FILETIME de dernière exécution
Compteurs	Aucun	Nombre d'exécutions, compteur de focus, temps de focus
Ce qui est enregistré	Processus vus par `bam.sys` (Windows 10 1709+)	Lancements via le shell de l'Explorateur
Rétention	~7 jours, purge au démarrage	Longue
Angles morts	Chemins amovibles/réseau, outils console en ligne de commande	Tout ce qui n'est pas lancé via l'Explorateur

Sources : Suhanov, BAM internals ; libyal winreg-kb, UserAssist ; Didier Stevens, UserAssist.

UserAssist en deux minutes

Sous UserAssist, chaque sous-clé GUID suit une catégorie ; à partir de Windows 7, {CEBFF5CD-ACE2-4F4F-9178-9926F41749EA} couvre les lancements d'exécutables et {F4E57C4B-2036-45F0-A9AB-443BCFE33D9F} les lancements de raccourcis (libyal). Les noms de valeur sont le chemin du programme avec un ROT13 appliqué aux lettres — P:\Jvaqbjf\... signifie C:\Windows\.... Les chemins commencent souvent par un GUID de Known Folder au lieu d'une lettre de lecteur.

Les données (72 octets à partir de Windows 7) contiennent un compteur d'exécutions à l'offset 4, un compteur de focus à l'offset 8, le temps de focus à l'offset 12 et le FILETIME de dernière exécution à l'offset 60 (libyal). libyal liste ce que la clé suit : lancements via le Panneau de configuration, le menu Démarrer et les raccourcis, la boîte Exécuter, les raccourcis clavier, la Quick Launch et autres chemins de l'Explorateur.

Décoder un nom de valeur à la main

Le ROT13 décale chaque lettre de 13 positions et laisse chiffres et ponctuation intacts : il est donc son propre inverse. Prenez ce nom de valeur UserAssist :

P:\Jvaqbjf\Flfgrz32\pzq.rkr

Décalez les lettres de 13 et vous obtenez C:\Windows\System32\cmd.exe. Tous les outils UserAssist le font pour vous, mais reconnaître cette forme aide quand vous parcourez une ruche brute dans une visionneuse, ou quand une recherche de cmd.exe sur la ruche brute ne renvoie rien : le nom en clair n'y est pas stocké.

BAM en deux minutes

Une clé par SID dans la ruche SYSTEM, un REG_BINARY par exécutable, les 8 premiers octets étant un FILETIME mis à jour au lancement et à la fin du processus ; environ sept jours de rétention ; rien pour les supports amovibles ni les partages réseau (Suhanov). Détails : où se trouve la clé BAM et le format des valeurs.

Là où ils divergent — et pourquoi

Vu dans	Cause typique
BAM seulement	Lancé par un script, une ligne de commande (programmes non console), un service ou une tâche s'exécutant sous l'utilisateur, une exécution à distance ; ou UserAssist a été vidé
UserAssist seulement	Plus ancien que la semaine de BAM ; lancé depuis une clé USB ou un partage réseau (lancement via l'Explorateur, mais BAM exclut le chemin) ; exécutable supprimé puis machine redémarrée
Les deux	Lancé récemment via l'Explorateur depuis un disque local
Aucun	Programme console démarré depuis `cmd.exe`/PowerShell, ou les deux nettoyés

La première ligne est celle où BAM justifie sa place : les outils d'attaque passent rarement par le menu Démarrer. Dans le cas fictif de mouvement latéral, PsExec64.exe et rclone.exe sous svc_backup sont exactement le type de lancements qu'on ne s'attend pas à voir dans UserAssist, alors que BAM les montre.

La deuxième ligne est celle où UserAssist justifie la sienne : l'historique. Quand l'incident a commencé trois semaines avant la collecte, BAM est sans doute vide pour la première phase, tandis qu'UserAssist peut encore montrer la première exécution d'un outil avec son compteur.

Ruches différentes, collectes différentes

BAM : une ruche SYSTEM (+ journaux) couvre tous les utilisateurs de la machine.
UserAssist : un NTUSER.DAT (+ ntuser.dat.LOG1/LOG2) par profil, sous C:\Users\<nom>\. Les profils supprimés emportent leur UserAssist avec eux ; les clés BAM de ce SID vivent dans SYSTEM et peuvent donc survivre au profil jusqu'à leur purge.

Une collecte KAPE avec les cibles registre récupère en général les deux (KapeFiles). Notre BAM/DAM Parser couvre le côté SYSTEM ; les artefacts de NTUSER.DAT comme UserAssist se lisent avec Registry Parser ou les outils de la comparaison des parseurs.

Horodatages : comparer avec prudence

Les deux sont des FILETIME en UTC, mais ils ne signifient pas la même chose :

La dernière exécution UserAssist est écrite quand l'Explorateur lance le programme.
BAM est mis à jour à la création et à la fin du processus : pour une même exécution, son heure peut être postérieure à celle d'UserAssist si le programme est resté ouvert.

Une heure BAM postérieure de quelques heures à l'heure UserAssist pour le même chemin n'est donc pas une contradiction ; ce peut être la fermeture du programme.

Anti-forensique

Les deux sont des données de registre ordinaires. Les valeurs UserAssist peuvent être supprimées par l'utilisateur ou par des utilitaires de nettoyage, puisque la ruche lui appartient ; les entrées BAM peuvent être supprimées avec des privilèges suffisants et disparaissent d'elles-mêmes au bout d'une semaine, ou quand l'exécutable est supprimé et la machine redémarrée (limites de BAM). Un utilisateur dont UserAssist est vide alors que BAM montre des programmes d'allure interactive (navigateur, Office) mérite un second regard.

Check-list d'investigation

Analysez BAM pour chaque SID de la machine (une seule ruche SYSTEM les couvre tous).
Analysez UserAssist dans le NTUSER.DAT de chaque profil, y compris ceux des comptes que vous jugez sans intérêt.
Pour chaque programme d'intérêt, notez : présent dans BAM ? dans UserAssist ? compteur ? dernières heures dans les deux ?
Expliquez chaque divergence avec le tableau ci-dessus (mode de lancement, ancienneté, type de chemin) avant de crier au suspect.
Faites intervenir Prefetch et les journaux d'événements pour les lignes qui ne collent toujours pas.

Questions fréquentes

Quelle est la différence entre BAM et UserAssist ?

BAM se trouve dans la ruche SYSTEM, une clé par SID, avec un seul horodatage récent par exécutable et environ une semaine de rétention. UserAssist se trouve dans le NTUSER.DAT de chaque utilisateur, enregistre les lancements passés par le shell de l'Explorateur, et conserve un compteur, un temps de focus et une heure de dernière exécution bien plus longtemps.

Pourquoi un programme apparaît-il dans BAM mais pas dans UserAssist ?

UserAssist enregistre les lancements passant par le shell de l'Explorateur (menu Démarrer, bureau, raccourcis, boîte Exécuter). Les programmes démarrés par un script, une ligne de commande, un service ou un outil distant n'empruntent pas ces chemins, mais peuvent tout de même produire une entrée BAM.