Sin embargo, Windows conserva un artefacto que a veces pasa desapercibido: SRUM (System Resource Usage Monitor).
Este artefacto permite examinar el consumo de recursos y, en determinados sistemas, los bytes enviados y recibidos por aplicación.
Hoy vamos a ver cómo adquirirlo, procesarlo e interpretarlo correctamente, incluyendo algunas novedades de SrumECmd 2026.10.0.
Cuando tenemos el volumen, pero no el destino
Imaginemos que, durante una investigación, encontramos referencias a una aplicación de sincronización de archivos.
Sabemos que estuvo presente en el equipo, pero no disponemos de un PCAP y los registros de red se han perdido.
La pregunta no debería ser todavía «¿qué documentos se han filtrado?», sino algo más básico:
¿Hay indicios de que esa aplicación intercambió datos por la red durante el periodo investigado?
Aquí puede ayudarnos SRUM.
Windows utiliza este mecanismo para contabilizar el consumo de recursos de aplicaciones y del sistema. Parte de esa información aparece en el Administrador de tareas, aunque la base de datos conserva más campos de los que muestra la interfaz.
La evidencia reside normalmente en:
%SystemRoot%\System32\sru\SRUDB.datSe trata de una base de datos ESE (Extensible Storage Engine).
Para enriquecer la interpretación conviene conservar también el hive SOFTWARE del Registro de Windows y, si existen, los registros transaccionales de la carpeta sru.
La guía de Microsoft Incident Response señala SRUM como un artefacto relevante para estudiar la actividad de aplicaciones, las identidades asociadas y el consumo de red.
Pero advierte de dos limitaciones importantes:
Sus marcas temporales no equivalen necesariamente al instante exacto de ejecución.
La información de uso de red en Windows Server no está poblada del mismo modo que en Windows de escritorio.
¿Qué información podemos obtener?
Los conjuntos de datos disponibles varían según la versión de Windows y los proveedores presentes.
Para un triaje inicial, tres salidas de SrumECmd resultan especialmente interesantes:
| Salida | Información |
|---|---|
AppResourceUseInfo | Actividad de aplicaciones, consumo de recursos e identidad asociada. |
NetworkUsages | Bytes enviados y recibidos por aplicación, usuario e interfaz. |
NetworkConnections | Información de conectividad y perfiles de red. |
También podemos encontrar AppTimelineProvider, que contiene métricas relacionadas con la actividad de aplicaciones.
En la versión 2026.10.0 de SrumECmd se han incorporado campos adicionales relacionados con el tiempo en primer plano, la interacción mediante teclado y ratón, el audio y otros indicadores, cuando el proveedor correspondiente dispone de esa información.
Una consideración importante sobre los timestamps
Los registros de SRUM no deben interpretarse como eventos individuales de ejecución.
Un Timestamp suele corresponder al registro o consolidación de una muestra.
Por tanto, una entrada con una marca temporal determinada no significa necesariamente que la aplicación comenzara a ejecutarse en ese instante.
Habitualmente trabajaremos con una granularidad aproximada de una hora, no de segundos.
Y esto es especialmente importante cuando intentamos reconstruir una cronología.
1. Adquisición de SRUM
Como ocurre con cualquier evidencia digital, antes de procesar debemos preservar.
En un análisis offline, lo más adecuado es trabajar sobre una imagen forense o una instantánea coherente del volumen.
Si realizamos la adquisición sobre un equipo encendido, debemos documentar el mecanismo utilizado para obtener los archivos abiertos.
Los artefactos que conviene localizar son:
C:\Windows\System32\sru\SRUDB.dat
C:\Windows\System32\sru\SRU*.log
C:\Windows\System32\sru\SRU.chk
C:\Windows\System32\sru\*.jrs
C:\Windows\System32\config\SOFTWARENo todos estos ficheros tienen que existir en cualquier sistema.
Los archivos transaccionales son especialmente importantes porque pueden ser necesarios para recuperar un estado consistente de la base de datos.
Copiar únicamente SRUDB.dat puede resultar insuficiente.
Una vez adquiridas las evidencias, podemos calcular los hashes de las copias de trabajo:
Get-ChildItem 'D:\Caso\Evidencia\sru' -File |
Get-FileHash -Algorithm SHA256 |
Export-Csv 'D:\Caso\Resultados\hashes_sru.csv' -NoTypeInformation
Get-FileHash 'D:\Caso\Evidencia\SOFTWARE' -Algorithm SHA256El directorio de resultados debe existir previamente.
Estos hashes permiten verificar los archivos utilizados durante el análisis, pero no sustituyen los controles de integridad realizados durante la adquisición original.
2. Procesamiento con SrumECmd
Para procesar este artefacto podemos utilizar SrumECmd, desarrollado por Eric Zimmerman.
Su sintaxis permite indicar directamente la base de datos y el hive SOFTWARE:
SrumECmd.exe -f "D:\Caso\Evidencia\sru\SRUDB.dat" `
-r "D:\Caso\Evidencia\SOFTWARE" `
--csv "D:\Caso\Resultados\SRUM" `
--temp "D:\Caso\Trabajo\SrumTemp"Los parámetros utilizados son:
| Parámetro | Función |
|---|---|
-f | Ruta de SRUDB.dat. |
-r | Hive SOFTWARE para ayudar a resolver identificadores. |
--csv | Directorio de salida de los informes. |
--temp | Directorio temporal utilizado durante el procesamiento. |
SrumECmd utiliza el motor ESE de Windows, por lo que este procedimiento debe ejecutarse en un entorno Windows compatible.
Novedades de SrumECmd 2026.10.0
Aquí tenemos una mejora interesante.
Según la documentación oficial, SrumECmd ya no necesita abrir directamente la base de datos original para realizar el procesamiento.
La herramienta crea una copia temporal de SRUDB.dat y de los registros transaccionales disponibles.
Si la base de datos se encuentra en estado dirty, intenta reproducir esos registros sobre la copia.
Cuando los registros necesarios no están disponibles y la base continúa sin poder abrirse, puede recurrir a una reparación sobre la copia temporal.
Esto simplifica el trabajo del analista, pero debemos tener presente algo:
Una base de datos reparada no implica necesariamente una recuperación íntegra de su contenido.
Si faltan registros transaccionales, determinada información podría perderse durante la recuperación.
Por eso debemos conservar:
La evidencia original.
Los registros transaccionales adquiridos.
La versión de SrumECmd utilizada.
La salida de consola y sus advertencias.
Cualquier indicación de recuperación o reparación.
Y, por supuesto, nunca ejecutar operaciones de reparación sobre la evidencia original.
3. Analizando el consumo de red
Una vez procesada la base de datos, podemos comenzar por el informe NetworkUsages.
Los campos que nos interesan especialmente son:
| Campo | Interpretación |
|---|---|
Timestamp | Marca temporal de la muestra registrada. |
ExeInfo | Información de la aplicación o ejecutable. |
Sid | Identificador de seguridad asociado. |
BytesSent | Bytes enviados contabilizados. |
BytesRecvd | Bytes recibidos contabilizados. |
InterfaceType | Tipo de interfaz de red. |
Los nombres de las columnas pueden variar según la versión del parser.
Para automatizar el análisis siempre debemos comprobar previamente la estructura del CSV generado.
Laboratorio sintético
Para ilustrar el procedimiento he preparado un pequeño laboratorio que no utiliza evidencias reales.
El siguiente CSV representa un conjunto de registros ficticios, con un subconjunto de columnas habituales:
Timestamp,ExeInfo,Sid,BytesSent,BytesRecvd,InterfaceType
2026-10-21 09:00:00,C:\Lab\sync_demo.exe,S-1-5-21-111-222-333-1001,104857600,1048576,6
2026-10-21 10:00:00,C:\Lab\sync_demo.exe,S-1-5-21-111-222-333-1001,52428800,2097152,6
2026-10-21 10:00:00,C:\Windows\System32\notepad.exe,S-1-5-21-111-222-333-1001,1024,4096,6
2026-10-21 11:00:00,C:\Lab\backup_demo.exe,S-1-5-21-111-222-333-1002,20971520,10485760,71El objetivo es identificar aplicaciones con un volumen significativo de tráfico saliente.
Para ello podemos utilizar el script Python analizar_srum_csv.py incluido con el laboratorio.
Este script agrupa los registros por aplicación y SID, suma los bytes enviados y recibidos y aplica un umbral configurable.
También admite las variantes de columna BytesRecvd y BytesReceived.
Ejecutamos:
python analizar_srum_csv.py networkusages_sintetico.csv 10El último argumento establece un umbral de 10 MiB enviados.
Resultado del laboratorio
La ejecución sobre el CSV sintético produce:
Aplicacion | SID/Usuario | Enviado (MiB) | Recibido (MiB) | Filas
C:\Lab\sync_demo.exe | S-1-5-21-111-222-333-1001 | 150.00 | 3.00 | 2
C:\Lab\backup_demo.exe | S-1-5-21-111-222-333-1002 | 20.00 | 10.00 | 1
Total de pares aplicacion/usuario: 3
Nota: volumen agregado de red, NO prueba de exfiltracion ni destino.Estos resultados han sido comprobados ejecutando el laboratorio.
Podemos observar que sync_demo.exe acumula 150 MiB enviados.
Pero ¿qué significa realmente?
Únicamente que, en este escenario sintético, los registros contabilizan ese volumen de tráfico saliente para la aplicación y el SID indicados.
No sabemos qué información se transmitió, a qué destino ni por qué motivo.
Y esa diferencia es fundamental.
4. Cuatro errores habituales al interpretar SRUM
Error 1. Confundir tráfico saliente con exfiltración
Que una aplicación haya transmitido 150 MiB no significa que se hayan filtrado 150 MiB de información.
Ese volumen podría corresponder a:
Sincronización legítima.
Copias de seguridad.
Tráfico propio de una aplicación.
Transferencias autorizadas.
Reintentos de comunicación.
SRUM no identifica por sí solo el contenido de una transferencia.
Tampoco proporciona necesariamente el destino remoto.
Error 2. Considerar el timestamp como una ejecución exacta
Una entrada de SRUM no equivale a un evento de creación de proceso.
Las marcas temporales permiten establecer ventanas aproximadas de actividad, pero no reconstruir por sí solas cada ejecución.
Para precisar la cronología debemos correlacionar con otras evidencias.
Error 3. Atribuir automáticamente la actividad a una persona
SRUM puede asociar registros a un SID.
Sin embargo, un SID identifica una cuenta o contexto de seguridad, no necesariamente a la persona que estaba utilizando físicamente el equipo.
Debemos considerar:
Sesiones interactivas.
Cuentas de servicio.
Procesos automatizados.
Tareas programadas.
Contextos de ejecución delegados.
La atribución requiere evidencias adicionales.
Error 4. Interpretar la ausencia de registros como ausencia de actividad
Que no encontremos una aplicación en SRUM no demuestra que nunca se haya ejecutado.
La información disponible depende de factores como la retención, la versión del sistema, los proveedores habilitados y la integridad de la adquisición.
También debemos recordar que la información de consumo de red en Windows Server no presenta necesariamente el mismo comportamiento que en Windows de escritorio.
5. Correlación con otros artefactos
Aquí es donde realmente empieza la investigación.
Imaginemos que identificamos una aplicación con un volumen de tráfico saliente que merece ser investigado.
Podemos seguir varias líneas de análisis.
Identificación del ejecutable
Localizar la ruta, comprobar el hash si el fichero sigue disponible y analizar sus metadatos.
Amcache puede ayudarnos a determinar si un binario estuvo presente, aunque no debemos interpretar automáticamente esa presencia como prueba de ejecución.
Reconstrucción temporal
Utilizar las muestras de SRUM para delimitar una ventana aproximada.
Después, correlacionar con Prefetch, eventos de creación de procesos y otras fuentes disponibles.
Por ejemplo, el evento 4688 de Windows Security o el Event ID 1 de Sysmon, cuando esos mecanismos de auditoría estaban habilitados.
Identificación de destinos
Buscar registros de cortafuegos, proxy, DNS o EDR.
Si existía Sysmon con el registro de conexiones habilitado, su Event ID 3 también puede aportar información.
SRUM no sustituye esas fuentes.
Análisis de la información potencialmente transferida
Investigar accesos a archivos, creación de comprimidos, directorios de preparación y actividad de aplicaciones de transferencia.
El objetivo es establecer si existe una relación verificable entre los datos accesibles, los procesos ejecutados y las comunicaciones observadas.
¿Qué podemos concluir?
Debemos distinguir entre tres afirmaciones:
Se ha identificado actividad de red contabilizada para una aplicación.
Se ha identificado una transferencia hacia un destino concreto.
Se ha confirmado la exfiltración de determinada información.
No son conclusiones equivalentes.
Cada una requiere un nivel diferente de evidencia.
Conclusión
SRUM es uno de esos artefactos que pueden aportar información valiosa cuando no disponemos de toda la visibilidad que nos gustaría tener.
No sustituye un PCAP, un EDR ni los registros del proxy.
Pero puede ayudarnos a identificar aplicaciones, usuarios y periodos que merecen una investigación más profunda.
La actualización de SrumECmd en octubre de 2026 facilita el tratamiento de bases ESE en estado dirty y amplía algunas métricas exportadas.
Eso reduce parte del trabajo manual, aunque no elimina la necesidad de preservar los originales y documentar cualquier recuperación realizada sobre las copias.
Y, sobre todo, debemos recordar algo:
En DFIR, medir actividad no es lo mismo que atribuir una acción.
La diferencia está en la correlación, la integridad de la adquisición y la prudencia con la que redactamos nuestras conclusiones.
Referencias técnicas
Microsoft Incident Response — Guidance for Incident Responders, apartado SRUM
Eric Zimmerman — SrumECmd, repositorio y documentación oficial
Material complementario: laboratorio sintético networkusages_sintetico.csv y script analizar_srum_csv.py.
0 Comentarios