Logs de eventos de Windows:

los Event ID que un analista debe conocer de memoria

Serie Blue Team  |  unfantasmaenelsistema.com

Antes de instalar Sysmon, antes de montar un SIEM y antes de pagar por un EDR, todo equipo Windows ya está escribiendo un diario de lo que ocurre dentro de él. El registro de eventos de Windows lleva décadas ahí, viene activado de serie y no cuesta nada. El problema no es que falte información: es que hay demasiada, mal repartida entre canales, con nombres crípticos y con la mitad de lo interesante apagado por defecto.

Este artículo es un mapa práctico de ese registro nativo: qué canales existen, qué auditoría hay que encender para que aparezcan los eventos que importan, y un catálogo comentado de los Event ID que un analista de SOC acaba reconociendo de memoria. Es el complemento natural del artículo de Sysmon —que añade telemetría por encima— y el paso previo a centralizarlo todo en Wazuh u otro SIEM.

1. Cómo se organiza el registro de eventos

El registro de eventos de Windows no es un fichero único, sino un conjunto de canales independientes. Los clásicos —los que existen desde Windows NT— son tres: Security (auditoría de seguridad: inicios de sesión, uso de privilegios, acceso a objetos), System (arranque, servicios, controladores, hardware) y Application (lo que registran los programas). A partir de Windows Vista se añadieron cientos de canales operativos específicos bajo Registros de aplicaciones y servicios > Microsoft > Windows.

El canal Security es especial: solo la Autoridad de seguridad local (LSA) puede escribir en él, cada entrada lleva un identificador de tarea de auditoría y su tamaño y retención suelen estar infradimensionados de fábrica. En un servidor ocupado, un canal Security de 20 MB puede rotar en minutos y borrar la evidencia antes de que nadie la mire.

2. Habilitar la auditoría: sin esto, el catálogo no aparece

La instalación por defecto de Windows audita muy poco. Para que los Event ID interesantes empiecen a generarse hay que activar la directiva de auditoría avanzada (Advanced Audit Policy Configuration), disponible por GPO en Configuración del equipo > Directivas > Configuración de Windows > Configuración de seguridad > Configuración de directiva de auditoría avanzada. Es preferible a la directiva de auditoría básica y no conviene mezclarlas.

2.1 Dos ajustes que casi todo el mundo olvida

El Event ID 4688 (creación de proceso) por sí solo dice qué se ejecutó, pero no con qué argumentos. La línea de comandos es donde vive la mitad de la actividad maliciosa (parámetros de PowerShell codificados, rutas de scripts, IP de destino). Hay que activarla aparte:

REM GPO: Config. del equipo > Plantillas administrativas > Sistema >
REM   Auditar creacion de procesos > Incluir linea de comandos en...
REM Equivale a esta clave:
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit" ^
    /v ProcessCreationIncludeCmdLine_Enabled /t REG_DWORD /d 1 /f
 
REM PowerShell Script Block Logging (genera Event ID 4104):
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" ^
    /v EnableScriptBlockLogging /t REG_DWORD /d 1 /f

3. El catálogo: Event ID que hay que conocer de memoria

3.1 Autenticación y sesiones

3.2 Logon Type: el número que lo cambia todo

En el 4624 y el 4625, el Logon Type indica cómo se autenticó la sesión. Interpretar mal este campo es el error más común al empezar. Los valores que aparecen a diario:

3.3 Gestión de cuentas y grupos

3.4 Kerberos (en los controladores de dominio)

El detalle de estos eventos y su detección se desarrolla en el artículo dedicado a Kerberoasting y AS-REP roasting. Aquí basta con saber que el 4769 con cifrado RC4 es la firma que se vigila.

3.5 Persistencia, ejecución y recursos compartidos

3.6 Antiforense: cuando alguien borra el rastro

4. Ruido, prioridad y cómo no ahogarse

Un controlador de dominio genera millones de 4624/4634/4769 al día que son puro funcionamiento normal. Intentar mirarlos todos es imposible y contraproducente. La estrategia que funciona:

• Filtra por identidad y por contexto, no por Event ID a secas. Un 4624 Type 3 no dice nada; un 4624 Type 10 de una cuenta de Domain Admin a las 3 de la madrugada, sí
• Listas de lo raro, no listas de lo malo. Define qué cuentas usan RDP, desde qué hosts salta la administración, qué procesos padre son normales; alerta sobre lo que se sale de ahí
• Correlación temporal. 4625 x50 seguido de un 4624 correcto desde la misma IP = fuerza bruta con éxito. Los eventos sueltos engañan; las secuencias no
• Cuentas de equipo y de servicio son el punto ciego. Se ignoran por ruidosas y es justo donde se esconde el movimiento lateral: trátalas como identidades de primera
• Prioriza retención larga para 4624/4625, 4688, 4720-4756, 4768/4769, 7045, 4104 y 1102; el resto puede caducar antes

5. Consultar el log desde la línea de comandos

El Visor de eventos vale para mirar un equipo puntual. Para cazar en serio se usan wevtutil (nativo, rápido, ideal para scripts y equipos remotos) y Get-WinEvent de PowerShell (más potente para filtrar y dar formato). La clave del rendimiento en Get-WinEvent es -FilterHashtable: filtra en el motor del log, no en memoria después.

REM --- wevtutil ---
REM Ultimos 20 logon fallidos, formato texto
wevtutil qe Security /q:"*[System[(EventID=4625)]]" /c:20 /rd:true /f:text
 
REM Exportar el canal Security de un equipo remoto a un .evtx
wevtutil epl Security C:\ir\dc01-security.evtx /r:DC01
 
REM Ver tamano y configuracion de retencion de un canal
wevtutil gl Security

# --- PowerShell / Get-WinEvent ---
# Logon interactivos y RDP (Type 2 y 10) de las ultimas 24 h
$f = @{ LogName='Security'; Id=4624; StartTime=(Get-Date).AddDays(-1) }
Get-WinEvent -FilterHashtable $f |
  Where-Object { $_.Properties[8].Value -in 2,10 } |
  Select-Object TimeCreated,
    @{n='User'; e={$_.Properties[5].Value}},
    @{n='LogonType'; e={$_.Properties[8].Value}},
    @{n='Source'; e={$_.Properties[18].Value}}
 
# Caza: creacion de servicios (7045) en toda una lista de equipos
$f = @{ LogName='System'; Id=7045; StartTime=(Get-Date).AddDays(-7) }
Get-WinEvent -FilterHashtable $f -ComputerName (Get-Content .\hosts.txt) |
  Select-Object MachineName, TimeCreated,
    @{n='Service'; e={$_.Properties[0].Value}},
    @{n='ImagePath'; e={$_.Properties[1].Value}}
 
# PowerShell Script Block sospechoso (4104 con nivel Warning)
Get-WinEvent -FilterHashtable @{
  LogName='Microsoft-Windows-PowerShell/Operational'; Id=4104; Level=3 } |
  Select-Object TimeCreated, @{n='Script'; e={$_.Properties[2].Value}}

6. Buenas prácticas

• Despliega la directiva de auditoría avanzada por GPO desde una plantilla contrastada (la baseline de seguridad de Microsoft, o la guía de auditoría de Malware Archaeology) y ajústala a tu entorno
• Activa la línea de comandos en el 4688 y el Script Block Logging de PowerShell el primer día
• Sube el tamaño de los canales Security, PowerShell/Operational, TaskScheduler/Operational y WinRM/Operational antes de que un incidente los haga rotar
• Reenvía todo con WEF a un colector y desde ahí al SIEM; no dependas de que el .evtx siga en el equipo
• Documenta tu línea base: quién usa RDP, desde dónde, qué relaciones padre-hijo son normales
• Combina el log nativo con Sysmon: el nativo te da identidad y política; Sysmon te da hashes, red por proceso e inyección. Se complementan
• Prueba tus reglas con emulación de adversario (Atomic Red Team) en un laboratorio aislado

Conclusión

El registro de eventos de Windows es la fuente de detección más barata que existe: ya está instalada y solo hay que encenderla bien. Con la auditoría avanzada configurada, la línea de comandos en el 4688 y el Script Block Logging de PowerShell, un equipo pasa de contar poco a contar casi todo lo que un analista necesita para reconstruir un incidente.

El trabajo no es memorizar cientos de números, sino un puñado: los logon y sus Type, la gestión de cuentas y grupos privilegiados, Kerberos en el DC, la instalación de servicios y tareas, y el borrado del propio log. Con ese catálogo en la cabeza, wevtutil y Get-WinEvent en las manos, y todo reenviado por WEF a un sitio seguro, ya tienes el 80% de un SOC funcionando sin gastar un euro en licencias.

unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)