Windows Event Logs: Los 20 Event IDs que Todo Analista Debe Monitorizar

Llevo más de una década metido en trincheras de SOCs y salas de guerra, y si hay algo que me saca de quicio es ver paneles de SIEM llenos de alertas genéricas de "Failed Logon" mientras los atacantes se pasean por el dominio como Pedro por su casa. En 2026, con la sofisticación de los ataques living-off-the-land y la explosión de herramientas como Cobalt Strike 5.0 o Sliver, monitorizar los logs de Windows sin criterio es como buscar una aguja en un pajar... sin saber qué es una aguja. La clave no está en recopilarlo todo, sino en entender la narrativa del ataque y buscar los event IDs que realmente marcan la diferencia entre un ruido molesto y una brecha catastrófica. En mi experiencia, el 80% del valor de detección en un entorno Windows reside en menos de 20 eventos, si sabes interpretarlos en contexto.

Vamos al lío. Olvida las listas genéricas de 2018 que aún circulan por ahí. Hoy te voy a hablar de los eventos que, en las auditorías y pentests que hacemos en Riskitera, vemos que los atacantes intentan borrar o enmascarar primero. Y te lo voy a contar con la crudeza con la que se lo explico a un CISO de un banco español: si no estás correlacionando estos eventos, tu SOC está ciego en un lado del campo.

¿Por qué los Event IDs clásicos ya no son suficientes en 2026?

La realidad es que los atacantes conocen el playbook del defensor mejor que nosotros mismos. Todo el mundo monitoriza el evento 4625 (logon fallido) para detectar brute force, pero ¿cuántos tienen reglas de correlación avanzada para el evento 4648 (logon con credenciales explícitas) que se genera cuando un atacante usa runas /netonly o herramientas como Mimikatz para movimiento lateral? Este último es, en mi opinión, diez veces más valioso. El panorama ha evolucionado: la detección basada en firmas está muerta, y la caza de amenazas (threat hunting) proactiva se basa en anomalías de comportamiento. Para ello, necesitas una base sólida de eventos de alta fidelidad.

En un pentest reciente para una aseguradora, el equipo rojo (nosotros) comprometió el dominio en menos de 48 horas sin disparar una sola alerta crítica en su SIEM. ¿Cómo? Usando técnicas de abuso de delegación Kerberos (ataque Kerberoasting) y movimiento lateral vía WMI, eventos que su stack de seguridad no estaba normalizando ni correlacionando. Su regla estrella era "10 intentos de logon fallidos en 5 minutos", mientras nosotros usábamos tickets TGT válidos robados. Fue un ejemplo de libro de la desconexión entre lo que se monitoriza y lo que realmente importa.

Los 5 Pilares de la Monitorización Efectiva en Windows: Una Visión 2026

Para estructurar esto, no voy a darte una simple lista. Voy a agrupar los eventos en los cinco pilares narrativos de un ataque moderno, tal y como los documentamos en nuestros informes de threat hunting.

1. Persistencia y Ejecución Inicial: Más Allá del Malware

Aquí es donde los EDR (Endpoint Detection and Response) suelen brillar, pero un SIEM bien afinado puede detectar bypasses. Olvídate solo de las entradas en Run o Services. Los atacantes avanzados usan métodos más sigilosos.

Evento 4697: Creación de un Servicio (Security Log) Este es un clásico, pero su potencia está en el contexto. Un servicio creado por SYSTEM es normal; uno creado por un usuario del dominio desde una estación de trabajo, no tanto. La clave está en correlacionar el Subject User Name con el New Service Name y el binario path. En 2026, vemos mucho abuso de servicios con paths que apuntan a cmd.exe /c o powershell.exe -enc para ejecutar payloads codificados.

<!-- Ejemplo de filtro Sigma para detectar creación de servicio sospechosa -->
title: Suspicious Service Creation
logsource:
    product: windows
    service: security
detection:
    selection:
        EventID: 4697
        ServiceName: 
            - '*update*'
            - '*config*'
            - '*temp*'
        ServiceFileName|contains|all:
            - 'cmd.exe'
            - 'powershell.exe'
    condition: selection
falsepositives:
    - Actividad legítima de administración, pero rara desde estaciones de trabajo de usuario.
level: high

Evento 4688: Creación de Proceso (Security Log con Auditing Habilitado) El Santo Grial, pero solo si tienes habilitado el Audit Process Creation en la Política de Grupo. Sin esto, estás ciego. No se trata de alertar por cada PowerShell, sino de buscar progenitores anómalos. ¿Por qué winword.exe está generando cmd.exe? ¿Por qué svchost.exe genera rundll32.exe? Las reglas de Sigma basadas en la matriz MITRE ATT&CK son tu mejor aliado aquí.

Evento 4104: Script Block Logging (Microsoft-Windows-PowerShell/Operational) Si no tienes esto habilitado, cierra el SOC y vete a casa. En serio. El PowerShell Remoting es la arteria principal del movimiento lateral. Este evento captura el contenido de los bloques de script que se ejecutan, permitiéndote ver comandos ofuscados. Un atacante usará -EncodedCommand; este evento lo decodifica automáticamente en el campo ScriptBlockText. En un caso de ransomware del año pasado, la detección temprana vino de un 4104 que mostraba un script desofuscado intentando deshabilitar el Volume Shadow Copy Service (vssadmin).

2. Movimiento Lateral y Escalada de Privilegios: El Corazón del Ataque

Este es el territorio del cazador. Los atacantes deben moverse, y aquí dejan huellas si sabes dónde mirar.

Evento 4648: Inicio de Sesión con Credenciales Explícitas (Security Log) Ya lo he mencionado, pero insisto: es el evento más infravalorado. Se genera cuando un proceso (como runas, cmdkey, o Mimikatz con sekurlsa::pth) inicia sesión usando credenciales almacenadas o introducidas. Es la firma del Pass-the-Hash o Overpass-the-Hash. Si ves a un usuario iniciando sesión en múltiples sistemas en minutos con este evento, es game over. Correlaciónalo con el Evento 4624 (Logon exitoso) de tipo 3 (Network) para reconstruir la cadena de movimiento.

Evento 4769: Se solicitó un TGS de Servicio Kerberos (Security Log) El Kerberoasting sigue siendo masivamente efectivo en entornos con cuentas de servicio con SPN y contraseñas débiles. Este evento, cuando se solicita un TGS (Ticket Granting Service) con cifrado RC4_HMAC_MD5 (tipo 0x17), es una señal de alarma enorme. A partir de 2024, Microsoft empezó a marcar estos tickets como "sensitive" por defecto, pero aún se ven en auditorías.

# Consulta rápida en Log Analytics (KQL) para buscar Kerberoasting
SecurityEvent
| where EventID == 4769
| where TicketEncryptionType == "0x17"  # RC4_HMAC
| where ServiceName has "@"  # Filtra tickets para cuentas de usuario (SPN)
| project TimeGenerated, Account, ClientAddress, ServiceName, TicketEncryptionType
| order by TimeGenerated desc

Eventos 4672 y 4673: Asignación y Uso de Privilegios Especiales El privilegio SeDebugPrivilege (depurar programas) permite leer memoria de procesos como lsass.exe. El SeBackupPrivilege puede ser usado para exfiltrar datos. Una activación de estos privilegios por parte de un usuario que no es administrador de dominio es una bandera roja gigante. Suele ser paso previo a volcar credenciales.

3. Evasión y Desactivación de Defensas: La Batalla Silenciosa

Los atacantes buenos no corren; desactivan las cámaras primero. Esto genera eventos muy específicos.

Evento 1102: Limpieza del Log de Seguridad (Security Log) Un clásico, pero sigue siendo la firma de un atacante que intenta cubrir sus huellas. En 2026, los atacantes más avanzados usan métodos más sutiles (como borrar entradas específicas vía APIs), pero para el 95% de los casos, este evento es un kill chain detector. Si tu SIEM no lo recibe… mal asunto.

Evento 4690: Intento de Eliminación de Objeto de WMI (Security Log) El namespace root\Subscription de WMI se usa para crear event consumers persistentes. Un atacante puede crear una suscripción para ejecutar código, pero luego intentará borrar la evidencia. Este evento, aunque raro, es de una fidelidad altísima.

Evento 5038 y 5059: Cambios en el Firewall de Windows (Security Log) Con la popularidad de herramientas como Cobalt Strike que abren proxies locales, ver reglas de firewall añadidas para permitir tráfico en puertos altos (e.g., 4444, 50050) desde cualquier origen es una señal clara. El evento 5059 (regla eliminada) también es interesante para ver limpieza.

4. Exfiltración y Comando & Control (C2): El Objetivo Final

Detectar la exfiltración es difícil, pero no imposible, si miras los proxies de la actividad.

Evento 5156: Conexión de Red Permitida por el Firewall de Windows (Security Log) Habilitar este auditoría es pesado, pero crucial. Permite ver qué proceso (ProcessID, Application) se conectó a qué IP y puerto remoto. Busca conexiones desde procesos como lsass.exe, svchost.exe (no relacionado con red) o explorer.exe a direcciones IP externas en puertos 443, 8443, o 53 (DNS tunneling). La correlación con inteligencia de amenazas (feeds de IPs maliciosas) es clave aquí.

Evento 4663: Acceso a un Objeto del Sistema de Archivos (Security Log) Si auditas acceso exitoso a archivos sensibles, puedes detectar data staging. Imagina un proceso como 7z.exe o rar.exe accediendo a miles de archivos en \\fileserver\finanzas\ seguido de acceso de ftp.exe o curl.exe a un servidor externo. Es una regla pesada, pero para servidores de datos críticos, es la única forma.

La Implementación Real: No Es Solo Recoger Logs, Es la Correlación

De nada sirve tener estos eventos si están en silos. Te pongo un ejemplo de detección de phishing con escalada que implementamos para un cliente del sector energético usando Splunk ES 8.2:

1. Fase inicial: Usuario hace clic en enlace en correo (detectado por proxy, log enviado a Splunk).
2. Ejecución: winword.exe crea powershell.exe (Evento 4688) que descarga un script.
3. Persistencia: El script crea una tarea programada (Evento 4698) o un servicio (4697).
4. Descubrimiento: El nuevo servicio ejecuta whoami /all y net group "Domain Admins" (visto en Evento 4104 de PowerShell).
5. Movimiento Lateral: Se detecta un 4648 desde ese host hacia un servidor.
6. Alerta de Correlación: El SOC recibe UNA alerta de alta prioridad que resume los pasos 1 a 5, con el contexto completo. No seis alertas inconexas.

Esa correlación se hace con reglas de detección en el SIEM (ya sea con Splunk Correlation Searches, Elasticsearch Rules, o Sentinel Analytics Rules). El código crudo para una detección básica de movimiento lateral podría ser así en KQL (Azure Sentinel):

// Detección de movimiento lateral rápido usando Logon Explicito
let timeframe = 30m;
SecurityEvent
| where TimeGenerated >= ago(timeframe)
| where EventID == 4648         // Logon con credenciales explícitas
| where SubjectUserName != TargetUserName  // Filtra autoconexiones
| project TimeGenerated, SubjectUserName, SubjectDomainName, TargetUserName, TargetServerName, ProcessName, ClientAddress
| join kind=inner (
    SecurityEvent
    | where TimeGenerated >= ago(timeframe)
    | where EventID == 4624     // Logon exitoso
    | where LogonType == 3      // Network logon
    | project TargetUserName, TargetLogonId, Computer, LogonTime=TimeGenerated
) on TargetUserName
| where (LogonTime - TimeGenerated) between (0s .. 120s)  // Conexión exitosa poco después del 4648
| summarize StartTime=min(TimeGenerated), EndTime=max(LogonTime), 
    TargetComputers=make_set(Computer), 
    Count=dcount(Computer) by SubjectUserName, TargetUserName, ClientAddress
| where Count >= 3  // Se conectó a 3 o más máquinas en la ventana de tiempo
| extend severity = case(Count >= 5, 'High', Count >= 3, 'Medium', 'Low')

Errores Comunes que Veo en Auditorías (y Cómo Solucionarlos)

1. Falta de Auditing en Política de Grupo: El 70% de los clientes que auditamos no tienen habilitado Audit Process Creation o el Script Block Logging. Sin eso, los eventos 4688 y 4104 no existen. Es el paso cero. Usa herramientas como auditpol.exe /get /category:* para verificarlo.
2. Centralización Incompleta: Los logs deben salir de los endpoints sí o sí. Un atacante borra logs locales. Usa agentes (Winlogbeat 8.x, Azure MMA, Splunk UF) que envíen logs en tiempo real a un sistema inmutable.
3. Falta de Normalización: Si tu SIEM ve el evento 4625 de un Windows Server 2012 y uno de un Windows 11 como campos diferentes, estás perdido. Invierte en un buen pipeline de parsing (con herramientas como Logstash o el procesamiento nativo de tu SIEM).
4. Monitorizar sin Contexto: Alertar por cada 4625 (logon fallido) genera fatiga. Mejor alertar por "10 logons fallidos a cuentas que no existen" (cuenta válida vs. inválida) o por "4625 seguido de 4624 exitoso desde misma IP" (posible éxito de brute force).

Recursos y Referencias

• Documentación Oficial de Microsoft sobre Auditing: Microsoft Security Auditing - Imprescindible para entender los eventos y sus campos.
• Repositorio Sigma HQ: Sigma Rules GitHub - El estándar de facto para reglas de detección independientes del SIEM. Tienen cientos de reglas para eventos de Windows listas para adaptar.
• Proyecto MITRE ATT&CK: MITRE ATT&CK Enterprise Matrix - La base para mapear tus eventos con las tácticas y técnicas de los atacantes. Crucial para construir narrativas de detección.
• Libro "The Windows Logging Handbook" de Alex Teixeira y others: No es gratuito, pero es la biblia. Cubre desde lo básico hasta la caza de amenazas avanzada con eventos específicos.

Al final, monitorizar Windows no es una checklist. Es entender la historia que tus sistemas te están contando. En 2026, con la inteligencia artificial empezando a ayudar en la correlación (como en Microsoft Sentinel con Copilot for Security), el analista humano debe elevar su rol: de leer alertas a interpretar narrativas complejas. Estos 20 eventos son el vocabulario esencial de esa historia. Si no los dominas, no podrás escribir el final.