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 :
- 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).
- le fichier
SRUDB.datdansC:\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.
Cliquez alors sur OK et laissez l’analyse se dérouler.
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
guestmountouqemu-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 UnallocatedvLa 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.
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/
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… 😉
