Forensique SRUM : usage des applications et octets réseau

Ce guide vous apprend à extraire, réparer et lire la base du System Resource Usage Monitor pour établir quelles applications ont tourné sur un hôte Windows, sous quel compte, à quelle heure, et quel volume de données chacune a fait transiter sur le réseau. C'est l'artefact de référence quand la question est : « des données ont-elles été exfiltrées, par quoi et quand ? »

Ce qu'est SRUM et pourquoi il compte

SRUM est apparu avec Windows 8 pour alimenter les pages batterie et consommation de données des Paramètres. Environ toutes les heures, des fournisseurs hébergés par le service de stratégie de diagnostic (DPS) écrivent des compteurs agrégés dans SRUDB.dat, une base ESE. Personne ne le configure, la plupart des attaquants n'y pensent pas, et il survit à la suppression des outils qu'il décrit.

Trois propriétés le distinguent des autres preuves d'exécution :

• Attribution par utilisateur : chaque enregistrement porte un SID.
• Volume réseau par application : octets envoyés et reçus pour chaque processus, par interface.
• Historique : des semaines de données horaires, là où Prefetch ou BAM ne gardent souvent que la dernière exécution.

La fiche SRUM résume l'artefact ; ce guide déroule une investigation.

Où se trouvent les données

Collectez tout le dossier sru et la ruche SOFTWARE avec ses journaux de transactions. Sans la ruche, les profils réseau restent de simples numéros.

Les tables qui comptent

Les tables SRUM portent le nom du GUID de leur fournisseur. Celles qui servent dans presque toutes les affaires :

L'ensemble exact des tables varie selon la version et l'édition de Windows ; vérifiez la clé Extensions et la base elle-même au lieu de supposer. Toutes les tables de données partagent AutoIncId, TimeStamp, AppId et UserId.

SruDbIdMapTable

Les tables de données ne stockent jamais directement un chemin ni un SID. AppId et UserId sont des index dans SruDbIdMapTable, où IdBlob contient la valeur réelle et IdType en précise la nature : chemin d'application, nom de service ou d'application empaquetée, ou SID utilisateur stocké en binaire. Les parseurs font cette jointure pour vous, mais quand une valeur paraît étrange (nom d'application vide, SID non résolu), revenez à la table brute. Les chemins sont généralement des chemins de périphérique, par exemple \Device\HarddiskVolume3\Users\jdoe\AppData\Local\Temp\rclone.exe : il faut la correspondance des volumes pour retrouver les lettres de lecteur.

Interfaces et profils réseau

InterfaceLuid encode le type d'interface : une fois décodé, il distingue l'Ethernet filaire du Wi-Fi ou du haut débit mobile. L2ProfileId pointe vers un profil WLAN ou filaire ; si vous fournissez la ruche SOFTWARE, SrumECmd le résout en nom de profil, comme le SSID Wi-Fi. C'est ainsi que l'on montre qu'un portable était sur un partage de connexion personnel, et non sur le réseau de l'entreprise, pendant un gros envoi. Voir les profils réseau pour la partie registre.

Temporalité : des tranches horaires, pas des événements

Deux faits conditionnent toute conclusion tirée de SRUM.

Intervalle d'écriture. Les fournisseurs agrègent en mémoire et écrivent environ toutes les 60 minutes, avec des intervalles plus courts signalés pour certains fournisseurs, ainsi qu'à l'arrêt. Le TimeStamp d'un enregistrement correspond au moment où la tranche a été écrite, en UTC. Il marque la fin d'une fenêtre d'agrégation, pas l'instant de l'activité. Un envoi de 3 Go affiché à 14:02 a eu lieu pendant la fenêtre précédente, pas à 14:02.

Rétention. Les tables détaillées sont couramment conservées une trentaine de jours, et diverses sources évoquent jusqu'à environ 60 jours selon la table et le build ; les tables d'énergie long terme peuvent remonter plus loin. Relevez toujours le TimeStamp le plus ancien de chaque table et indiquez cette plage dans le rapport.

Traitez tous les horodatages SRUM comme de l'UTC (UTC et heure locale) et corrélez à l'heure près, pas à la seconde.

Collecte

La base est verrouillée par le service en cours d'exécution. Copiez-la via un cliché instantané avec esentutl, qui gère aussi correctement le format de pages ESE :

mkdir E:\case\sru
esentutl.exe /y C:\Windows\System32\sru\SRUDB.dat /vss /d E:\case\sru\SRUDB.dat
robocopy C:\Windows\System32\sru E:\case\sru SRU*.log SRU.chk /COPY:DAT
reg save HKLM\SOFTWARE E:\case\SOFTWARE.hiv

Sur une image disque, exportez simplement le dossier et la ruche SOFTWARE avec ses journaux. La cible KAPE SRUM collecte les deux (voir acquisition et triage) ; Velociraptor propose la cible de triage SRUM et l'artefact Windows.Forensics.SRUM pour une analyse à chaud. Pendant une réponse à chaud, récupérez SRUM tôt : c'est peu coûteux et cela couvre des semaines.

Réparer une base « dirty »

Une copie d'une base ESE en cours d'utilisation est presque toujours en état Dirty Shutdown, et certains parseurs la refusent. Vérifiez d'abord l'en-tête, sur une copie de travail, jamais sur votre seul exemplaire :

cd /d E:\case\sru
esentutl.exe /mh SRUDB.dat | findstr /i "State"

Si l'état est Dirty Shutdown, rejouez les journaux. Le nom de base des journaux SRUM est sru, et /i demande à ESE d'ignorer les bases attachées absentes ou incohérentes :

esentutl.exe /r sru /i
esentutl.exe /mh SRUDB.dat | findstr /i "State"

Lancez la commande depuis le dossier qui contient la base et ses journaux, idéalement sur un système dont la version d'ESE est au moins aussi récente que celle de la source. Si la récupération échoue, esentutl /p SRUDB.dat effectue une réparation destructive qui supprime les pages endommagées : ne l'utilisez que sur une seconde copie et documentez-le. SrumECmd peut aussi tenter lui-même la réparation sur une copie lorsqu'il détecte une base « dirty ».

Analyse

SrumECmd (Eric Zimmerman) est le choix habituel. Donnez-lui la base et la ruche SOFTWARE :

SrumECmd.exe -f E:\case\sru\SRUDB.dat -r E:\case\SOFTWARE.hiv --csv E:\out\srum
:: Ou laissez-le trouver les deux dans une arborescence de type KAPE
SrumECmd.exe -d E:\case\C --csv E:\out\srum

Il produit un CSV par table (AppResourceUseInfo, NetworkUsages, NetworkConnections, EnergyUsage, PushNotifications et d'autres) avec AppId, UserId et SID déjà résolus.

srum-dump (Mark Baggett) génère un classeur annoté à partir d'un modèle configurable, pratique pour les relecteurs qui vivent dans Excel. Ses arguments en ligne de commande ont changé d'une version à l'autre : consultez l'aide du build utilisé. Pour un coup d'œil rapide sans outillage, AppResourcesUsageView et NetworkUsageView de NirSoft lisent SRUM sur un système allumé.

Schémas d'investigation

Fenêtre d'exfiltration

Chargez NetworkUsages, additionnez BytesSent par application et par heure, puis triez par ordre décroissant. Les gros émetteurs légitimes (OneDrive, Teams, agents de sauvegarde, navigateurs en visioconférence) donnent la référence pour cet utilisateur. Ce qui ressort :

• Les outils de transfert en ligne de commande : rclone.exe, curl.exe, winscp.exe, pscp.exe, clients de type megacmd.
• Un navigateur avec un pic sortant qui coïncide avec une visite d'un site de partage dans l'historique du navigateur.
• Des archiveurs (7z.exe, rar.exe, WinRAR.exe) avec de fortes écritures disque dans Application Resource Usage juste avant l'heure de l'envoi.
• Des outils d'accès à distance comme AnyDesk ou TeamViewer qui envoient bien plus qu'ils ne reçoivent, signe probable d'un transfert de fichiers sortant (forensique des outils d'accès à distance).
• Des pics de svchost.exe qui coïncident avec des tâches BITS.

Indiquez ensuite le rapport entre octets envoyés et reçus, ainsi que le profil réseau. « rclone.exe, sous le SID de jdoe, a envoyé environ 4,1 Go entre 01:00 et 03:00 UTC via le profil Wi-Fi Jay iPhone » est une affirmation précise et défendable.

Prouver qu'un outil supprimé a tourné

Quand le binaire, son fichier Prefetch et son entrée Amcache ont disparu, une ligne SRUM pour \Device\HarddiskVolume3\Users\Public\x.exe avec du temps CPU montre encore qu'il a tourné, sous quel utilisateur et pendant quelles heures. Cela resserre aussi la fenêtre de recherche dans les clichés instantanés de volume qui pourraient encore contenir le fichier. Le guide des preuves d'exécution montre comment SRUM s'articule avec les autres sources.

Comptes de service et SYSTEM

Des enregistrements sous S-1-5-18 (SYSTEM) ou sous des SID de service pour des binaires situés dans des chemins accessibles en écriture aux utilisateurs sont une piste sérieuse de persistance ou d'outil d'exécution à distance. Recoupez avec les événements d'installation de service et les tâches planifiées.

Prouver que l'hôte était actif

Network Connectivity et Energy Usage montrent ensemble si un portable était allumé, sur batterie, et connecté à quel réseau à une heure donnée. Cela confirme ou infirme un alibi (« le portable est resté fermé tout le week-end ») bien mieux que les seuls événements d'ouverture de session.

Rédiger les constats SRUM

Les chiffres SRUM incitent à une fausse précision. Présentez-les pour ce qu'ils sont : des compteurs agrégés sur une fenêtre, attribués à un chemin d'application et à un SID. Donnez les bornes de la tranche en UTC, la table d'origine de la valeur, ainsi que le parseur et sa version. Si vous additionnez plusieurs heures, dites-le, et placez les lignes horaires en annexe pour qu'un relecteur puisse vérifier le calcul. Les compteurs incluent l'overhead des protocoles et les retransmissions : un total BytesSent de 4,1 Go ne signifie pas que 4,1 Go de fichiers exactement ont quitté le réseau. Enfin, décrivez ce que SRUM ne peut pas montrer (destination, noms de fichiers, heure exacte de démarrage) et citez les sources utilisées pour combler ces manques. Un rapport qui pose ces limites d'emblée est bien plus difficile à attaquer en revue ou devant un tribunal.

Pièges

• Prendre TimeStamp pour l'heure de l'événement. C'est la fin d'une tranche d'agrégation, généralement d'une heure.
• Attendre des destinations. SRUM contient des volumes, pas d'IP ni de domaines.
• Ignorer l'état « dirty ». Un parseur qui saute silencieusement les données non validées peut faire paraître vides les dernières heures.
• Manquer les données récentes. Une copie à chaud peut ne pas contenir la dernière heure non écrite.
• Analyser sans la ruche SOFTWARE. Les noms de profils réseau restent non résolus.
• Surinterpréter les chemins de périphérique. HarddiskVolumeN doit être rattaché à une lettre de lecteur, et les volumes amovibles changent de numéro.
• Supposer l'exhaustivité. Certains processus sont attribués à des processus hôtes (svchost.exe, conteneurs d'applications empaquetées), et une activité très brève peut passer sous le seuil enregistré.
• Conclure « rien ne s'est passé » devant une petite base. Supprimer SRUDB.dat impose d'arrêter DPS ; une base qui commence récemment sur un système ancien est un constat d'anti-forensique.

Checklist de la méthode

1. Collecter l'intégralité de C:\Windows\System32\sru\ et la ruche SOFTWARE avec .LOG1 et .LOG2, depuis un cliché instantané ou une image.
2. Calculer l'empreinte des originaux et travailler sur des copies.
3. Vérifier l'état avec esentutl /mh ; rejouer les journaux avec esentutl /r sru /i si la base est « dirty ».
4. Analyser avec SrumECmd (-f et -r) et noter le TimeStamp le plus ancien et le plus récent de chaque table.
5. Traduire les chemins de périphérique en lettres de lecteur et les SID en comptes.
6. Dans NetworkUsages, classer les applications par BytesSent par heure et par profil réseau ; signaler outils de transfert, archiveurs, navigateurs et outils d'accès à distance.
7. Dans AppResourceUseInfo, confirmer l'exécution des binaires suspects et repérer les fortes écritures disque avant les envois.
8. Recouper chaque heure SRUM avec Prefetch, Amcache, BAM, l'historique des navigateurs, les journaux du pare-feu et du proxy, et construire la chronologie en UTC.