Preuve d'exécution avec BAM : un cas de mouvement latéral

TL;DR. Scénario fictif, données synthétiques. Sur FIN-WKS-07, BAM suffit à retracer une matinée : alice ouvre une « facture » à double extension, puis PowerShell 24 secondes plus tard ; une heure après, le compte de service svc_backup — censé n'exécuter qu'un agent de sauvegarde — lance cmd.exe, dépose un binaire dans ProgramData, exécute un scanner d'IP depuis un second volume, ouvre une session RDP, lance PsExec, 7-Zip et rclone. Un faux svchost.exe tourne en SYSTEM depuis Windows\Temp. BAM donne le qui, le quoi et le quand ; il ne donne ni les commandes, ni les hash, ni les cibles, et cet article le dit explicitement à chaque fois.

Tout ce qui figure dans cet article est fictif. La machine, les comptes, les SID, les chemins et les heures proviennent des ruches synthétiques derrière le bouton « Essayer un exemple » du BAM/DAM Parser. Aucune organisation, personne ou incident réel n'est décrit. Vous pouvez charger les mêmes données et suivre pas à pas.

Le contexte

Un poste de la comptabilité, FIN-WKS-07, a déclenché une alerte pour du trafic sortant vers un fournisseur de stockage cloud le 14 septembre 2026. L'intervenant a collecté SYSTEM, SYSTEM.LOG1/LOG2 et SOFTWARE avec KAPE avant que quiconque ne redémarre la machine — ce qui, comme l'explique l'article sur les limites, maintient en vie les entrées BAM des outils supprimés.

Le chargement des ruches dans l'outil donne l'en-tête suivant :

Toutes les heures ci-dessous sont en UTC, telles que stockées dans BAM. Ajoutez deux heures pour l'heure locale de Paris.

Phase 1 — Accès initial sous alice

En filtrant sur alice et en triant par dernière exécution :

Ce que BAM étaye : un début de journée normal (Teams, Outlook, Chrome), puis un programme à double extension .pdf.exe lancé depuis Downloads, puis PowerShell 24 secondes plus tard, le tout sous alice.

Ce que BAM ne montre pas : comment le fichier est arrivé (téléchargement navigateur ou pièce jointe), son hash, si PowerShell était son processus enfant, ni ce que PowerShell a exécuté. Rappelez-vous que l'heure est la dernière activité enregistrée — mise à jour au lancement et à la fin du processus (Suhanov) —, la « facture » a donc pu démarrer un peu avant 09:12:07 si elle est restée ouverte un moment.

Étapes suivantes sur un vrai dossier : historique Chrome et flux Zone.Identifier pour l'origine du téléchargement (Browser Forensics), Amcache pour le SHA-1, journaux PowerShell Operational (4104, journalisation des blocs de script si activée) dans EVTX Parser.

Comparaison des control sets. En décochant « Control set actif uniquement », on voit ControlSet002 avec seulement quatre entrées d'alice — Chrome, Outlook, Excel, Notepad. Cet instantané plus ancien ne contient aucune des lignes suspectes, ce qui est cohérent avec une activité récente. C'est un point de comparaison, pas une preuve de chronologie.

Phase 2 — Le compte de service se réveille

svc_backup est un compte de service de sauvegarde. Dans un parc sain, sa clé BAM contiendrait au plus l'agent de sauvegarde. Ici :

C'est le constat central, et c'est le genre de constat où BAM est unique : une exécution attribuée à un compte précis. L'article sur l'attribution explique pourquoi il faut écrire « exécuté sous le compte svc_backup » — BAM ne sait pas si une personne a tapé les commandes ou si un outil a utilisé les identifiants.

Rattachement à MITRE ATT&CK pour le rapport :

• Advanced_IP_Scanner.exe → découverte de services réseau (T1046).
• mstsc.exe → RDP sortant (T1021.001).
• PsExec64.exe → exécution de services sur des machines distantes (T1569.002).
• 7z.exe puis rclone.exe → préparation et exfiltration vers un stockage cloud (T1567.002).

Ce qu'apportent les chemins

• \Device\HarddiskVolume7\tools\ — pas le volume système (HarddiskVolume3). BAM n'enregistre pas les exécutables sur des supports marqués amovibles (Suhanov) : ce volume s'est donc présenté autrement — un VHD/ISO monté ou un disque externe vu comme fixe sont des candidats. Rattachez-le avec d'autres artefacts avant d'écrire « clé USB ». Voir l'article sur le format des valeurs pour les chemins de périphérique.
• \ProgramData\Intel\m64.exe — un binaire inconnu dans un dossier d'apparence légitime. BAM ne peut pas dire ce que c'est ; le SHA-1 d'Amcache le peut.
• \Users\Public\rclone.exe — un dossier accessible en écriture à tous, souvent détourné pour préparer des données.

Ce qui manque

Pas de net.exe, whoami.exe ni nltest.exe, alors que ce type de commandes de reconnaissance est typique d'une session cmd.exe. C'est attendu : des programmes console lancés depuis une session en ligne de commande ont été observés sans entrée BAM (Suhanov). Cette absence ne dit rien. C'est dans Prefetch et les événements 4688/Sysmon qu'ils apparaîtront.

Phase 3 — SYSTEM depuis un dossier temporaire

Sous S-1-5-18 :

Un svchost.exe hors de System32, exécuté en LocalSystem trois minutes après l'ouverture d'un shell par svc_backup et quatre minutes avant l'apparition de m64.exe. Du masquage classique (T1036). Comment il a obtenu SYSTEM — installation de service, tâche planifiée, service de PsExec lui-même — demande les événements 7045/4697 et la clé Services.

La timeline consolidée

Les quarante minutes entre PowerShell et le premier shell du compte de service forment le trou évident : comment l'attaquant a-t-il obtenu les identifiants de svc_backup ? BAM l'ignore. Pistes à tester : identifiants stockés dans un script ou une configuration lisible par alice, vol d'identifiants (Prefetch/Amcache pour les outils de dump, événements d'accès à LSASS), ou connexion depuis une autre machine (4624 type 3/10).

Ce qui est allé dans le rapport

1. Les constats BAM, chacun formulé « dernière activité enregistrée sous le compte X à T UTC », avec le chemin de la clé SID.
2. Les limites explicites : pas de lignes de commande, pas de hash, pas d'outils console, pas d'exécutions depuis supports amovibles ou réseau, un seul horodatage par programme.
3. Le plan de corroboration : Amcache (hash de m64.exe, de la facture, de rclone), Prefetch (compteurs, premières exécutions), EVTX (ouvertures de session, installations de service, PowerShell), SRUM (octets envoyés par rclone.exe), et les clés BAM des machines atteintes par PsExec et RDP, où le même compte (ou SYSTEM) a pu lancer des outils aussi.
4. Le périmètre : les autres machines atteintes par mstsc.exe et PsExec64.exe font l'objet de la même collecte.

À vous de jouer

Ouvrez le BAM/DAM Parser, cliquez sur Essayer un exemple, et reproduisez chaque tableau avec le filtre de comptes, « Signalées uniquement » et le tri. Le pas-à-pas explique chaque commande, et la comparaison avec Prefetch, ShimCache et Amcache montre ce qu'apporterait chaque artefact de corroboration.