Windows Event Logs forense: IDs clave, Sysmon y correlación de eventos

Cuando un analista de seguridad investiga un incidente en un entorno Windows, su primera parada son los Event Logs. Son el equivalente de auth.log y syslog en Linux, pero con una estructura mucho más rica: cada evento tiene un ID numérico, un canal, campos estructurados y metadatos que permiten correlaciones muy precisas. Saber leerlos es la diferencia entre decir «algo pasó» y poder reconstruir exactamente qué hizo el atacante, cuándo, con qué cuenta y desde dónde.

Es la duodécima lección de la Tanda 8. Aquí vas a aprender qué canales y Event IDs mirar primero, cómo Sysmon amplía la visibilidad que Windows da por defecto, cómo correlacionar eventos para armar un timeline forense y qué herramientas usar para procesar miles de eventos en segundos. Lo practicarás en los laboratorios titancorp, server-vault y the-shadow-brokers de whoami-labs, donde te enfrentas a entornos Windows reales con Active Directory, servicios mal configurados y post-explotación.

Esta lección cubre análisis forense defensivo. Las técnicas que aprendes sirven también para entender qué huellas dejas cuando atacas un entorno Windows, pero el enfoque es defender: detectar, investigar y responder. Practica solo en entornos autorizados.

Qué son los Windows Event Logs#

Windows registra eventos del sistema operativo, de las aplicaciones y de la seguridad en archivos con formato EVTX, almacenados en C:\Windows\System32\winevt\Logs\. Cada archivo corresponde a un canal (Security, System, Application, etc.) y cada evento dentro tiene un Event ID numérico que identifica el tipo de acción registrada.

A diferencia de los logs de texto plano de Linux, los Event Logs son binarios y estructurados. Eso tiene ventajas: puedes filtrar por campo, hacer consultas XPath, exportar en XML. Y tiene una desventaja: no puedes leerlos con grep. Necesitas herramientas específicas, desde el Event Viewer integrado hasta utilidades de línea de comandos como Get-WinEvent o herramientas forenses como Chainsaw y Hayabusa.

El problema real no es que Windows no registre eventos. El problema es que, por defecto, registra demasiado poco. La configuración de auditoría predeterminada omite eventos críticos como la creación de procesos con línea de comandos completa, conexiones de red por proceso o carga de DLLs. Para tener visibilidad forense real necesitas habilitar políticas de auditoría avanzada y, casi siempre, instalar Sysmon.

Canales y proveedores clave#

Windows organiza los eventos en canales. Estos son los que un analista forense revisa primero:

El canal Security es el más importante para investigación forense. Pero por defecto tiene un tamaño máximo de 20 MB, lo que en un servidor activo significa que se sobrescribe en horas. Uno de los primeros pasos de hardening es aumentar ese tamaño a un mínimo de 1 GB y reenviar eventos a un SIEM.

Event IDs imprescindibles#

No necesitas memorizar los miles de Event IDs que existen. Estos son los que aparecen en casi toda investigación forense:

El Event ID 4624 merece atención especial porque incluye el campo Logon Type, que te dice cómo se autenticó el usuario:

Ver un login tipo 10 desde una IP externa a las 3:00 AM con una cuenta de administrador es una señal de alerta inmediata. Ver un tipo 3 masivo desde una sola IP es sospechoso de enumeración o movimiento lateral.

Sysmon: telemetría extendida#

Sysmon (System Monitor) es una herramienta gratuita de Microsoft Sysinternals que añade telemetría que Windows no registra por defecto. Se instala como servicio y driver, y escribe en su propio canal de Event Logs. Para un equipo de blue team, Sysmon es imprescindible.

Los Event IDs de Sysmon más relevantes:

La diferencia entre investigar con y sin Sysmon es brutal. Sin Sysmon, un 4688 de Security te dice «se creó cmd.exe». Con Sysmon Event ID 1, te dice que cmd.exe fue lanzado por powershell.exe, que a su vez fue lanzado por winword.exe (macro maliciosa), con la línea de comandos completa, el hash SHA256 del ejecutable y el directorio de trabajo. Eso es la diferencia entre tener una pista y tener la cadena completa.

La configuración de Sysmon se controla con un archivo XML. Las configuraciones comunitarias más usadas son la de SwiftOnSecurity (sysmon-config) y la de Olaf Hartong (sysmon-modular). Ambas filtran el ruido y se enfocan en eventos relevantes para seguridad.

Correlación de eventos#

El valor real del análisis forense no está en un evento aislado. Está en la cadena. Un login exitoso (4624) seguido de la creación de un proceso sospechoso (Sysmon 1) seguido de una conexión de red saliente (Sysmon 3) seguido de la instalación de un servicio (7045) cuenta una historia completa: acceso inicial, ejecución, C2 y persistencia.

Para correlacionar, necesitas un campo común. En Windows Event Logs, ese campo es el Logon ID (un identificador hexadecimal asignado a cada sesión de login). Todos los eventos generados dentro de esa sesión comparten el mismo Logon ID. Si encontraste un 4624 sospechoso con Logon ID 0x12345, puedes filtrar todos los eventos de Security con ese Logon ID para ver todo lo que esa sesión hizo.

# Buscar todos los eventos de una sesión por Logon ID
Get-WinEvent -FilterHashtable @{LogName='Security'} |
  Where-Object { $_.Properties[7].Value -eq '0x12345' } |
  Sort-Object TimeCreated |
  Format-Table TimeCreated, Id, Message -AutoSize

Otro campo útil para correlación es el Process ID. Sysmon Event ID 1 registra el PID del proceso creado. Ese mismo PID aparece en Sysmon 3 (conexión de red) y en Sysmon 11 (creación de archivo). Así puedes trazar: «este proceso se conectó a esta IP y luego creó este archivo».

Herramientas de análisis#

Event Viewer#

La herramienta integrada de Windows. Interfaz gráfica, filtros por Event ID, por rango de tiempo, por origen. Útil para investigación rápida en un equipo al que tienes acceso. Limitada para análisis masivo.

Get-WinEvent#

El cmdlet de PowerShell para consultar Event Logs. Soporta filtros XPath, hashtable y es scriptable:

# Logins fallidos en las últimas 24 horas
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = (Get-Date).AddDays(-1)
} | Select-Object TimeCreated,
    @{N='IP';E={$_.Properties[19].Value}},
    @{N='User';E={$_.Properties[5].Value}}

# Procesos creados por Sysmon
Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-Sysmon/Operational'
    Id      = 1
} -MaxEvents 50 | Format-List TimeCreated, Message

Chainsaw#

Herramienta open source en Rust que escanea archivos EVTX contra reglas Sigma. Ideal para buscar patrones de ataque conocidos en logs exportados:

# Escanear logs exportados con reglas Sigma
chainsaw hunt C:\logs\evtx_export\ -s sigma_rules/ --mapping mappings/sigma-event-logs-all.yml

Hayabusa#

Similar a Chainsaw pero con reglas propias optimizadas para detección de amenazas. Genera timelines en CSV que puedes abrir en Timeline Explorer:

hayabusa csv-timeline -d C:\logs\evtx_export\ -o timeline.csv

Timeline Explorer#

Herramienta gráfica de Eric Zimmerman para visualizar timelines CSV generados por Hayabusa, MFTECmd o PECmd. Permite filtrar, ordenar y colorear miles de eventos.

EvtxECmd#

Parte del kit de Eric Zimmerman. Convierte EVTX a CSV, JSON o XML para procesamiento masivo:

EvtxECmd.exe -d C:\Windows\System32\winevt\Logs\ --csv C:\output\ --csvf timeline.csv

Explotación y análisis en un laboratorio#

En los laboratorios Windows de whoami-labs puedes practicar la cadena completa. Veamos un escenario típico en el lab titancorp (Active Directory):

Paso 1: conectar al entorno#

# Conexión al lab
ssh usuario@IP_DEL_LAB

Paso 2: enumerar logs disponibles#

# Ver qué canales de Event Log existen y su tamaño
Get-WinEvent -ListLog * | Where-Object RecordCount -GT 0 |
  Sort-Object RecordCount -Descending |
  Select-Object LogName, RecordCount, MaximumSizeInBytes

Paso 3: buscar logins sospechosos#

# Logins exitosos tipo 10 (RDP) o tipo 3 (red)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} |
  Where-Object {
    $_.Properties[8].Value -in @(3, 10)
  } | Select-Object TimeCreated,
      @{N='User';E={$_.Properties[5].Value}},
      @{N='Type';E={$_.Properties[8].Value}},
      @{N='IP';E={$_.Properties[18].Value}} |
  Format-Table -AutoSize

Paso 4: buscar persistencia#

# Servicios nuevos instalados
Get-WinEvent -FilterHashtable @{LogName='System'; Id=7045} |
  Select-Object TimeCreated,
    @{N='Service';E={$_.Properties[0].Value}},
    @{N='Path';E={$_.Properties[1].Value}} |
  Format-Table -AutoSize

# Cuentas creadas
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4720} |
  Select-Object TimeCreated, Message | Format-List

Paso 5: detectar borrado de evidencia#

# Logs borrados (anti-forense)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=1102}

Qué puede lograr un atacante si los logs no están#

En entornos sin Sysmon y con la configuración de auditoría por defecto, un atacante que borra el Security log (Event ID 1102) elimina casi toda la evidencia de su actividad. Paradójicamente, el propio evento 1102 queda registrado en el nuevo log limpio, así que un borrado sigue dejando huella si sabes buscarla.

Cómo configurar la auditoría correctamente#

La auditoría avanzada se configura mediante Group Policy (GPO) en Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration:

Logon/Logoff
  Audit Logon                    → Success, Failure
  Audit Special Logon            → Success
Account Logon
  Audit Credential Validation    → Success, Failure
  Audit Kerberos Auth Service    → Success, Failure
Detailed Tracking
  Audit Process Creation         → Success
  (habilitar "Include command line in process creation events")
Object Access
  Audit File System              → Success, Failure (en carpetas sensibles)
Account Management
  Audit User Account Management  → Success, Failure
  Audit Security Group Management→ Success, Failure
Policy Change
  Audit Audit Policy Change      → Success

Para Sysmon, la instalación es directa:

# Instalar Sysmon con configuración de SwiftOnSecurity
sysmon64.exe -accepteula -i sysmonconfig-export.xml

# Verificar que está corriendo
Get-Service Sysmon64

# Actualizar configuración
sysmon64.exe -c nueva-config.xml

El tamaño de los logs se cambia con:

# Aumentar Security log a 1 GB
wevtutil sl Security /ms:1073741824

# Verificar
wevtutil gl Security

Errores comunes al defenderse#

• Dejar la auditoría por defecto: Windows apenas registra lo mínimo sin configuración explícita.
• No instalar Sysmon: perder visibilidad de procesos, red y archivos es fatal para el forense.
• Guardar logs solo localmente: un atacante con privilegios los borra en segundos.
• No habilitar la línea de comandos en 4688: saber que se ejecutó cmd.exe sin saber qué comando corrió es inútil.
• Configurar Sysmon sin filtros: genera tanto ruido que satura el almacenamiento y entierra las alertas.
• No monitorizar el evento 1102: si alguien borra el Security log y nadie lo nota, la auditoría no existe.
• Olvidar PowerShell ScriptBlock Logging: los atacantes usan PowerShell constantemente y sin este log no queda rastro del script ejecutado.

Preguntas frecuentes#

Sysmon es gratuito pero no viene preinstalado, por qué#

Microsoft lo mantiene como herramienta de Sysinternals, no como componente del sistema operativo. Es gratuito, pero requiere instalación y configuración explícita. En entornos empresariales se despliega por GPO o SCCM.

Puedo analizar logs de una máquina apagada#

Sí. Los archivos EVTX se pueden copiar desde C:\Windows\System32\winevt\Logs\ y analizarlos en otro equipo con Event Viewer, Chainsaw, Hayabusa o EvtxECmd. Es la forma estándar de hacer forense sin alterar la evidencia.

Qué diferencia hay entre Event ID 4688 y Sysmon Event ID 1#

Ambos registran creación de procesos. El 4688 de Security es nativo pero limitado: no incluye hash del ejecutable, no registra el proceso abuelo y la línea de comandos solo aparece si la habilitas por GPO. Sysmon 1 incluye todo eso más el Current Directory, el usuario efectivo y la firma digital del ejecutable.

Cuánto almacenamiento necesitan los logs#

Depende del volumen del servidor. Un servidor Active Directory con Sysmon y auditoría avanzada puede generar varios GB por día. La regla general es retener al menos 30 días localmente y enviar todo a un SIEM para retención a largo plazo.

Qué hago si el atacante borró los logs#

Busca en el SIEM (si hay reenvío). Revisa los archivos EVTX que Windows puede no haber purgado completamente (herramientas de carving como EVTXtract pueden recuperar eventos de espacio no asignado). El evento 1102 en el nuevo log confirma el borrado. También revisa Volume Shadow Copies si existen.

Dónde practico#

En los laboratorios titancorp (Active Directory completo con Kerberoasting y DCSync), server-vault (Windows Server 2019 con IIS) y the-shadow-brokers (explotación SMB y post-explotación Windows) de whoami-labs.

Resumen#

• Los Windows Event Logs son archivos EVTX estructurados con Event IDs numéricos que registran la actividad del sistema.
• Los IDs más críticos: 4624/4625 (login), 4688 (proceso), 7045 (servicio), 1102 (borrado de log), 4720 (cuenta creada).
• Sysmon añade telemetría esencial: procesos con hash y línea de comandos (ID 1), conexiones de red por proceso (ID 3), acceso a memoria (ID 10), consultas DNS (ID 22).
• La correlación se hace por Logon ID o Process ID para reconstruir la cadena completa del ataque.
• Herramientas clave: Get-WinEvent, Chainsaw, Hayabusa, EvtxECmd, Timeline Explorer.
• Sin configuración avanzada y sin Sysmon, Windows registra muy poco: habilitar auditoría y desplegar Sysmon es obligatorio para cualquier entorno que quiera detectar incidentes.

Fuentes y lecturas recomendadas#

• Microsoft: Windows Security Auditing
• Sysmon - Sysinternals
• SwiftOnSecurity sysmon-config
• SANS Windows Event Log Cheat Sheet
• Chainsaw - WithSecureLabs
• Hayabusa - Yamato Security
• MITRE ATT&CK: Data Sources
• SigmaHQ: Detection Rules