BAM, du SID au nom d'utilisateur : attribuer l'exécution

TL;DR. Les noms de clés BAM sont l'attribution : une sous-clé par SID sous UserSettings. Résolvez les SID avec la ProfileList de la ruche SOFTWARE (nom de dossier), la ruche SAM (noms des comptes locaux) ou le domaine (comptes de domaine). Reconnaissez les SID bien connus — S-1-5-18 est LocalSystem, S-1-5-90-0-N les comptes DWM, S-1-5-96-0-N les comptes du pilote de polices. Et pesez vos mots : BAM attribue l'exécution à un compte, pas à une personne derrière le clavier.

L'attribution à un utilisateur est le principal avantage de BAM sur Prefetch, ShimCache et Amcache, qui sont globaux au système. Cet article montre comment passer d'un SID à un nom utilisable dans un rapport, et jusqu'où ce nom est fiable. Les bases sont dans le guide complet BAM/DAM.

Lire un SID

Un identifiant de sécurité comme S-1-5-21-3623811015-3361044348-30300820-1119 se décompose ainsi (Microsoft Learn) :

Deux repères issus de la même documentation : le RID 500 est l'Administrateur intégré, et un SID n'est jamais réutilisé dans son périmètre. Deux clés BAM qui partagent la partie domaine appartiennent à la même machine ou au même domaine ; comparez ce préfixe au SID de la machine pour distinguer comptes locaux et comptes de domaine.

Résoudre les noms

ProfileList (ruche SOFTWARE)

SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\<SID> contient une valeur ProfileImagePath telle que C:\Users\svc_backup. Le dernier dossier est en général le nom du compte, et c'est ce qu'affiche notre BAM/DAM Parser dès que vous ajoutez la ruche SOFTWARE : chaque ligne reçoit un Compte à côté de son SID (colonne User dans les exports), et le filtre de comptes affiche « nom (SID) ».

Le piège : Microsoft documente que renommer un compte utilisateur ne change pas le chemin de son profil (Microsoft Learn). Le « nom du dossier de profil » est donc un indice fort, pas le nom de compte faisant foi. Nous le présentons comme tel dans nos rapports.

Ruche SAM (comptes locaux)

Pour les comptes locaux, la clé SAM\Domains\Account\Users de la ruche SAM associe chaque RID à son nom d'utilisateur actuel. Si la partie domaine du SID BAM correspond au SID de la machine, le RID s'y résout. Notre outil n'analyse pas la ruche SAM ; Registry Parser ou les plugins SAM de RegRipper le font.

Le domaine

Pour les comptes de domaine, interrogez le contrôleur de domaine (Get-ADUser -Identity <SID>), ou utilisez les événements d'ouverture de session de la machine, qui portent à la fois le SID et le nom du compte (EVTX Parser pour les ouvertures de session 4624/4648).

Les SID bien connus que vous croiserez

Les trois premiers figurent dans la liste Microsoft des SID bien connus ; les formats DWM et pilote de polices sont documentés dans la référence Security Identifier et dans les notes de Boutnaru sur dwm.exe.

Une clé SYSTEM avec des entrées hors de System32 mérite l'attention. Dans l'exemple fictif du site, S-1-5-18 affiche \Windows\Temp\svchost.exe à côté du vrai \Windows\System32\svchost.exe — exactement le type de ligne pour lequel existe le signalement « Binaire système hors de son dossier ». Quelque chose a tourné en LocalSystem depuis un dossier temporaire ; sur un vrai dossier, vous chercheriez le service ou la tâche planifiée qui l'a lancé (installations de service 7045, clé Services, XML des tâches).

Un compte, pas une personne

Une entrée BAM sous le SID X signifie que le processus a été attribué au compte X. Elle ne dit pas qui était au clavier. Rien dans l'enregistrement ne distingue ces situations, qui exécutent toutes du code sous le même compte :

• l'utilisateur a lancé le programme lui-même,
• quelqu'un d'autre a utilisé son mot de passe, son jeton ou sa session (RDP, runas, identifiants volés),
• une tâche planifiée ou un service configuré pour s'exécuter sous ce compte l'a démarré,
• un outil d'exécution à distance a créé un processus avec ces identifiants.

C'est pourquoi la formulation dans un rapport doit être « exécuté sous le compte… », avec le contexte d'ouverture de session (interactive, RDP, réseau, service) tiré des journaux d'événements. Pour les connexions à distance, SRUM et les artefacts RDP aident à situer la session.

Comptes de service et comptes partagés

C'est sur les comptes de service que l'attribution BAM brille. Un compte de sauvegarde qui n'exécute normalement qu'un agent et qui affiche soudain cmd.exe, mstsc.exe et un scanner dans sa clé BAM trahit clairement un usage interactif abusif. L'enquête sur un mouvement latéral suit exactement ce schéma avec le compte fictif svc_backup.

Les comptes partagés (borne, salle de TP, admin générique) sont l'inverse : BAM attribuera tout à un seul SID. Associez-le aux événements d'ouverture de session et aux IP sources pour séparer les sessions.

Exemple concret avec les données d'exemple

Les ruches d'exemple fictives derrière le bouton Essayer un exemple de l'outil contiennent trois clés BAM :

Les deux SID S-1-5-21 partagent la partie domaine 3623811015-3361044348-30300820 : ils appartiennent à la même machine ou au même domaine ; leurs RID, 1104 et 1119, distinguent les comptes. Sans la ruche SOFTWARE, l'outil n'afficherait que les SID ; avec elle, le filtre de comptes indique alice (S-1-5-21-…-1104) et svc_backup (S-1-5-21-…-1119). Ces deux ruches ne suffisent pas à dire s'il s'agit de comptes locaux ou de domaine : comparez la partie domaine au SID de la machine issu de la ruche SAM, ou interrogez le domaine. L'enquête détaillée s'appuie précisément sur cette attribution pour montrer que c'est le compte de service, et non l'utilisatrice, qui a lancé les outils d'attaque.

Check-list

1. Chargez SYSTEM et SOFTWARE pour que les noms s'affichent à côté des SID.
2. Comparez la partie domaine de chaque SID au SID de la machine : local ou domaine ?
3. Obtenez les noms faisant foi via la SAM (local) ou le domaine.
4. Traitez les SID bien connus comme une catégorie à part ; examinez de près les chemins inhabituels sous SYSTEM.
5. Écrivez « sous le compte », et apportez le type et la source de l'ouverture de session depuis les journaux d'événements.

Tout ce qui précède, hormis les recherches SAM et domaine, se fait directement dans le BAM/DAM Parser ; voyez le pas-à-pas pour la méthode complète.

Questions fréquentes

Comment transformer un SID BAM en nom d'utilisateur ?

Chargez la ruche SOFTWARE et lisez ProfileList\<SID>\ProfileImagePath : le dernier dossier de ce chemin est en général le nom du compte. Pour les comptes locaux, la ruche SAM donne le nom actuel à partir du RID ; pour les comptes de domaine, interrogez le domaine ou regardez les événements d'ouverture de session.

Une entrée BAM prouve-t-elle qu'une personne a lancé le programme ?

Elle prouve que le processus a été attribué au SID de ce compte. L'enregistrement ne distingue pas l'utilisateur, un attaquant utilisant son mot de passe, ou une tâche ou un service configuré pour s'exécuter sous ce compte ; apportez le contexte d'ouverture de session depuis les journaux d'événements.