Amcache en Windows Server: cadencia, cobertura y peculiaridades

Amcache en Windows Server usa el mismo formato de hive y el mismo schema Inventory* que Windows 10 / 11 (cubierto en Amcache en Windows 11). Las diferencias están en cadencia, cobertura y contexto operativo — ninguna de las cuales cambia cómo parseas, pero todas cambian cómo razonas sobre los datos.

Esta página es la referencia específica de Server para analistas DFIR trabajando en Server 2016, 2019, 2022, 2025 y las ediciones Server Core correspondientes.

Para la referencia más amplia del artefacto, ver la referencia completa de Amcache. Para la ruta y el flujo de recolección en cualquier Windows, ver Dónde está Amcache.hve en disco.


Qué es lo mismo#

En Windows Server 2016 en adelante, obtienes:

  • La misma ruta de archivo: C:\Windows\AppCompat\Programs\Amcache.hve + .LOG1 + .LOG2.
  • El mismo schema Inventory* que Windows 10 1709+ / Windows 11.
  • El mismo AmcacheParser.exe produce las mismas categorías CSV.
  • Aplican los mismos filtros de triage (PE sin firmar en ruta escribible por usuario, etc.).

Puedes usar los mismos playbooks, consultas y herramientas. Los pivotes cross-host descritos en Movimiento lateral y pivote ProgramId de Amcache funcionan a través de entornos mixtos de estación de trabajo + servidor sin modificación.


Qué es diferente#

La cadencia del appraiser es más lenta#

La tarea programada Compatibility Appraiser corre menos frecuentemente en Servers que en estaciones de trabajo. Intervalos típicos:

  • Estación de trabajo (Windows 10 / 11): ~24 h.
  • Server con Desktop Experience: 2–5 días entre corridas.
  • Server Core: semanalmente o más; a veces solo por disparador de política.

La consecuencia: la precisión de KeyLastWriteTimestamp en un hive Server es más holgada que en un hive de estación de trabajo. La primera aparición de un binario en Amcache puede retrasarse varios días respecto a su primera aparición en disco. Para investigaciones que necesitan precisión de hora en tiempos de first-seen, recurre a marcas de tiempo de Sysmon / Security 4688 / MFT.

Menos actividad interactiva → hives más pequeños#

Un hive típico de Server es más pequeño que un hive de estación de trabajo de la misma edad:

  • Pocas o ninguna entrada \Users\<x>\AppData\... — las cuentas de servidor rara vez inician sesión interactivamente.
  • Menos binarios ad-hoc — los servidores de producción ejecutan un conjunto estable de servicios.
  • Los registros de driver y dispositivo son estables (los servidores rara vez conectan nuevos dispositivos USB / Bluetooth).

Tamaños:

Tipo de servidor Tamaño típico del hive (1 año)
Server Core (producción) 2–6 MB
Server con Desktop Experience (producción) 4–10 MB
Server con Desktop Experience (jumphost, RDP admin) 10–25 MB
Controlador de dominio 4–12 MB

Un jumphost — un servidor en el que los admins hacen RDP para trabajo cross-domain — tiende a parecerse más a una estación de trabajo que a un servidor: mucha actividad interactiva, muchas herramientas administrativas, muchas descargas ad-hoc. Estos son también los hives Server de mayor valor en la mayoría de las investigaciones.

Menos ruido de LOLBIN, más señal de LOLBIN#

Los servidores ejecutan un conjunto estrecho de LOLBINs (net.exe, wmic.exe, schtasks.exe, PowerShell). Cualquier ejecución inusual de LOLBIN en un servidor de producción destaca. Los filtros de triage pueden ser más estrictos:

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

Si el binario aparece en Amcache y el KeyLastWriteTimestamp es reciente, cruza con Security 4688 para la ejecución real de línea de comandos. En un servidor, cada uso de línea de comandos de estas herramientas vale la pena revisar.


Aspectos específicos de Server Core#

Server Core (sin Desktop Experience) es el modo de instalación más ligero usado para cargas de trabajo de producción donde el acceso admin ocurre vía PowerShell remoting o las UIs de gestión. Peculiaridades:

Appraiser aún más lento#

Intervalos del appraiser de Server Core de una semana o más son normales. Un hive que no se ha actualizado en dos semanas no es necesariamente sabotaje.

Sin datos interactivos de menú Inicio / accesos directos#

InventoryApplicationShortcut es escaso o vacío — no hay menú Inicio que inventariar. No pivotes sobre datos de acceso directo en Server Core.

Instalaciones muy hardenizadas / bloqueadas#

Algunos builds hardenizados de Server Core desactivan el appraiser completamente. En esos, Amcache está congelado en el momento de instalación o poco después. Comprueba la tarea programada del appraiser y el valor del registro HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\AmcacheUpdater\DisableScheduled (el nombre varía según build) para confirmar.

Si el appraiser está intencionadamente desactivado, Amcache no es un artefacto útil en ese host. Recurre a Sysmon, EDR y los logs de eventos regulares de Windows.


Servers hardenizados / sin CEIP#

Algunas organizaciones desactivan el Customer Experience Improvement Program (CEIP) y la telemetría relacionada en servidores de producción por política. El appraiser es parte de esa infraestructura de telemetría; desactivar CEIP a menudo desactiva el appraiser por efecto colateral.

Señales de que el appraiser ha sido desactivado:

  • Amcache.hve existe pero tiene una distribución de KeyLastWriteTimestamp que se detiene en la hora de instalación
    • unos días, sin entradas más nuevas.
  • El hive es pequeño (<2 MB en un servidor de larga ejecución).
  • La tarea programada \Microsoft\Windows\Application Experience\Microsoft Compatibility Appraiser está desactivada o tiene un LastRunTime coincidente con la fecha de instalación.
  • HKLM\SOFTWARE\Policies\Microsoft\Windows\DataCollection\AllowTelemetry está puesto a 0 por GPO.

En estos hosts, Amcache no es el artefacto correcto. Usa:

  • Sysmon para telemetría en tiempo real de proceso / archivo / red (asumiendo que está desplegado).
  • Log de eventos de seguridad con auditoría de línea de comandos habilitada (4688 con ProcessCmdLine).
  • Log operacional de PowerShell para ejecución de scripts.
  • EDR para inventario y ejecución de binarios.

Controladores de dominio#

Los DCs son un caso especial que vale la pena tratar con cuidado extra:

  • Son servidores, así que aplican todas las advertencias de cadencia de Server.
  • Son los objetivos de mayor valor en cualquier entorno, así que cualquier entrada de Amcache apuntando a un binario desconocido merece triage inmediato.
  • Muchas organizaciones restringen el logon interactivo en DCs, así que la presencia de cualquier fila \Users\<admin>\AppData\... en un DC es en sí misma inusual y vale la pena investigar independientemente del hash del binario.

Un filtro base útil para DCs:

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

Cualquier resultado no vacío en un DC justifica atención directa.


RDS / Citrix / hosts de sesión multi-usuario#

Los Remote Desktop Session Hosts y los servidores Citrix son los servidores más parecidos a estaciones de trabajo desde una perspectiva Amcache:

  • Muchos perfiles de usuario → muchas rutas \Users\ para hacer triage.
  • Mucha actividad interactiva → mucho churn de inventario.
  • Frecuentemente usados como jumphosts y puntos de pivote.

En estos, trata el hive como tratarías un hive de estación de trabajo — pero con la cadencia más lenta del appraiser en mente. El filtro "PE sin firmar en ruta escribible por usuario" es el punto de partida más productivo.


Escenarios de cluster / failover#

En Windows Server Failover Clustering, cada nodo tiene su propio Amcache.hve. Recoge de cada nodo — un binario que apareció en un nodo del cluster puede no haber aparecido en otros, especialmente si el atacante comprometió solo uno.

Para investigaciones en servicios de alta disponibilidad (SQL AlwaysOn, Exchange DAG, clusters Hyper-V), el Amcache por nodo forma parte del set de recolección estándar junto al log del cluster (Get-ClusterLog) y los logs a nivel de aplicación.


Tabla de decisión rápida#

Tipo de servidor ¿Usar Amcache? Notas
Servidor de app de producción (estable) Cadencia más lenta; tasa de FP muy baja; cualquier hit es significativo.
Base de datos / DC Sí, con cuidado Hosts de atención especial; filtro ajustado en rutas de usuario.
Jumphost / RDS / Citrix Sí — primario Hive Server de mayor valor; trata como estación de trabajo.
Server Core hardenizado (CEIP off) No Hive congelado; usa Sysmon / EDR en su lugar.
Nodo de cluster de failover Sí — recoge todos los nodos Análisis por nodo; cruza-correlaciona.

Ver también#

Para explorar un hive Server sin instalar nada, suelta el archivo en la página de inicio del parser — se parsea enteramente en tu navegador.

Artículos relacionados

Volver a todos los artículos