Leer archivos .evtx sin una máquina Windows

El registro nunca está en la máquina en la que estás sentado

El patrón es siempre el mismo. Algo ha pasado — una sospecha de compromiso, una tormenta de bloqueos de cuentas, un servicio que murió a las 03:00 — y la prueba es un registro de eventos de Windows que alguien exportó, copió en una imagen o extrajo de una máquina que no puedes arrancar, en la que no puedes iniciar sesión o que no tienes licencia para tocar. Tu propia máquina es un Mac, una estación de trabajo Linux o un portátil corporativo bloqueado sin ninguna máquina virtual Windows a la vista. El Visor de eventos no va a venir a ayudarte.

La buena noticia es que un archivo .evtx es un formato binario documentado y autónomo. Todo lo que el Visor de eventos te muestra sobre un registro — con una excepción importante que se trata más abajo — está dentro del archivo, y un analizador adecuado puede leerlo en cualquier sitio. El visor EVTX de este sitio ejecuta ese analizador (la crate evtx de Rust, compilada a WebAssembly) en tu pestaña del navegador, porque los registros de eventos nombran usuarios, máquinas y direcciones IP y no deberían subirse a un sitio convertidor cualquiera, igual que tampoco debería subirse una captura de paquetes. Lo que sigue es el método de trabajo, no el manual de la herramienta: qué mirar, en qué orden, y qué te dirán los campos y qué no.

Qué hay realmente dentro de un archivo .evtx

Un archivo .evtx es una cabecera de 4096 bytes seguida de una secuencia de fragmentos de 64 KB. Cada fragmento contiene una serie de registros de eventos, y cada registro se almacena como XML binario (BinXML): un bloque System que rellena el sistema operativo, más la carga propia del proveedor como EventData o UserData. Abre un registro y encontrarás campos, no prosa — EventID 4625, una marca de tiempo, un canal y valores con nombre como IpAddress, TargetUserName y LogonType. Esos campos son la prueba. También son todo lo que un analizador en una máquina ajena puede darte con honestidad.

He aquí la excepción, y condiciona todo lo demás en esta guía: la frase que muestra el Visor de eventos — «Una cuenta no pudo iniciar sesión» — no está en el archivo. Windows la genera en el momento de verla a partir de las DLL de mensajes que pertenecen a cada proveedor y viven en la máquina que escribió el registro. Por eso los valores de datos a veces parecen %%14592: son referencias a una tabla de mensajes que el archivo no transporta. Un visor en otra máquina puede mostrarte cada campo que el evento registró, y su XML en bruto tal como está almacenado — pero una herramienta que presenta un texto de mensaje pulido para el .evtx de otra persona lo está reconstruyendo desde sus propias copias de las DLL o lo está adivinando. Primero los campos, la prosa al final: ese es el orden honesto.

Un dato estructural más que conviene conocer antes de citar cifras: los fragmentos del archivo son independientes. Un registro extraído de una imagen de disco, o copiado de una unidad moribunda, suele tener fragmentos individuales que ya no se pueden analizar. Un buen lector señala cada fragmento dañado con su desplazamiento en bytes y lee todo lo que lo rodea. El silencio en este punto — una herramienta que devuelve un registro más corto y no dice nada — es como los registros desaparecen en silencio de una investigación.

Empieza por el bloque System

El bloque System de cada registro lleva el mismo esqueleto: Provider (qué componente lo escribió), EventID (qué pasó, en la numeración de ese proveedor), Level (de 1 Crítico a 5 Detallado, con 0 para los eventos que no llevan nivel), Channel (Security, System, Application y los cientos de registros operativos bajo Microsoft-Windows-*), Computer, una marca de tiempo en UTC y el EventRecordID. El triaje empieza ordenando un registro entero según ese esqueleto: cuántos registros, en qué intervalo de tiempo, de qué canales, dominados por qué ID de evento. Un registro de Seguridad que es en un 80 % un único ID de evento suele ser una historia sobre esa única cosa — un cortafuegos decidiendo, un servicio autenticándose en bucle — y el resumen te lo dice antes de que leas un solo registro.

Cita el EventRecordID del bloque System cuando hagas referencia a un registro. Los archivos extraídos, seleccionados o reexportados pueden tener sus cabeceras de registro renumeradas por la herramienta que los produjo, mientras que el bloque System conserva el ID que la máquina asignó originalmente — la diferencia entre «registro 7 de este extracto» y «EventRecordID 319457858 en el registro original» importa en el momento en que alguien intenta reproducir tu hallazgo. Las marcas de tiempo merecen el mismo cuidado: dentro del archivo están en UTC, siempre. El Visor de eventos las convierte a la hora local de la máquina que abra el registro, y por eso dos capturas de pantalla del mismo registro pueden diferir en horas. Elige UTC para el informe y dilo.

Cuatro ID de evento que se ganan su sitio

1102 — el registro de auditoría se borró. El registro de Seguridad registra su propio borrado, como primer evento del nuevo registro. Sus campos nombran al usuario que lo borró. En un incidente, un 1102 es a la vez una prueba y una frontera: todo lo anterior en ese registro ha desaparecido del archivo que tienes, y el propio borrado es un hecho que merece una línea en el informe. Si el registro más antiguo de un archivo es un 1102 con una marca de tiempo dentro de tu ventana de interés, dilo antes de que nadie construya una teoría sobre la ausencia de eventos anteriores.

4624 y 4625 — inicios de sesión, correctos y fallidos. Son los caballos de batalla de las investigaciones de cuentas. Los campos que importan son TargetUserName, IpAddress y, sobre todo, LogonType: 3 es un inicio de sesión de red, 10 es Escritorio remoto, 2 es un inicio de sesión interactivo en consola y 7 es un desbloqueo. Un patrón de fuerza bruta se lee como una ráfaga de 4625 contra una cuenta desde una dirección, seguida — el momento que importa — de un 4624. Un único 4625 es una errata; la señal es la forma de la secuencia, y por eso se filtra y se cuenta en lugar de desplazarse.

4688 — se creó un proceso. Cuando la directiva de auditoría lo registra, cada 4688 nombra el nuevo proceso (NewProcessName), la cuenta que lo lanzó y a menudo el proceso padre — la materia prima de «qué se ejecutó en esta máquina, y cuándo». Dos cautelas te mantienen honesto: 4688 solo existe si «Auditoría de creación de procesos» estaba habilitada en la máquina de origen (su ausencia no prueba nada sobre lo que se ejecutó), y la captura de la línea de comandos es un ajuste distinto otra vez. Trata una pista rica de 4688 como un regalo, no como un derecho.

Estos cuatro son un conjunto de partida, no un temario — el hermano de inicio de sesión especial de 4624, el 4672, el inicio de sesión con credenciales explícitas 4648 y la instalación de servicios 7045 en el registro System son las paradas siguientes habituales. Pero una parte notable de las preguntas del primer día — ¿se borró el registro?, ¿quién entró?, ¿desde dónde?, ¿y qué ejecutó? — se responde solo con 1102, 4624, 4625 y 4688.

Qué no pueden decirte los campos

La disciplina sobre la ausencia es la mayor parte del trabajo con registros. El archivo no puede mostrarte eventos que la máquina de origen nunca registró: la directiva de auditoría decide qué existe, y una máquina con la configuración por defecto registra mucho menos de lo que un investigador espera. No puede mostrarte el texto de los mensajes, como se ha visto arriba — una referencia %% es un puntero a una cadena en una máquina que no tienes. No puede, por sí solo, probar una manipulación ni su ausencia: los huecos en los ID de registro aparecen tanto en archivos extraídos honestamente como en registros borrados, y por eso la señal en la que apoyarse es el registro 1102 explícito, y no un hueco.

Y un registro es un solo testigo. Las marcas de tiempo proceden del reloj de la máquina de origen, que pudo estar equivocado; las cuentas aparecen con los nombres que la máquina conocía; la IP de un inicio de sesión de red es la dirección que la máquina vio, con NAT y VPN incluidas. Los campos son exactamente lo que la máquina registró — ni menos, y la disciplina consiste en recordar que tampoco más.

Una rutina de triaje de cinco minutos

Primer minuto: abre el archivo en el visor EVTX y lee el resumen antes que ningún registro — total, intervalo de tiempo, canales y los ID de evento más frecuentes. Anota cualquier fragmento que el visor señale como ilegible, con sus desplazamientos; esa cautela pertenece a tus notas desde el principio, no como una nota al pie después.

Segundo minuto: busca el 1102. Si el registro se borró, todo tu enfoque cambia, y la hora del borrado y la cuenta son tus primeros hechos sólidos. Tercer minuto: filtra los 4625 y observa la forma — recuento por cuenta, por dirección de origen. Una ráfaga seguida de un 4624 para la misma cuenta desde la misma dirección es el hallazgo; anota las marcas de tiempo exactas. Cuarto minuto: con la ventana sospechosa fijada, filtra los 4688 (y los 4624 de tipo 10, si el acceso remoto está en cuestión) dentro de esa ventana y enumera qué se ejecutó y quién inició sesión. Quinto minuto: exporta los registros filtrados como JSON o CSV y escribe el párrafo mientras tienes las cifras delante — ID de registro, horas en UTC, cuenta, direcciones. La exportación es tu documento de trabajo; el párrafo, con la cautela sobre los fragmentos ilegibles y el límite del texto de los mensajes, es el entregable.

Esa rutina no cierra una investigación. Convierte un archivo binario ajeno en cinco hechos citados y una siguiente pregunta defendible, en la máquina que sea que tengas delante — que es la mayor parte de lo que el triaje ha sido siempre.

Preguntas frecuentes