Amcache sur Windows Server : cadence, couverture et particularités

Amcache sur Windows Server utilise le même format de ruche et le même schéma Inventory* que Windows 10 / 11 (couvert dans Amcache sur Windows 11). Les différences sont dans la cadence, la couverture et le contexte d'exploitation — aucune ne change la façon dont vous analysez, mais toutes changent la façon dont vous raisonnez sur les données.

Cette page est la référence spécifique au Serveur pour les analystes DFIR travaillant sur Server 2016, 2019, 2022, 2025 et les éditions Server Core correspondantes.

Pour la référence plus large sur l'artefact, voir la référence complète Amcache. Pour le chemin et le workflow de collecte sur tout Windows, voir Où se trouve Amcache.hve sur disque.

Ce qui est identique#

Sur Windows Server 2016 et au-delà, vous obtenez :

Le même chemin de fichier : C:\Windows\AppCompat\Programs\Amcache.hve + .LOG1 + .LOG2.
Le même schéma Inventory* que Windows 10 1709+ / Windows 11.
Le même AmcacheParser.exe produit les mêmes catégories CSV.
Les mêmes filtres de triage s'appliquent (PE non signé dans chemin inscriptible par l'utilisateur, etc.).

Vous pouvez utiliser les mêmes playbooks, requêtes et outils. Les pivots cross-hôtes décrits dans Mouvement latéral et pivot avec le ProgramId Amcache fonctionnent à travers les environnements mixtes poste de travail + serveur sans modification.

Ce qui est différent#

La cadence de l'appraiser est plus lente#

La tâche planifiée Compatibility Appraiser tourne moins fréquemment sur les Serveurs que sur les postes de travail. Intervalles typiques :

Poste de travail (Windows 10 / 11) : ~24 h.
Serveur avec Desktop Experience : 2-5 jours entre runs.
Server Core : hebdomadaire ou plus ; parfois seulement sur déclenchement par politique.

La conséquence : la précision de KeyLastWriteTimestamp sur une ruche Serveur est plus lâche que sur une ruche poste de travail. La première apparition d'un binaire dans Amcache peut être en retard de plusieurs jours par rapport à sa première apparition sur disque. Pour les enquêtes qui ont besoin d'heures de first-seen à la précision horaire, repliez-vous sur Sysmon / Security 4688 / horodatages MFT.

Moins d'activité interactive → ruches plus petites#

Une ruche Serveur typique est plus petite qu'une ruche poste de travail du même âge :

Peu ou pas d'entrées \Users\<x>\AppData\... — les comptes serveur se connectent rarement de façon interactive.
Moins de binaires ad-hoc — les serveurs de production exécutent un ensemble stable de services.
Les enregistrements de pilote et de périphérique sont stables (les serveurs connectent rarement de nouveaux périphériques USB / Bluetooth).

Tailles :

Type de serveur	Taille de ruche typique (1 an)
Server Core (production)	2-6 Mo
Serveur avec Desktop Experience (production)	4-10 Mo
Serveur avec Desktop Experience (jumphost, admin RDP)	10-25 Mo
Contrôleur de domaine	4-12 Mo

Un jumphost — un serveur sur lequel les admins font du RDP pour du travail cross-domaine — tend à ressembler plus à un poste de travail qu'à un serveur : beaucoup d'activité interactive, beaucoup d'outillage administratif, beaucoup de téléchargements ad-hoc. Ce sont aussi les ruches Serveur de plus haute valeur dans la plupart des enquêtes.

Moins de bruit LOLBIN, plus de signal LOLBIN#

Les serveurs exécutent un ensemble étroit de LOLBINs (net.exe, wmic.exe, schtasks.exe, PowerShell). Toute exécution LOLBIN inhabituelle sur un serveur de production se démarque. Les filtres de triage peuvent être plus serrés :

Import-Csv .\SERVER01_amcache_AssociatedFileEntries.csv |
  Where-Object {
    $_.FullPath -match '\\System32\\(net|wmic|schtasks|certutil|bitsadmin|regsvr32)\.exe$'
  }

Si le binaire apparaît dans Amcache et le KeyLastWriteTimestamp est récent, recroisez avec Security 4688 pour l'exécution réelle de ligne de commande. Sur un serveur, chaque usage en ligne de commande de ces outils vaut un coup d'œil.

Spécificités Server Core#

Server Core (sans Desktop Experience) est le mode d'installation plus léger utilisé pour les charges de travail de production où l'accès admin se fait via PowerShell remoting ou les UIs de gestion. Particularités :

Appraiser encore plus lent#

Les intervalles d'appraiser Server Core d'une semaine ou plus sont normaux. Une ruche qui n'a pas été mise à jour depuis deux semaines n'est pas nécessairement du sabotage.

InventoryApplicationShortcut est éparse ou vide — il n'y a pas de menu Démarrer à inventorier. Ne pivotez pas sur les données de raccourci sur Server Core.

Installs lourdement durcis / verrouillés#

Certains builds Server Core durcis désactivent l'appraiser entièrement. Sur ceux-ci, Amcache est figé au moment de l'install ou peu après. Vérifiez la tâche planifiée de l'appraiser et la valeur du registre HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\AmcacheUpdater\DisableScheduled (le nom varie selon le build) pour confirmer.

Si l'appraiser est intentionnellement désactivé, Amcache n'est pas un artefact utile sur cet hôte. Repliez-vous sur Sysmon, EDR et les journaux d'événements Windows réguliers.

Serveurs durcis / non-CEIP#

Certaines organisations désactivent le Customer Experience Improvement Program (CEIP) et la télémétrie associée sur les serveurs de production par politique. L'appraiser fait partie de cette infrastructure de télémétrie ; désactiver CEIP désactive souvent l'appraiser par effet de bord.

Signes que l'appraiser a été désactivé :

Amcache.hve existe mais a une distribution de KeyLastWriteTimestamp qui s'arrête à l'heure d'install + quelques jours, sans entrées plus récentes.
La ruche est petite (<2 Mo sur un serveur de longue durée).
La tâche planifiée \Microsoft\Windows\Application Experience\Microsoft Compatibility Appraiser est désactivée ou a un LastRunTime correspondant à la date d'install.
HKLM\SOFTWARE\Policies\Microsoft\Windows\DataCollection\AllowTelemetry est défini à 0 par GPO.

Sur ces hôtes, Amcache n'est pas le bon artefact. Utilisez :

Sysmon pour la télémétrie processus / fichier / réseau en temps réel (en supposant qu'il soit déployé).
Journal d'événements Security avec l'audit de ligne de commande activé (4688 avec ProcessCmdLine).
Journal opérationnel PowerShell pour l'exécution de scripts.
EDR pour l'inventaire de binaires et l'exécution.

Contrôleurs de domaine#

Les DCs sont un cas spécial qui mérite d'être traité avec un soin particulier :

Ce sont des serveurs, donc toutes les réserves de cadence Serveur s'appliquent.
Ce sont les cibles de plus haute valeur dans tout environnement, donc toute entrée Amcache pointant sur un binaire non familier mérite un triage immédiat.
De nombreuses organisations restreignent la connexion interactive aux DCs, donc la présence de toute ligne \Users\<admin>\AppData\... sur un DC est elle-même inhabituelle et vaut la peine d'être enquêtée indépendamment du hash du binaire.

Un filtre de baseline utile pour les DCs :

Import-Csv .\DC01_amcache_UnassociatedFileEntries.csv |
  Where-Object {
    $_.FullPath -match '\\Users\\' -and
    $_.IsPeFile -eq 'True'
  }

Tout résultat non vide sur un DC mérite une attention directe.

RDS / Citrix / hôtes de session multi-utilisateurs#

Les Remote Desktop Session Hosts et serveurs Citrix sont les serveurs les plus poste-de-travail-like du point de vue Amcache :

Nombreux profils utilisateur → nombreux chemins \Users\ à trier.
Beaucoup d'activité interactive → beaucoup de churn d'inventaire.
Fréquemment utilisés comme jumphosts et points de pivot.

Sur ceux-ci, traitez la ruche comme vous le feriez pour une ruche de poste de travail — mais avec la cadence plus lente de l'appraiser en tête. Le filtre « PE non signé dans chemin inscriptible par l'utilisateur » est le point de départ le plus productif.

Scénarios cluster / failover#

Sur Windows Server Failover Clustering, chaque nœud a son propre Amcache.hve. Collectez depuis chaque nœud — un binaire qui est apparu sur un nœud de cluster peut ne pas être apparu sur les autres, surtout si l'attaquant n'a compromis qu'un seul.

Pour les enquêtes sur les services hautement disponibles (SQL AlwaysOn, Exchange DAG, clusters Hyper-V), l'Amcache par-nœud fait partie de l'ensemble de collecte standard aux côtés du log de cluster (Get-ClusterLog) et des logs au niveau application.

Table de décision rapide#

Type de serveur	Utiliser Amcache ?	Notes
Serveur d'app de production (stable)	Oui	Cadence plus lente ; taux FP très bas ; tout hit est significatif.
Base de données / DC	Oui, avec soin	Hôtes attention-spéciale ; filtre serré sur chemins utilisateur.
Jumphost / RDS / Citrix	Oui — primaire	Ruche Serveur de plus haute valeur ; traiter comme poste de travail.
Server Core durci (CEIP off)	Non	Ruche figée ; utiliser Sysmon / EDR à la place.
Nœud de cluster failover	Oui — collecter tous les nœuds	Analyse par-nœud ; recroiser.

Voir aussi#

Référence complète Amcache — l'artefact en intégralité.
Amcache sur Windows 11 et Windows 10 — contrepartie desktop avec notes de schéma build par build.
Où se trouve Amcache.hve sur disque — patterns de collecte pour tout Windows.
Amcache pour l'investigation de malware — le playbook poste de travail (fonctionne aussi sur jumphosts / RDS).
Mouvement latéral et pivot avec le ProgramId Amcache — pivots cross-hôtes sur des parcs mixtes poste de travail + serveur.

Pour explorer une ruche Serveur sans rien installer, déposez le fichier sur la page d'accueil de l'analyseur — il s'analyse entièrement dans votre navigateur.