SRUM (System Ressource Utilization Manager) – Forensgeek

Forensics

Bonjour à tous, aujourd’hui on continue la série Forensgeek avec un nouveau TP sur un élément analysable en investigation post-mortem, le SRUM (System Ressource Utilization Manager).

C’est quoi SRUM et ça sert à quoi ?

Le SRUM est présent depuis Windows 8 et enregistre l’activité relative à l’utilisation des ressources dans le système. On y retrouve des informations sur cycles CPU, les I/O disque ou réseau ou encore les notifications. C’est une sorte de journal d’évènements de performances des applications.

C’est où ?

Alors vous pouvez visualiser, partiellement, les informations dans le gestionnaire de tâches, onglet Historique des applications.

Après c’est une vue incomplète au dessus. L’ensemble des données est accessible dans deux emplacement :

  1. Le registre et la clé HKLM\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\SRUM\Extensions. Attention, vous n’avez ici que les informations relatives à la dernière heure au maximum (purge horaire et celui-ci est aussi purgé à l’arrêt du système).
  2. le fichier SRUDB.dat dans C:\WINDOWS\System32\sru, mais vous n’avez pas la possibilité d’accéder facilement à ce fichier tant que le système est en ligne.

Pour les curieux le format du .dat, c’est un ESE pour Extensible Storage Engine (ESE). C’est un format propriétaire Microsoft, un peu à l’image d’un SQLlite ou vous avez une base de données dans un seul fichier. Il existe des utilitaires dédiés pour gérer ce type de fichier comme ESEDatabaseView si vous voulez creuser le format dans le détails.

Comment on le collecte ?

A chaud

Alors comme le fichier .dat et verrouillé pendant le fonctionnement du système, le plus simple pour les collecte live reste d’avoir un EDR sur votre parc informatique (jetez un oeil à GRR ou Velociraptor IR en open source) qui s’occupe de la collecte pour vous puisqu’avec les bon accès et utilitaires « as-system » : c’est quand même possible de lire le .dat.

Sur une seule machine en ligne, vous pouvez aussi utiliser l’utilitaire SRUM-DUMP (attention l’antivirus n’est pas content comme le fichier n’est pas signé et va jardiner un peu trop dans des lib sysyème) ou SrumECmd (que je n’ai pas testé ici).

Une fois l’utilitaire démarré, allez sélectionner votre fichier srudb.dat, le programme va repérer qu’il s’agit d’un système vivant et vous proposer d’utiliser FGET en cliquant sur Auto Extract comme ci-dessous. Le programme détecte tout seul son template XLSX à utiliser, ainsi que le chemin de registre.

SRUM (System Ressource Utilization Manager)srum dump interface

Cliquez alors sur OK et laissez l’analyse se dérouler.

SRUM (System Ressource Utilization Manager) srum dump running

A froid

Sur un système à froid, vous devez donc récupérer le .dat et la base de registre pour les passer dans l’outil. Ici, soit vous avez une image Windows à analyser déjà sous la main. Si vous voulez tester, je vous propose d’aller en prendre une toute prête chez l’ENISA (European Network and Information Security Agency, l’ANSSI version Europe), juste pour ce type d’usages « académiques », donc ici.

$ curl https://www.enisa.europa.eu/ftp/ENISA-LOT3-Evidence.zip -O VM-ENISA.zip

Une fois le zip téléchargé, décompressez l’archive :

$ unzip VM-ENISA.zip

Qui va vous donner un jolie fichier evidence.vmdk que vous pouvez au choix :

  • Monter directement comme disque externe dans une machine virtuelle Linux, c’est le plus simple, de loin. On verra, peut-être, dans un prochain TP comment installer une machine dédié pour la forensics.
  • Télécharger et monter directement dans la VM l’image avec des utilitaires comme
    guestmount ou qemu-nbd.
  • Convertir le vmdk en une image au format E01 ou raw dont je vous parlais dans le premier article forensgeek sur l’acquisition d’image.

Une fois le disque monté dans votre Linux vous devriez trouver un fichier disk.raw sur celui-ci, il ne vous reste plus qu’a le monter. Pour cela commencer par contrôler quels partitions et types de systèmes de fichiers sont utilisés avec mmls (ou fdisk -l pour ceux qui préfèrent) :

# mmls disk.raw 
DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors

      Slot      Start        End          Length       Description
000:  Meta      0000000000   0000000000   0000000001   Primary Table (#0)
001:  -------   0000000000   0000002047   0000002048   Unallocated
002:  000:000   0000002048   0001026047   0001024000   NTFS / exFAT (0x07)
003:  000:001   0001026048   0050329599   0049303552   NTFS / exFAT (0x07)
004:  -------   0050329600   0050331647   0000002048   Unallocatedv

La partition qui nous intéresse est la n°3 vu la taille des autres:

# mkdir /mnt/enisa_part3_c
# mount -t ntfs -o ro,offset=525336576 disk.raw /mnt/enisa_part3_c
$ ll /mnt/enisa_part3_c/
total 917954
drwxrwxrwx  1 root root      4096 août  16  2016  ./
drwxr-xr-x 18 root root      4096 mars  31 12:20  ../
drwxrwxrwx  1 root root         0 juil. 21  2016 '$Recycle.Bin'/
-rwxrwxrwx  1 root root        24 oct.  30  2015  autoexec.bat*
-rwxrwxrwx  1 root root    400228 oct.  30  2015  bootmgr*
-rwxrwxrwx  1 root root         1 oct.  30  2015  BOOTNXT*
-rwxrwxrwx  1 root root        10 oct.  30  2015  config.sys*
-rwxrwxrwx  1 root root 671088640 août  16  2016  pagefile.sys*
drwxrwxrwx  1 root root         0 oct.  30  2015  PerfLogs/
drwxrwxrwx  1 root root      4096 juil. 15  2016  ProgramData/
drwxrwxrwx  1 root root      8192 août  16  2016 'Program Files'/
drwxrwxrwx  1 root root         0 juil. 14  2016  Recovery/
-rwxrwxrwx  1 root root 268435456 août  16  2016  swapfile.sys*
drwxrwxrwx  1 root root      4096 juil. 27  2016 'System Volume Information'/
drwxrwxrwx  1 root root      4096 juil. 15  2016  Users/
drwxrwxrwx  1 root root     28672 juil. 27  2016  Windows/

Remarque : Le paramètre offset=525336576, ne correspond pas à la valeur du start indiquée par mmls (1026048). la valeur vient en fait de la multiplication de la taille d’un secteur du disque par le nombre de secteur à décaler pour avoir le début de la partition. ici 1026048*512=525336576 octets à décaler dans le fichier pour avoir le début de la partition C:)

Installez SRUM-DUMP (attention il y avait une dépendance pétée de mon côté dans le requirements.txt, j’ai du modifier PySimpleGUI-4.1.0 par PySimpleGUI-4.11.0 dans ce fichier) :

$ git clone --branch srum_dump2 http://github.com/markbaggett/srum-dump
$ cd srum-dump
$ sudo -H python3 -m pip install -r requirements.txt

Et enfin lancez le programme en ciblant les fichiers dans le montage comme source :

$ python3 srum_dump2.py -i "/mnt/enisa_part3_c/Windows/System32/sru/SRUDB.dat" -o "/home/etienne/srum-dump/SRUM_DUMP_OUTPUT.xlsx" -t "/home/etienne/srum-dump/SRUM_TEMPLATE2.xlsx" -r "/mnt/enisa_part3_c/Windows/System32/config/SOFTWARE"

Comment on l’analyse le SRUM (System Ressource Utilization Manager)?

Une fois l’extraction SRUM_DUMP vous aura créé un fichier SRUM_DUMP_OUTPUT.xlsx à côté de l’exécutable que vous n’avez plus qu’a analyser. Dans ce fichier plusieurs onglets :

  • ruDbCheckpoint
  • App Timeline Provider
  • Network Data Usage
  • Windows Push Notifications
  • Application Resource Usage
  • vfuprov
  • Network Connectivity Usage
  • Energy Usage
  • Energy Usage LT

La plus intéressante reste la App Timeline Provider à mon sens, mais tous les éléments peuvent avoir un intérêt en fonction de ce que vous cherchez.

SRUM (System Ressource Utilization Manager) analysis srum dump

A quoi ça sert ?

Le SRUM permet donc d’identifier des exécutions de programme ayant eu lieu récemment, y compris si ces derniers ont été supprimés depuis l’éxécution. Il permet aussi de compléter une analyse déjà existante avec des statistiques de fonctionnement d’un ou plusieurs programme, et plus globalement du système. Les informations sur les consommations de ressources peuvent être très intéressantes pour mettre en avant des exfiltrations de données par exemple, ou des interactions de l’utilisateur via les notifications Push de Windows.

Le SRUM fait partie des éléments à ne surtout pas louper dans la construction de votre timeline lors d’une analyse. Il y a plein d’informations dedans, y compris sur la partie réseau. Même si les informations présentes ne permettent de remonter que de quelques jours dans le temps, elles sont suffisamment détaillées pour mettre en évidence des comportements malveillants.

Pour les attaquants, a priori il faut couper le service DPS (Diagnostic Policy Service / Service de stratégie de diagnostic) pour arrêter le SRUM et éviter de laisser des traces la dedans.

Conclusion SRUM (System Ressource Utilization Manager)

Comme d’habitude je vous laisse avec quelques liens pas trop cons sur le sujet avant de terminer :

https://lifars.com/wp-content/uploads/2020/09/SRUM-Another-Windows-Time-Machine.pdf

https://isc.sans.edu/forums/diary/System+Resource+Utilization+Monitor/21927/

https://www.youtube.com/watch?v=l6-83WU95Sw

Sinon, c’est tout pour moi pour aujourd’hui, j’espère que ça vous aura intéressé. De mon côté, je vais continuer la série Forensgeek, autant pour moi que pour vous ! Y’a tellement de trucs à regarder… Fouillez bien vos poubelles… 😉

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.