Reconstruir una timeline de actividad de usuario desde el USN journal

Desde tres minutos de registros $UsnJrnl normalmente puedes reconstruir lo que un usuario estaba haciendo: Office, navegador, descargas, código. Cómo leer el journal como un log de comportamiento.

Por 7 min de lectura

Una gran parte de "¿qué pasaba en este ordenador entre las 14:00 y las 16:00?" se puede contestar directamente del USN journal, sin ningún otro artefacto. Los registros no son un log de syscalls y no están etiquetados con un usuario, pero son algo casi igual de útil: un registro de alta frecuencia, por operación, de cada archivo que la máquina tocó. Con el conocimiento de patrones que cuesta unos pocos engagements construir, puedes recuperar comportamiento a la granularidad de save de Office, navegación de navegador, rebuild de IDE, pausa para comer.

Este post es la guía de campo para leer el journal como una timeline de comportamiento.

Por qué esto funciona en absoluto

La mayoría de acciones visibles al usuario en un escritorio Windows producen una firma reconocible en el sistema de archivos. Haz clic en Save en Word y Word escribe un archivo temp, lo renombra atómicamente y hace BasicInfoChange | Close al resultado. Abre una pestaña nueva en Chrome y el caché de disco se añade. Ejecuta un npm install y mil archivos package.json brotan en segundos.

Estas firmas no están documentadas en ninguna referencia de Microsoft. Se aprenden mirando journals de hosts de experimentos controlados y haciendo match con actividad conocida. Abajo hay un set de partida, ordenado por la frecuencia con la que veo cada uno en casos.

Office en estado salvaje

Cuando un usuario guarda un archivo Word, Excel o PowerPoint ves:

FileCreate | Close            ~$<filename>.docx     (archivo de bloqueo)
FileCreate | Close            <filename>.tmp        (temp atómico)
DataExtend | Close            <filename>.tmp        × N
RenameOldName | Close         <filename>.docx
FileDelete | Close            <filename>.docx
RenameNewName | Close         <filename>.docx       (era <filename>.tmp)
FileDelete | Close            ~$<filename>.docx
BasicInfoChange | Close       <filename>.docx

El archivo de bloqueo ~$ es la señal de Office de que un documento está abierto. Su FileCreate y FileDelete enmarcan la ventana de apertura/cierre con precisión. El rename atómico .tmp a .docx es el guardado en sí. El BasicInfoChange al final es el archivo nuevo recibiendo el stamp de su mtime al cerrar.

Un truco de pivote que uso en cada engagement: filtra por registros FileCreate cuyo nombre empiece con ~$. Eso te da cada documento Office que el usuario abrió en la ventana. Resta FileDelete de los mismos nombres y tienes cualquier documento aún abierto en el momento de adquisición, que en una captura en vivo corresponde a los documentos que el usuario tenía abiertos cuando la máquina fue imagiada. Ese último detalle ha entrado en más de un informe como la respuesta a "¿qué estaba haciendo realmente el usuario en el momento que entramos?".

Actividad de navegador

Los navegadores modernos mantienen cachés pesados en sistema de archivos. Chrome y Edge usan \Users\<u>\AppData\Local\<browser>\User Data\Default\Cache\Cache_Data\ (más Code Cache\). Firefox usa \Users\<u>\AppData\Local\Mozilla\Firefox\Profiles\<id>\cache2\. Durante la navegación:

  • Una tasa baja sostenida de FileCreate | Close y DataExtend | Close en el directorio de caché.
  • FileDelete | Close ocasionales mientras el LRU desaloja entradas viejas.
  • Cada pocos minutos, RenameNewName de archivos de caché mientras el índice se compacta.

Las ráfagas de escrituras de caché correlan con visitar sitios pesados en medios o aplicaciones de página única. Los periodos tranquilos correlan con que el usuario está fuera o en una página de carga larga. La reproducción activa de vídeo produce una forma distinta — DataExtend sostenido grande sobre un único archivo de caché en vez de muchos creates pequeños.

Los nombres de los archivos de caché no codifican URLs. Para eso, pivota a las bases SQLite propias del navegador vía el tooling de forense de navegador. La contribución del journal es la cadencia — que el usuario estaba navegando activamente durante una ventana específica — más los eventos FileCreate explícitos en \Users\<u>\Downloads\ por descargas deliberadas.

Actividad de código

Si el usuario es desarrollador, la actividad de IDE y herramientas de build produce ráfagas altamente características:

  • Webpack, Vite, Turbopack — muchos FileCreate en node_modules\.cache\, node_modules\.vite\, .next\ y dist\. Cientos por build.
  • Visual Studio C++ — FileCreate de archivos .obj y .pdb en subárboles Debug\ o Release\.
  • Cargo (Rust) — Builds incrementales tocan target\debug\incremental\ mucho; builds completas también tocan target\debug\deps\.
  • Go — Ráfagas cortas e intensas en $GOPATH\pkg\ y el caché de build bajo \Users\<u>\AppData\Local\go-build\.
  • npm install y yarn install — Miles de registros FileCreate bajo node_modules\ en decenas de segundos. La actividad de usuario más ruidosa del journal.

Una ráfaga de cinco minutos de FileCreate en node_modules\ seguida de un enjambre DataExtend sobre dist\bundle.js es "corrió el build, luego un servidor de dev recargó". Lee la sección de exclusión abajo — esas ráfagas ahogarán todo lo demás si no las filtras fuera para análisis no de desarrollo.

Descargas e instalaciones

Una descarga directa vía Chrome:

FileCreate | Close             \Users\<u>\Downloads\<file>.crdownload
DataExtend | Close             \Users\<u>\Downloads\<file>.crdownload  × N
RenameNewName | Close          \Users\<u>\Downloads\<file>
BasicInfoChange | Close        \Users\<u>\Downloads\<file>

Firefox usa .part, Edge usa .download. El rename atómico al final es lo que hace que el archivo aparezca "completo" al Explorer y otros lectores.

La instalación de un programa nuevo típicamente sigue: FileCreate de un instalador (.exe, .msi, .appx) en Downloads, luego una ráfaga de registros FileCreate bajo \Program Files\, \Program Files (x86)\ o \Users\<u>\AppData\Local\Programs\. El histograma por minuto hace las instalaciones trivialmente identificables. Cruza con AmCache y Prefetch para el lado de ejecución.

Juntándolo: la receta de timeline diaria

La receta para un informe "qué hizo el usuario hoy":

  1. Saca el journal parseado del usuario para el día. Restringe a registros cuya ruta resuelta empiece con \Users\<u>\ (el usuario objetivo). Esto elimina Windows Update, cachés del sistema y ruido del SO que de otra forma domina.
  2. Calcula, por bucket de 10 minutos: cuentas de FileCreate, DataExtend, BasicInfoChange.
  3. Plotea las tres series. La forma te dice la actividad aproximada:
    • Altos creates más extend. Escribiendo o guardando contenido.
    • Alto BasicInfoChange solo. Navegando, scrolleando, edición ligera donde Office o el editor toca el archivo sin escrituras significativas.
    • Alto extend con bajo create. Descarga grande o reproducción multimedia.
    • Creates sostenidos en rutas Cache\. Navegación.
    • Creates sostenidos en node_modules\ o target\ o Debug\. Programación.
  4. Anota los picos inspeccionando los cinco nombres top en cada bucket. Los nombres Office y los archivos de bloqueo ~$ son anclas excelentes. Los nombres de caché normalmente los puedes ignorar.

El parser de esta página expone el histograma por minuto en su componente timeline. Hacer clic en una barra filtra la tabla a esa ventana, que es el workflow de arriba sin escribir código.

Para atribución — qué usuario estaba al teclado — empareja la timeline del journal con logons interactivos 4624 de Security.evtx (LogonType=2) y logoffs 4647 iniciados por usuario del parser EVTX. Eso enmarca las fronteras de sesión y te da un nombre que poner a la actividad.

Exclusiones y trampas

Los scans de backup y AV producen ráfagas BasicInfoChange a nivel volumen que se parecen superficialmente a actividad de usuario. Siguen horarios programados y visitan cada directorio en vez de centrarse en un subárbol. Fáciles de identificar por cobertura de ruta y excluir.

Los agentes de sync (OneDrive, Dropbox, Google Drive Backup and Sync) generan tráfico de journal que parece actividad de usuario pero es trabajo propio del agente. Filtra a registros fuera de la carpeta de sync para actividad iniciada por usuario, o mira específicamente dentro de la carpeta de sync para el patrón exfil-via-cloud documentado en el post de exfiltración.

Indexadores en segundo plano. SearchIndexer.exe toca archivos en \Users\<u>\AppData\Roaming\Microsoft\Windows\Recent\ y \ProgramData\Microsoft\Search\. MsMpEng.exe (Defender) produce eventos BasicInfoChange cuando escanea. Ambos fáciles de bucketear como ruido del sistema.

Chrome Software Reporter, Edge updater, Windows Update. Todos producen ráfagas predecibles de FileCreate y DataExtend en \Program Files\ y \Windows\SoftwareDistribution\. Filtra por ruta.

node_modules\ y otros outputs de build dominan cualquier timeline que los incluya. Para casos no de desarrollo, excluye node_modules\, target\, Debug\, Release\, obj\, bin\, .next\, dist\, build\ por prefijo de ruta.

Lo que el journal no puede reconstruir

  • La identidad del usuario. Correla timestamps con logons 4624 de Security.evtx.
  • Las URLs que el usuario visitó. Las bases de datos de historial del navegador las contienen — el journal solo conoce la cadencia de escritura de caché.
  • El contenido de cualquier archivo. Solo metadatos.
  • Cualquier cosa fuera de la ventana del ring buffer. Un $J de 32 MB cubre unos pocos días en un escritorio. Cualquier cosa más vieja desaparece de este artefacto; saca shadow copies y $LogFile si necesitas más alcance.

Para el 80% de las preguntas "¿qué hacía el usuario entre X e Y?", $J y $MFT juntos responden directamente. El 20% restante quiere Sysmon, EVTX, SRUM para uso de red y CPU a nivel aplicación, y una super-timeline en condiciones.

Lecturas adicionales