Analyse d'Artefact : SRUM (System Resource Usage Monitor)

Note

Résumé exécutif : introduit avec Windows 8 et perfectionné sous Windows 10/11, le System Resource Usage Monitor (SRUM) agit comme la véritable “boîte noire” télémétrique du système. Bien qu’il soit conçu pour fournir des statistiques de gestion de l’énergie au Gestionnaire des tâches, pour les analystes DFIR, le SRUM est une base de données forensique d’une richesse exceptionnelle. Il conserve un historique (de 30 à 60 jours) de l’exécution des processus en les liant directement à l’utilisation du réseau (octets envoyés/reçus) et à des SIDs utilisateurs spécifiques.

1. Aperçu technique

La philosophie fondamentale du SRUM est la collecte continue de télémétrie pour l’optimisation des ressources. Le service de politique de diagnostic de Windows (Diagnostic Policy Service - DPS) surveille en permanence les processus en cours d’exécution, capturant des métriques sur les cycles CPU, les écritures disque, la consommation de la batterie et l’utilisation du réseau.

Afin de minimiser les écritures sur le disque et l’impact sur les performances, ces données sont temporairement conservées en mémoire et ne sont écrites dans la base de données physique que sous deux conditions :

1. toutes les 60 minutes en fonctionnement normal.
2. lors d’un arrêt normal du système.

2. Emplacement et structure de l’artefact

Les données du SRUM ne sont pas stockées dans des journaux textuels classiques ni dans le registre Windows ; elles reposent sur le moteur de base de données interne de Microsoft.

• Chemin du fichier : C:\Windows\System32\sru\SRUDB.dat
• Format : Extensible Storage Engine (ESE). Il s’agit du même format de base de données transactionnelle robuste utilisé par l’Active Directory (ntds.dit) et Microsoft Exchange.

Parce qu’il s’agit d’un fichier système activement verrouillé, l’acquisition de SRUDB.dat lors d’une réponse à incident “à chaud” nécessite des outils d’accès direct au disque (raw disk access) ou une extraction via les clichés instantanés (Volume Shadow Copy - VSS).

3. Structure des données : le graal de la télémétrie réseau

Le parsing de la base de données ESE révèle plusieurs tables ({Network Data}, {Application Resource Usage}, etc.). La corrélation de ces tables fournit la chronologie forensique ultime.

Les métriques clés extraites du SRUM incluent :

• Chemin de l’application : le chemin absolu du binaire exécuté.
• SID de l’utilisateur : l’identifiant de sécurité du compte ayant initié le processus, offrant une attribution d’une grande fiabilité.
• Octets réseau envoyés / reçus : le volume exact de trafic généré par le processus sur des interfaces réseau spécifiques (Wi-Fi, Ethernet).
• Durée : le temps total d’activité de l’application au premier plan et en arrière-plan.

4. Valeur forensique en réponse aux incidents

Le SRUM est souvent l’artefact décisif dans les investigations où la journalisation réseau standard (ex: logs proxy, PCAP) a fait l’objet d’une rotation ou a été intentionnellement désactivée par les attaquants.

A. Prouver l’exfiltration de données

Lors de l’investigation d’une menace interne ou d’une opération de ransomware, prouver le vol de données est critique. Si les fichiers Prefetch (.pf) montrent qu’un outil d’archivage (7z.exe) puis un client FTP (ftp.exe) ont été exécutés séquentiellement, le SRUM fournit le chaînon manquant. Il révélera que 7z.exe n’a eu aucune activité réseau, mais que ftp.exe a envoyé exactement 750 Mo de données vers l’extérieur peu de temps après.

B. Détecter les balises C2 “Low and Slow”

Les menaces persistantes avancées (APT) utilisent souvent des binaires légitimes (comme powershell.exe ou msbuild.exe) pour établir des canaux de commande et contrôle (C2). Même si le trafic est chiffré via TLS, le SRUM enregistrera de manière persistante les petits volumes d’octets sortants, révélateurs d’un comportement de balisage (beaconing), sur une période glissante de 60 jours.

C. Identifier l’injection de processus

Le SRUM lie intrinsèquement l’exécution d’un processus au SID d’un utilisateur. Si un analyste observe une activité réseau provenant de svchost.exe (qui opère normalement sous les comptes SYSTEM, LOCAL SERVICE ou NETWORK SERVICE), mais que le SRUM attribue cette exécution spécifique au SID d’un utilisateur standard, c’est un indicateur de très haute fidélité d’une injection de processus (Process Hollowing) ou de thread malveillant.

5. Le flux de corrélation d’exécution

Pour construire une chronologie irréfutable de l’activité malveillante, les analystes DFIR combinent la télémétrie du SRUM avec d’autres artefacts d’exécution.

1. Chronologie d’exécution (Prefetch) : identifier l’heure d’exécution précise d’un binaire suspect.
2. Identification de la charge utile (Amcache) : extraire le hash SHA1 du binaire pour le croiser avec les plateformes de Threat Intelligence.
3. Attribution réseau (SRUM) : interroger la base de données SRUM à l’horodatage exact du Prefetch pour mesurer le volume de données exfiltrées ou reçues par ce hash spécifique.

6. Outils recommandés

En raison du format de base de données ESE, l’analyse manuelle est impossible. Des parseurs forensiques spécialisés sont nécessaires pour reconstruire les tables dans des formats lisibles par un humain.

SrumECmd

Faisant partie des outils d’Eric Zimmerman, SrumECmd.exe est l’utilitaire en ligne de commande définitif pour le parsing de SRUDB.dat. Il résout automatiquement les SIDs et génère des fichiers CSV catégorisés et très détaillés.

KAPE (Kroll Artifact Parser and Extractor)

Utilisez les cibles (targets) et modules SRUM de KAPE pour acquérir automatiquement le fichier verrouillé via VSS et le parser de manière transparente lors d’un triage de masse des terminaux.

---

Références et lectures complémentaires

• SANS Institute : Windows Forensic Analysis
• Outils d’Eric Zimmerman : Dépôt GitHub SrumECmd
• Artefact lié :BAM (Background Activity Moderator)