Amcache vs SRUM : présence vs usage de ressources sur fenêtre longue
Si vous avez lu Amcache vs Prefetch et Amcache vs ShimCache, le troisième artefact Windows de preuve d'exécution à connaître est SRUM — le System Resource Usage Monitor.
SRUM et Amcache sont encore plus différents l'un de l'autre qu'Amcache et Prefetch. Ils ne se recoupent que sur le fait que tous deux enregistrent « des binaires qui ont fait quelque chose sur cet hôte ». Au-delà de cela, ils répondent à des questions très différentes.
Les différences phares :
SRUM enregistre l'usage de ressources par application sur une fenêtre de 30-60 jours. Amcache enregistre la présence avec des métadonnées riches, avec une rétention bien plus longue.
Pour la référence Amcache plus large, voir la référence complète Amcache.
Ce qu'est SRUM#
SRUM est la base de données qui supporte le System Resource Usage Monitor de Windows, la fonctionnalité qui alimente les volets « Utilisation des données » et « Utilisation de l'alimentation » dans les paramètres modernes de Windows. Il vit à :
C:\Windows\System32\sru\SRUDB.dat
SRUDB.dat est une base de données ESE (le même format que
mailbox.edb ou la base Active Directory) avec plusieurs tables, les
plus utiles étant :
| Table | Contenu |
|---|---|
Application Resource Usage |
Temps CPU, octets working-set, I/O par application par heure. |
Network Usage |
Octets réseau envoyés / reçus par application par heure. |
Push Notification |
Activité de notification toast / push par application. |
Energy Estimation |
Estimations de consommation d'énergie par application. |
Chaque ligne est regroupée par heure et par application. L'« application » est identifiée par un chemin d'exécutable ou un AppID. Les données SRUM sont mises à jour en continu par le service SRUM et agrégées quotidiennement en aggregats long terme.
La rétention de SRUM est typiquement de 30 à 60 jours mais varie selon le build et la configuration.
La différence fondamentale#
| Propriété | SRUM | Amcache |
|---|---|---|
| Stockage | SRUDB.dat (base ESE) |
Amcache.hve (ruche du registre) |
| Granularité | Par-application, par-heure | Par-fichier |
| Enregistre le hash ? | Non | Oui (SHA-1) |
| Enregistre le chemin complet ? | Oui | Oui |
| Enregistre l'éditeur ? | Non | Oui |
| Enregistre l'exécution ? | Oui (implicitement — si usage > 0) | Non (présence seule) |
| Enregistre CPU / réseau / I/O ? | Oui | Non |
| Enregistre quand il a tourné ? | Oui — à l'heure près. | Non (seulement l'heure d'inventaire). |
| Rétention | 30-60 jours typique | Bien plus longue (années sur hôtes de longue durée). |
| Granularité des horodatages | Buckets horaires | Seconde |
| Facile à analyser ? | Modéré (ESE — utiliser SrumECmd) |
Facile (utiliser AmcacheParser) |
Les deux artefacts sont complémentaires, pas redondants. Utilisez SRUM quand vous vous souciez de l'usage de ressources ; utilisez Amcache quand vous vous souciez de la présence et des métadonnées.
Quand SRUM gagne#
« Combien de réseau ce binaire a-t-il envoyé ? »#
Amcache : pas de réponse. SRUM : octets envoyés / reçus par application par heure. Critique pour les enquêtes d'exfiltration de données.
« Quelles applications ont tourné dans les 30 derniers jours ? »#
Amcache : pas de données d'exécution. SRUM : chaque application avec un CPU ou I/O non nul dans ses buckets horaires a tourné à cette heure.
« Ce binaire a-t-il utilisé le réseau à un moment suspect ? »#
SRUM est le seul artefact qui vous donne une répartition par heure de l'activité réseau par application. Recroisez avec les journaux VPN / firewall pour identifier les fenêtres d'exfiltration.
« Quel était le profil d'usage de ressources de l'hôte dans les jours précédant l'incident ? »#
SRUM est ce qui se rapproche le plus d'un « enregistreur de performance toujours actif » livré par Windows. Les pics de CPU, de réseau ou d'I/O pointent souvent sur de l'activité attaquante.
Quand Amcache gagne#
« Ce binaire était-il présent sur l'hôte ? »#
SRUM n'enregistre que les binaires qui ont fait quelque chose. Un binaire qui était sur disque mais n'a jamais tourné (ou n'a jamais utilisé de ressources mesurables) n'apparaît pas dans SRUM. Amcache l'attrape.
« Quel est le SHA-1 de ce binaire ? »#
SRUM ne hashe pas les binaires. Amcache si. Vous avez besoin d'Amcache pour l'enrichissement VirusTotal ou flux TI.
« Au-delà de la fenêtre SRUM de 30-60 jours »#
La rétention SRUM est courte. Amcache retient régulièrement des entrées pendant des mois ou des années sur des postes de longue durée. Pour les enquêtes couvrant des événements de plus de ~60 jours, Amcache est souvent le seul artefact avec les données.
« Preuves de pilote / périphérique »#
SRUM concerne les applications et l'usage de ressources. Amcache
possède des schémas dédiés InventoryDriverBinary et
InventoryDeviceContainer pour les artefacts kernel-mode et
périphérique.
« Hunt cross-hôtes par hash ou ProgramId »#
SRUM n'a ni hashes ni ProgramId. Amcache si. Voir
Mouvement latéral et pivot avec le ProgramId Amcache.
Le pairing classique SRUM + Amcache#
La combinaison est la plus puissante pour les enquêtes d'exfiltration :
- Depuis SRUM, trouvez les applications avec un usage réseau
anormal dans la fenêtre d'exfil suspectée (ex. lignes
Network Usagemontrant des gigaoctets d'octets envoyés pour un binaire qui n'envoie normalement rien). - Depuis Amcache, prenez le chemin ou nom d'exécutable du même
binaire et cherchez son
Hash,Publisher,LinkDateetKeyLastWriteTimestamp. Vous avez maintenant un hash de contenu à soumettre à VirusTotal et une approximation de first-seen pour le moment où le binaire est arrivé. - Depuis Prefetch, confirmez les horodatages d'exécution qui s'alignent sur les pics réseau SRUM.
Cette triple jointure — Prefetch (quand a-t-il tourné) + SRUM (qu'a- t-il fait) + Amcache (qu'est-ce que c'est) — est le workflow canonique de preuve d'exécution Windows.
Table de décision rapide#
| Votre question | SRUM | Amcache |
|---|---|---|
| Le binaire X était-il sur cet hôte ? | partiel (seulement s'il a utilisé des ressources) | oui |
| Quel est le SHA-1 du binaire X ? | ✗ | ✓ |
| Quand le binaire X est-il apparu pour la première fois ? | seulement s'il a utilisé des ressources | ✓ |
| Le binaire X a-t-il utilisé le réseau ? | ✓ | ✗ |
| Combien d'octets le binaire X a-t-il envoyés ? | ✓ | ✗ |
| Quel était le profil CPU de l'hôte la semaine dernière ? | ✓ | ✗ |
| Présence sur fenêtre longue (>60 jours) ? | ✗ | ✓ |
| Preuves pilote / périphérique ? | ✗ | ✓ |
| Hunt cross-hôtes ? | ✗ | ✓ |
Voir aussi#
- Référence complète Amcache — l'artefact en intégralité.
- Amcache vs Prefetch — comparaison de preuve d'exécution.
- Amcache vs ShimCache — l'autre artefact de preuve de présence.
- Amcache pour l'investigation de malware — comment les quatre artefacts se combinent dans un playbook réel.
Pour un coup d'œil rapide côté navigateur sur votre ruche, déposez un fichier sur la page d'accueil de l'analyseur — il s'analyse entièrement dans votre navigateur.
Articles liés
- Amcache vs ShimCache : quand chaque artefact gagne
ShimCache et Amcache enregistrent tous deux les binaires ayant touché un hôte Windows. Ce sont des mécanismes différents avec des limites différentes — voici quand utiliser chacun, et ce que prouve réellement leur recoupement.
- Amcache vs Prefetch : ce que chacun prouve vraiment
Amcache enregistre la présence ; Prefetch enregistre l'exécution. Une référence pratique pour savoir quand utiliser chacun, sur quoi ils se recoupent, et comment les combiner dans une timeline DFIR.
- Comparatif des analyseurs Amcache : AmcacheParser CLI, outil navigateur, Volatility, RegRipper
Comparaison côte à côte des quatre façons d'analyser une ruche Windows Amcache.hve en 2026 — AmcacheParser CLI d'Eric Zimmerman, outil navigateur, Volatility 3 et RegRipper.
- Volatility et Amcache : extraire la ruche depuis des images mémoire
Un guide pratique pour récupérer Amcache depuis une image mémoire Windows en utilisant Volatility — quand la récupération côté mémoire est la seule option, quels plugins utiliser, et comment passer le relais à AmcacheParser.