Utiliser SRUM dans une investigation forensique

SRUM est l'artefact qui ferme la boucle sur "cela a-t-il tourné, quand, qui l'a lancé, combien de données a-t-il déplacé". Sur les affaires où l'EDR est absent, où la fenêtre suspecte précède la couverture EDR, ou où l'EDR a été contourné, SRUM est fréquemment l'enregistrement d'activité par processus le plus défendable sur la machine. Le compromis est la résolution : la plupart des lignes sont regroupées par heure, on ancre donc des affirmations grossières avec SRUM puis on les affine avec des artefacts à la seconde près ailleurs.

Ce que SRUM prouve bien

• Une application tournait à une date donnée. Les lignes Application Resource Use avec FaceTime > 0 ou BackgroundCycleTime > 0 pour un binaire résolu via AppId placent ce processus sur le système pour un seau horaire donné.
• Combien de données une application a envoyées ou reçues. BytesSent / BytesRecvd de Network Data Usage par AppId par profil réseau.
• Sur quel réseau était l'hôte. Network Connectivity porte des horodatages de connexion FILETIME précis par profil Wi-Fi.
• Le portable était-il sur secteur ou batterie. Energy Usage enregistre chaque transition avec un FILETIME précis à la seconde.

Un exemple traité : exfiltration de données

Le schéma standard de l'employé partant. Image prise trois jours après le dernier jour ; la question est de savoir s'il a préparé et exfiltré des données.

1. Acquérir C:\Windows\System32\sru\* et la ruche registre SOFTWARE depuis l'image. Voir où se trouve SRUDB.dat.
2. Récupérer la base si sale, voir comment réparer un SRUDB.dat corrompu.
3. Analyser. Déposez la base dans l'analyseur navigateur ou lancez SrumECmd. Voir comment analyser SRUDB.dat.
4. Filtrer Network Data Usage sur le UserId du suspect (résolu via SruDbIdMapTable vers son SID, lui-même associé à un nom d'utilisateur via ProfileList du registre).
5. Trier par BytesSent décroissant pour la fenêtre suspecte (14 derniers jours d'emploi). Cherchez les processus non-navigateur avec des centaines de Mo sortants : OneDrive.exe, Dropbox.exe, pwsh.exe, curl.exe, 7z.exe, binaires sur mesure.
6. Recouper Network Connectivity pour la même fenêtre. L'appareil était-il sur Wi-Fi d'entreprise, un hotspot personnel, ou un SSID inconnu ? Le haut débit mobile (L2ProfileFlags & 0x400) signifie souvent un hotspot intentionnellement choisi pour contourner le filtrage de sortie.
7. Pivoter vers Application Resource Use pour ces processus. FaceTime > 0 distingue l'usage au premier plan d'un agent de synchronisation en arrière-plan.
8. Corroborer l'activité fichier avec le journal USN et le MFT : les octets sont un bonus si vous pouvez aussi montrer ce qui a été archivé et copié.

Processus + octets + réseau + utilisateur + heure est une histoire bien plus forte que n'importe quelle source unique.

Un exemple traité : persistance de malware

Alerte SOC déclenchée sur un binaire à faible prévalence exécuté hier matin.

1. Résolvez le chemin du binaire dans SruDbIdMapTable. S'il existe une ligne, le processus s'est enregistré auprès de SRUM à un moment, donc il a tourné.
2. Extrayez toutes les lignes Application Resource Use pour cet AppId, triées par TimeStamp. La plus ancienne est la première exécution ; les lignes suivantes montrent les intervalles de récurrence, empreinte d'une persistance par tâche planifiée ou clé Run.
3. Si les cycles CPU en arrière-plan continuent sans temps au premier plan, le processus tourne silencieusement.
4. Recoupez Network Data Usage pour le même AppId pour voir s'il a téléphoné chez lui et sur quel réseau.
5. Récupérez le hash du binaire via AmCache pour le pivot threat-intel, Prefetch pour des horodatages d'exécution précis, et Sysmon 1 / EVTX 4688 (EVTX) pour le processus parent.

Chevauchement EDR et là où SRUM gagne encore

L'EDR moderne enregistre la plupart de ce que SRUM fait, souvent avec une meilleure granularité. SRUM gagne encore sa place quand :

• L'EDR n'était pas déployé au moment de l'activité suspecte.
• L'EDR a été désactivé ou contourné par l'adversaire (et SRUM ne l'a pas été, DPS figure rarement sur les checklists adversariales).
• La rétention EDR est plus courte que la fenêtre d'investigation.
• L'hôte est un portable personnel/prestataire avec une couverture EDR inégale.

Dans ces cas, SRUM est un journal d'audit intégré, activé par défaut, que Microsoft a laissé tourner depuis des années.

Mises en garde

• Regroupement horaire. Une session navigateur de cinq minutes peut apparaître comme une ligne de 60 minutes. Ne revendiquez pas une résolution minute par minute.
• FaceTime > 0 ≠ humain au clavier. Interface visible n'est pas entrée humaine. Sessions RDP, kiosques, écrans de connexion sans surveillance s'enregistrent tous.
• Les agrégats LT diffèrent des compteurs court-terme. Ne comparez pas un à un les comptes d'octets LT hebdomadaires aux lignes court-terme horaires.
• SYSTEM peut manipuler. Vérifiez l'entrée MFT de SRUDB.dat pour des horodatages de modification inattendus et utilisez Energy Usage comme oracle de continuité (il journalise même quand la plupart de la télémétrie d'application est supprimée).

Pour aller plus loin

• Qu'est-ce que SRUM et pourquoi cela intéresse les analystes forensiques
• Tables SRUM expliquées : AppResource, Network, Energy, Push
• Comment analyser SRUDB.dat sans rien installer
• Détecter l'exfiltration de données avec SRUM
• SRUM vs Prefetch vs Amcache