Limites de BAM et anti-forensique : ce que BAM rate

TL;DR. BAM est précis mais oublieux et sélectif. La rétro-ingénierie publiée montre qu'il supprime au démarrage les entrées de plus de sept jours, retire celles dont l'exécutable a disparu, et ne crée pas d'entrée pour les supports amovibles, les partages réseau ni (d'après les observations) les programmes console lancés en ligne de commande. Il ne garde qu'un horodatage, sans hash ni compteur. Les attaquants profitent de la plupart de ces angles morts sans effort ; une altération délibérée est possible mais laisse des incohérences que l'on peut chercher.

Chaque artefact a ses défaillances ; le problème n'apparaît que lorsque le rapport ne les mentionne pas. Voici la liste que nous gardons à côté de chaque constat BAM. Pour le contexte : le guide complet BAM/DAM. La plupart des affirmations comportementales ci-dessous viennent de l'article BAM internals de Maxim Suhanov, basé sur les builds 18363 et 19592 de Windows 10 — retestez sur le build de votre preuve quand une conclusion en dépend.

Les angles morts intégrés

Rétention de sept jours

Suhanov a constaté que les entrées de plus de sept jours sont supprimées au démarrage, et a identifié un paramètre de durée de vie, UserSettingsLifetimeMs, dont la valeur par défaut correspond à sept jours. Les entrées dont l'utilisateur a modifié l'état de modération échappent à cette suppression par ancienneté (source).

Conséquences :

• Une machine redémarrée plus d'une semaine après l'activité a probablement perdu l'entrée.
• Une machine non redémarrée peut conserver des entrées de plus d'une semaine, puisque la purge a lieu au démarrage.
• Pour une activité plus ancienne, analysez les ruches SYSTEM des clichés instantanés de volume — chacun est un instantané de BAM au moment de la copie (présentation de VSS). Notre outil accepte plusieurs ruches SYSTEM à la fois et conserve le fichier source sur chaque ligne.

Exécutables supprimés ou déplacés

« Les entrées BAM peuvent être supprimées si un exécutable est retiré de son emplacement d'origine », et Suhanov a vu l'entrée disparaître après un redémarrage (source). Le réflexe classique de l'attaquant — lancer un outil puis le supprimer — efface donc la trace BAM au prochain démarrage. D'ici là, l'entrée reste. Un argument de poids pour collecter SYSTEM avant que quiconque ne redémarre la machine.

Supports amovibles et partages réseau

Suhanov a montré que bam.sys refuse de créer des entrées pour les exécutables situés sur des périphériques marqués comme distants ou amovibles (« les entrées BAM ne sont pas créées pour les exécutables sur supports amovibles et/ou partages réseau »). Les outils lancés depuis une clé USB ou depuis \\server\share\tool.exe n'apparaîtront pas.

Question ouverte que nous n'avons pas vu tester publiquement : les disques externes qui se présentent à Windows comme des disques fixes plutôt qu'amovibles. Si votre dossier en dépend, reproduisez avec le même matériel.

Pour ces exécutions, regardez plutôt Prefetch, Amcache, les fichiers LNK et les Jump Lists pour l'accès, et les artefacts de périphériques USB pour le support.

Programmes console lancés en ligne de commande

Suhanov a observé que « les applications console n'obtiennent pas d'entrée BAM si elles sont lancées depuis une session en ligne de commande », sans en identifier la cause. En pratique, whoami.exe, net.exe ou un outil d'attaque en console lancé depuis cmd.exe peuvent manquer alors que cmd.exe lui-même apparaît. Considérez l'absence d'un outil console comme non informative.

Un seul horodatage, aucun contexte

• Pas de première exécution, pas de compteur, pas de durée.
• L'heure est mise à jour à la création et à la fin du processus (source) : pour un programme resté ouvert longtemps, elle peut refléter sa fermeture.
• Ni hash, ni taille, ni signataire, ni ligne de commande, ni processus parent.
• Les chemins utilisent des noms de périphérique de volume, pas des lettres de lecteur (voir le format des valeurs).

Trous liés à l'acquisition

• Ruche dirty. Des écritures récentes peuvent se trouver dans SYSTEM.LOG1/LOG2. Rejouez-les avant de conclure à l'absence d'une entrée (emplacement de la clé).
• Mauvais control set. Lire ControlSet002 au lieu de celui indiqué par Select\Current donne un état plus ancien.
• Ancienne clé seulement. À partir de 1809, les données actuelles sont dans State\UserSettings ; un outil qui ne lit que bam\UserSettings voit un instantané figé (versions).

Anti-forensique délibérée

Les valeurs BAM sont des données de registre ordinaires. Un attaquant disposant de privilèges suffisants peut les modifier (MITRE ATT&CK T1112, Modify Registry ; T1070, Indicator Removal). Options réalistes, par effort croissant :

Nous n'avons pas testé quel niveau de privilège est nécessaire pour écrire dans ces clés sur les builds actuels ; vérifiez les permissions de la clé sur un système de référence au lieu de supposer que seul SYSTEM, ou n'importe quel administrateur, peut les modifier (sécurité des clés de registre).

Détecter une altération

1. Heure de la clé contre valeurs. L'heure de dernière écriture de chaque clé SID doit être proche de sa valeur la plus récente. Une clé écrite bien après toutes les valeurs restantes signifie que quelque chose a changé ensuite — peut-être une suppression. Notre parseur affiche cette heure dans le panneau de détail et l'exporte (SidKeyLastWriteUtc).
2. Comparer control sets et instantanés. Une entrée présente dans la ruche SYSTEM d'un cliché instantané mais absente de la ruche actuelle, alors que l'exécutable existe encore et que moins d'une semaine s'est écoulée, mérite une note.
3. Cohérence entre artefacts. Un outil présent dans Prefetch ou Amcache mais absent de BAM, sans qu'aucune des raisons naturelles ci-dessus ne s'applique, est une piste, pas une conclusion.
4. Télémétrie du registre. Les événements Sysmon 12 à 14 enregistrent la création/suppression d'objets de registre, l'écriture de valeurs et les renommages quand ils sont configurés (Sysmon) ; analysez-les avec EVTX Parser. La plupart des parcs ne surveillent pas spécifiquement la clé BAM : l'absence d'événements prouve peu.
5. Journaux de transactions. Une suppression juste avant l'acquisition peut rester visible en comparant la ruche avant et après le rejeu des journaux.

Formuler un constat BAM

• Présence : « Un enregistrement BAM sous le SID X indique chemin avec une dernière activité enregistrée à T UTC. »
• Absence : « Aucun enregistrement BAM n'a été trouvé pour chemin. BAM n'enregistre pas les exécutables situés sur supports amovibles ou partages réseau, purge au démarrage les entrées de plus de sept jours et retire celles des exécutables supprimés avant un redémarrage ; cette absence ne prouve donc pas que le programme n'a pas été exécuté. »

Corroborez ensuite avec la matrice de comparaison, et analysez la ruche avec le BAM/DAM Parser, qui signale les ruches dirty et les anciens formats pour que les trous soient visibles d'emblée.

Questions fréquentes

Pourquoi un programme dont je sais qu'il a tourné est-il absent de BAM ?

Raisons courantes : il a été lancé depuis un support amovible ou un partage réseau, c'était un programme console démarré en ligne de commande, son entrée a été purgée au démarrage après sept jours, son exécutable a été supprimé puis la machine redémarrée, ou les dernières écritures sont encore dans SYSTEM.LOG1/LOG2.

Un attaquant peut-il modifier ou supprimer des entrées BAM ?

Oui : avec des privilèges suffisants, ce sont des données de registre ordinaires. Suppressions et modifications peuvent laisser des traces : heure de dernière écriture de la clé SID plus récente que toutes les valeurs, écarts avec Prefetch ou Amcache, et événements d'audit du registre ou Sysmon s'ils étaient activés.