Windows Event Logs para SOC: eventos clave y cómo analizarlos

Una cuenta inicia sesión correctamente en Windows.

¿Es relevante?

Depende.

Si es el usuario habitual accediendo a su portátil corporativo a las nueve de la mañana en día laborable, probablemente no.

Si es una cuenta administrativa que llevaba tres meses sin utilizarse, accede mediante Escritorio Remoto (RDP) a las 03:17 de la madrugada y segundos después aparece un proceso desconocido ejecutando comandos codificados, la misma autenticación cambia completamente de significado.

Windows puede registrar ambos casos con el mismo identificador: Event ID 4624.

Por eso aprender Windows Event Logs no consiste en memorizar mecánicamente que:

4624 = login correcto
4625 = login fallido

Eso sirve para empezar el primer día de clase. Pero un analista SOC necesita dar un paso más:

Principio operativo: El Event ID te dice qué clase de evento ocurrió. Los campos y el contexto te ayudan a entender qué ocurrió realmente.

Vamos a trabajar precisamente sobre esa diferencia.

1. Qué son los Windows Event Logs #

Windows registra una gran cantidad de actividad mediante su sistema unificado de eventos. En una máquina local podemos acceder a ellos gráficamente ejecutando el Visor de eventos:

eventvwr.msc

Al desplegar la sección Windows Logs (Registros de Windows) encontramos los canales clásicos del sistema operativo:

• Security (Seguridad): Contiene eventos generados por las políticas de auditoría del sistema operativo.
• System (Sistema): Registra eventos de los componentes, controladores y servicios del núcleo de Windows.
• Application (Aplicación): Almacena eventos emitidos por aplicaciones instaladas por el usuario o software corporativo.
• Setup (Instalación): Registra eventos de configuración y actualización del sistema operativo.
• Forwarded Events (Eventos reenviados): Recibe eventos transmitidos desde otros equipos mediante Windows Event Forwarding (WEF).

Para un analista de seguridad, el canal Security es especialmente crítico porque concentra los eventos de auditoría. Sin embargo, sería un grave error metodológico pensar que toda la información útil reside allí.

En una investigación real con frecuencia necesitamos consultar registros especializados bajo Applications and Services Logs:

• Microsoft-Windows-PowerShell/Operational (ejecución de scripts, bloques de comandos y módulos de PowerShell).
• Microsoft-Windows-TaskScheduler/Operational (creación, edición y disparo de tareas programadas).
• Microsoft-Windows-Windows Defender/Operational (detecciones, bloqueos y cambios de estado del antivirus).
• Microsoft-Windows-Windows Firewall With Advanced Security/Firewall (reglas y conexiones bloqueadas).
• Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational (conexiones RDP entrantes).

Por eso la pregunta nunca debería ser: «¿qué Event IDs tengo que memorizar?». La pregunta útil es: «¿qué actividad estoy intentando reconstruir y qué registro de Windows puede haberla observado?».

2. Security, System y Application no son lo mismo #

Comprender la función de cada canal evita perder tiempo buscando evidencias donde nunca se generaron:

No existe una regla del tipo: «para investigar seguridad, mira únicamente Security». En una intrusión donde el atacante instala un servicio malicioso para persistencia, el registro System (con el evento 7045 de nuevo servicio creado) aportará la evidencia clave que complementa al registro Security.

3. Antes de memorizar Event IDs: aprende a leer un evento #

Tomemos como ejemplo un inicio de sesión correcto. En el visor de eventos, Windows puede mostrarnos una estructura similar a esta:

Event ID: 4624
Computer: WS-FINANZAS-07.empresa.local
Subject:
    Security ID: S-1-5-18 (SYSTEM)
New Logon:
    Security ID: S-1-5-21-3482...-1042
    Account Name: mlopez
    Account Domain: EMPRESA
    Logon ID: 0x6B7A11
Logon Information:
    Logon Type: 10
Network Information:
    Workstation Name: WS-PORTATIL-03
    Source Network Address: 198.51.100.23
    Source Port: 52140

Un principiante suele detenerse en la primera línea: «4624 = inicio de sesión correcto».

Un analista extrae de inmediato seis preguntas operativas fundamentales:

• ¿Quién? Account Name: mlopez dentro del dominio EMPRESA.
• ¿Dónde? Computer: WS-FINANZAS-07 (el host que recibió la conexión).
• ¿Desde dónde? Source Network Address: 198.51.100.23.
• ¿Cómo? Logon Type: 10 (sesión interactiva remota / RDP).
• ¿Cuándo? Marca de tiempo precisa del evento.
• ¿Qué sesión? Logon ID: 0x6B7A11 (el identificador que enlazará el resto de acciones de esa sesión).

Y a partir de esos datos formula la pregunta contextual: «¿era esperable que el usuario mlopez iniciara una sesión remota RDP sobre un equipo del departamento de finanzas desde esa dirección IP específica?».

El número 4624 fue únicamente el punto de partida.

4. Event ID 4624: inicio de sesión correcto y los Logon Types #

El Event ID 4624 registra una autenticación exitosa en el equipo local o remoto. Es uno de los eventos más comunes en cualquier red corporativa y también uno de los que más falsas asunciones genera.

Una autenticación correcta no significa automáticamente «usuario legítimo». Significa estrictamente que las credenciales o el mecanismo criptográfico presentado fueron aceptados por el sistema. Si un atacante sustrajo credenciales válidas mediante un ataque de phishing, Windows generará un 4624 perfectamente válido.

Logon Type: el campo que cambia por completo la interpretación

Dentro del evento 4624, el campo numérico Logon Type (Tipo de inicio de sesión) describe la naturaleza técnica de la sesión creada:

No necesitas memorizar cada tipo el primer día. Lo que necesitas entender con claridad es que:

4624 + Logon Type 2   vs   4624 + Logon Type 10

describen dos situaciones completamente distintas. Un Logon Type 10 obliga a investigar el origen del tráfico de red y la IP remota; un Logon Type 2 sitúa al usuario frente a la máquina física.

5. Event ID 4625: fallo de inicio de sesión y análisis de causas #

El Event ID 4625 registra un intento fallido de autenticación. Ver un evento 4625 aislado no implica prácticamente nada en un entorno empresarial activo: los usuarios se equivocan al teclear su contraseña, las aplicaciones intentan sincronizar con credenciales desactualizadas o un dispositivo móvil intenta conectarse a la red Wi-Fi tras una rotación de contraseña.

Cuándo empieza a ser relevante un 4625

El interés analítico aparece cuando observamos patrones de frecuencia o secuencias coordinadas:

08:40:11 4625 usuario=administrador IP=198.51.100.54
08:40:13 4625 usuario=administrador IP=198.51.100.54
08:40:15 4625 usuario=administrador IP=198.51.100.54
08:40:17 4625 usuario=administrador IP=198.51.100.54
08:40:19 4625 usuario=administrador IP=198.51.100.54

Cinco fallos en ocho segundos sugieren automatización, pero todavía no confirman una intrusión. La situación cambia de nivel si a continuación aparece:

08:40:23 4624 usuario=administrador IP=198.51.100.54
08:41:02 4688 powershell.exe

Ahora tenemos una correlación temporal de alta criticidad: múltiples fallos seguidos inmediatamente de un acierto desde la misma IP y la ejecución casi instantánea de una consola de comandos.

No todos los fallos significan contraseña incorrecta: Status y Sub Status

Dentro del evento 4625, los campos Status y Sub Status revelan el motivo exacto del rechazo según los códigos de error NTSTATUS de Microsoft:

• 0xC000006A: El nombre de usuario es correcto pero la contraseña es errónea.
• 0xC0000064: El nombre de usuario especificado no existe en el sistema o directorio.
• 0xC000006E: Restricción del tipo de cuenta de usuario (por ejemplo, cuenta deshabilitada).
• 0xC0000234: La cuenta de usuario está bloqueada por haber superado el umbral de intentos fallidos.
• 0xC0000072: La cuenta está actualmente deshabilitada.
• 0xC000006F: El usuario intentó iniciar sesión fuera del horario laboral autorizado.

Decir que «4625 = ataque de fuerza bruta» es una simplificación incorrecta. Un analista revisa los códigos de estado para saber si el atacante desconoce las contraseñas, está enumerando usuarios inexistentes o intentando utilizar cuentas deshabilitadas.

6. Event ID 4648: uso explícito de credenciales #

El Event ID 4648 se emite cuando un proceso o usuario intenta iniciar sesión utilizando credenciales suministradas de forma explícita (a diferencia de reutilizar el token de sesión actual mediante SSO o Kerberos implícito).

Ocurre rutinariamente cuando un administrador utiliza herramientas como runas.exe o cuando un script corporativo especifica un usuario y contraseña para conectarse a un recurso remoto.

En el contexto de una investigación defensiva, el 4648 es valioso para rastrear:

• Movimientos laterales entre servidores del dominio.
• Uso de herramientas de administración remota de terceros.
• Ejecución de utilidades como PsExec o scripts de automatización con cuentas privilegiadas.

El evento por sí solo no demuestra actividad maliciosa. Su valor surge al combinarlo con la cuenta de origen, el equipo de destino, los procesos generados y la actividad subsiguiente.

7. Event ID 4672 y el poder de Logon ID #

El Event ID 4672 se genera cuando a una nueva sesión se le asignan privilegios especiales de seguridad (como SeDebugPrivilege, SeBackupPrivilege, SeLoadDriverPrivilege o SeTcbPrivilege).

El título del evento puede parecer alarmante («Special privileges assigned to new logon»), pero en la práctica Windows genera miles de eventos 4672 legítimos a lo largo del día. Las sesiones iniciadas por la cuenta SYSTEM o por administradores locales al arrancar servicios los producen de forma habitual.

Una regla de detección básica que alerte ante cualquier aparición del 4672 colapsaría al SOC con falsos positivos. Lo analíticamente relevante ocurre cuando observamos que una cuenta que no debería poseer privilegios elevados recibe estas capacidades, o cuando el evento coincide con una autenticación remota imprevista.

Logon ID: el hilo conductor de la investigación

Windows asigna a cada sesión iniciada un identificador hexadecimal único llamado Logon ID (por ejemplo: 0x65A128):

4624  Account Name: admin-backup   Logon ID: 0x65A128   (Autenticación)
4672  Account Name: admin-backup   Logon ID: 0x65A128   (Asignación de privilegios)
4688  New Process: powershell.exe   Logon ID: 0x65A128   (Creación de proceso)

El Logon ID permite conectar inequívocamente múltiples eventos dispersos con la misma sesión de trabajo. En lugar de buscar eventos aislados de forma independiente, el analista reconstruye la secuencia causal completa:

AUTENTICACIÓN ↓ SESIÓN (Logon ID) ↓ PRIVILEGIOS ↓ PROCESOS ↓ ACCIONES

8. Event ID 4688: creación de procesos y línea de comandos #

El Event ID 4688 registra la creación de un nuevo proceso en el sistema cuando la política de auditoría de seguimiento detallado (Detailed Tracking) está habilitada.

Para la ciberseguridad defensiva, este evento es crítico porque los ataques, la administración y la actividad normal del sistema terminan ejecutando procesos ejecutables (binarios .exe, scripts o utilidades nativas LOLBAS).

Si observamos:

New Process Name: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

La presencia de PowerShell no es maliciosa por defecto. Las preguntas correctas que debe plantearse el analista son:

• ¿Quién lo ejecutó? (campo SubjectUserName).
• ¿Qué proceso padre lo inició? (campo CreatorProcessName o ParentProcessName).
• ¿Qué argumentos y parámetros se pasaron en la línea de comandos?
• ¿Qué conexiones de red o archivos generó inmediatamente después?

El proceso padre revela la anomalía

Compara estas dos relaciones de proceso padre e hijo:

# Relación 1: Ejecución normal por parte del usuario en el escritorio
explorer.exe
 └── powershell.exe

# Relación 2: Ejecución sospechosa originada desde un procesador de texto
winword.exe
 └── powershell.exe

La segunda relación es una señal clásica de ejecución de macros maliciosas embebidas en un documento ofimático recibido por correo. Reconstruir árboles de procesos nos permite dejar de mirar nombres de archivos ejecutables aislados y empezar a analizar comportamiento de ejecución.

Línea de comandos en el evento 4688

Por defecto, el evento 4688 registra el ejecutable pero no los argumentos que acompañaron a su ejecución. Mediante Directiva de Grupo (GPO) es posible habilitar la inclusión de la línea de comandos en los eventos de creación de procesos (Include command line in process creation events).

Saber que se ejecutó powershell.exe aporta visibilidad limitada; saber que se ejecutó con:

powershell.exe -ExecutionPolicy Bypass -NoProfile -WindowStyle Hidden -Enc SQBFAFgA...

proporciona de inmediato el payload codificado para su análisis y extracción de indicadores de compromiso (IoCs).

9. Cuentas y grupos: eventos 4720, 4728 y 4732 #

Una vez dentro de un entorno comprometido, los atacantes suelen buscar mecanismos de persistencia creando cuentas locales o agregando usuarios a grupos privilegiados.

Event ID 4720: creación de una cuenta de usuario

Se genera cada vez que se crea un usuario en el sistema local o en Active Directory. No significa automáticamente persistencia maliciosa: los administradores de sistemas crean cuentas legítimas con frecuencia.

La clave radica en el contexto:

10:12:14  4720  Creator: admin-ti    New Account: jperez       (Alta legítima)
03:14:52  4720  Creator: web-service  New Account: backup_admin2 (Anomalía crítica)

Una cuenta creada en plena madrugada por una cuenta de servicio web que gestiona un servidor público exige contención inmediata.

Eventos 4728 y 4732: modificaciones en grupos de seguridad

• Event ID 4728: Se añadió un miembro a un grupo de seguridad global (en entornos de dominio).
• Event ID 4732: Se añadió un miembro a un grupo de seguridad local (por ejemplo, el grupo local Administradores o Usuarios de escritorio remoto).

Analiza la secuencia temporal de persistencia:

03:14:52 → 4720 → Se crea la cuenta local backup_admin2
03:15:07 → 4732 → Se añade backup_admin2 al grupo local Administradores
03:16:11 → 4624 → backup_admin2 inicia sesión interactiva remota (Logon Type 10)
03:16:29 → 4672 → backup_admin2 recibe privilegios especiales

Ningún evento aislado cuenta toda la historia. La secuencia cronológica demuestra la táctica completa.

10. Bloqueos, Kerberos y NTLM: 4740, 4768, 4769 y 4776 #

Event ID 4740: cuenta bloqueada

Registra que una cuenta de usuario ha sido bloqueada tras superar el límite de intentos fallidos configurado en las políticas de seguridad. Puede originarse por un usuario que olvidó su clave, pero también por campañas automatizadas de password spraying.

El campo más valioso del 4740 es Caller Computer Name, que identifica la máquina desde la cual se originaron los intentos que provocaron el bloqueo, permitiendo al analista rastrear el foco del problema en la red.

Eventos Kerberos en controladores de dominio: 4768 y 4769

En Active Directory, la autenticación se gestiona primordialmente mediante el protocolo Kerberos. Dos eventos clave auditados en los Domain Controllers son:

• Event ID 4768: Solicitud de un Ticket Granting Ticket (TGT). Ocurre cuando un usuario se autentica inicialmente ante el Key Distribution Center (KDC).
• Event ID 4769: Solicitud de un Ticket de Servicio (TGS). Ocurre cuando un usuario que ya posee un TGT solicita acceso a un servicio específico de la red (servidor de archivos, SQL, etc.).

No intentes memorizar cada campo técnico de estos eventos sin comprender antes el ciclo de vida de Kerberos: usuario solicita autenticación → KDC emite TGT → usuario presenta TGT para solicitar ticket de servicio → KDC emite TGS para el servicio de destino. Un volumen masivo de eventos 4769 solicitando tickets con cifrado débil RC4 puede ser indicio de un ataque de Kerberoasting.

Event ID 4776: validación de credenciales (NTLM)

Registra que el controlador de dominio o el equipo local intentó validar las credenciales de una cuenta utilizando el protocolo NTLM. En entornos modernos donde Kerberos es el estándar preferido, la aparición de eventos 4776 puede ayudar a detectar sistemas legados desactualizados o intentos de autenticación NTLM forzada.

11. Integridad de logs: 1102 y 4719 #

Cuando un adversario obtiene privilegios de administración en un endpoint, con frecuencia intentará cegar los mecanismos de defensa y eliminar evidencias forenses.

Event ID 1102: se limpió el registro de auditoría Security

El Event ID 1102 se genera cuando se borra deliberadamente el archivo de registro de seguridad de Windows (por ejemplo, ejecutando wevtutil cl Security o mediante PowerShell).

Microsoft recomienda clasificar el evento 1102 como una alerta de alta prioridad en cualquier plataforma de monitorización. En condiciones normales de operación, los administradores de sistemas no borran manualmente el registro Security. Aunque pueda deberse a tareas de mantenimiento o scripts de pruebas mal diseñados, cualquier aparición del 1102 exige una explicación verificable:

• ¿Qué cuenta de usuario ejecutó la limpieza?
• ¿Desde qué sesión interactiva o remota?
• ¿Qué eventos se registraron en los minutos inmediatamente anteriores al borrado?
• ¿Dispone la organización de una copia centralizada en el SIEM que conserve la evidencia que se perdió en el equipo local?

Event ID 4719: cambios en la política de auditoría

El Event ID 4719 se emite cuando se modifica la configuración de las directivas de auditoría del sistema (por ejemplo, deshabilitando la auditoría de inicio de sesión o el seguimiento de procesos). Modificar qué registra Windows es una técnica directa para reducir la visibilidad defensiva. La investigación debe contrastar si el cambio respondió a una actualización legítima de Directivas de Grupo (GPO) o a una acción no autorizada.

12. Tabla de Event IDs de Windows para analistas SOC #

Utiliza esta tabla no como una lista de «eventos buenos o malos», sino como una guía de preguntas analíticas para iniciar tu investigación:

13. Caso práctico: investigación de un incidente en 5 pasos #

Simulemos la respuesta ante una alerta del SIEM: «Múltiples fallos de autenticación seguidos de acceso exitoso contra una cuenta de soporte técnico».

Paso 1. Identificar los intentos fallidos (4625)

En el registro Security encontramos la ráfaga de fallos:

02:14:01 4625 Account: admin-soporte Source IP: 198.51.100.77 Status: 0xC000006A
02:14:03 4625 Account: admin-soporte Source IP: 198.51.100.77 Status: 0xC000006A
02:14:05 4625 Account: admin-soporte Source IP: 198.51.100.77 Status: 0xC000006A
02:14:07 4625 Account: admin-soporte Source IP: 198.51.100.77 Status: 0xC000006A
02:14:09 4625 Account: admin-soporte Source IP: 198.51.100.77 Status: 0xC000006A

Fijamos dos puntos de pivote: la cuenta admin-soporte y la IP 198.51.100.77.

Paso 2. Buscar si la secuencia culminó en éxito (4624)

Cinco segundos después de los fallos encontramos:

02:14:14 4624 Account: admin-soporte Source IP: 198.51.100.77 Logon Type: 10 Logon ID: 0x92B11F

Confirmamos que tras la ráfaga de fallos se estableció una sesión remota RDP (Logon Type 10) desde la misma dirección IP. La hipótesis de compromiso gana fuerza.

Paso 3. Correlacionar el Logon ID

Consultamos todos los eventos que compartan el Logon ID: 0x92B11F:

02:14:14 4672 Account: admin-soporte Logon ID: 0x92B11F Privileges: SeDebugPrivilege, SeSecurityPrivilege

La sesión remota recibió privilegios administrativos elevados en la estación.

Paso 4. Rastrear la creación de procesos (4688)

Examinamos los procesos creados en el host bajo ese mismo contexto de usuario y sesión:

02:15:02 4688 Parent: explorer.exe New Process: powershell.exe Logon ID: 0x92B11F
02:15:26 4688 Parent: powershell.exe New Process: cmd.exe Logon ID: 0x92B11F
02:17:03 4720 Creator: admin-soporte New Account: svc-backup2
02:17:14 4732 Creator: admin-soporte Member: svc-backup2 Target Group: Administrators

Paso 5. Documentar conclusiones con rigor profesional

Un analista poco experimentado redactaría: «Un hacker ruso atacó con fuerza bruta y hackeó el servidor creando persistencia».

Un informe pericial y profesional documenta con precisión técnica la evidencia observada:

Conclusión del analista: Se identificaron cinco eventos 4625 de autenticación fallida contra la cuenta administrativa admin-soporte desde la dirección 198.51.100.77, seguidos cinco segundos después de un inicio de sesión remoto correcto (4624, Logon Type 10) desde la misma IP. La sesión (Logon ID 0x92B11F) obtuvo privilegios especiales (4672) e inició instancias interactivas de PowerShell y cmd.exe. Posteriormente se registró la creación de la cuenta local svc-backup2 (4720) y su incorporación inmediata al grupo local de Administradores (4732). Se requiere validación urgente con el titular de la cuenta admin-soporte sobre la legitimidad del acceso remoto y la contención inmediata del activo.

14. Auditoría avanzada y límites de visibilidad #

Windows no audita absolutamente toda la actividad con el máximo nivel de detalle de manera predeterminada. La visibilidad de los eventos depende de:

• La versión y edición del sistema operativo (Windows 10/11 Pro/Enterprise o Windows Server).
• El rol del sistema (estación de trabajo, servidor miembro o Controlador de Dominio).
• La configuración de Directivas de Auditoría Avanzada (Advanced Audit Policy Configuration) distribuida por GPO.

Las directivas avanzadas de auditoría dividen la telemetría en subcategorías especializadas:

• Account Logon: Auditoría de credenciales en Controladores de Dominio (Kerberos, NTLM).
• Account Management: Creación, borrado y modificación de usuarios y grupos.
• Detailed Tracking: Creación y terminación de procesos.
• Logon/Logoff: Inicios y cierres de sesión locales y de red.
• Policy Change: Modificaciones en directivas de auditoría y reglas de filtrado.
• Privilege Use: Asignación y uso de privilegios sensibles.
• System: Cambios de estado y eventos de seguridad del núcleo.

Axioma forense fundamental: Un evento no observado no demuestra que la acción no haya ocurrido; puede significar que la auditoría no estaba habilitada para registrarla.

Cuando redactes un informe pericial, utiliza fórmulas sobrias como: «No se observaron eventos 4688 durante la ventana temporal analizada», y evita afirmaciones categóricas indemostrables como «No se ejecutaron procesos en el equipo».

15. Herramientas: Event Viewer, PowerShell, SIEM y Sysmon #

Filtrado local con Event Viewer

En el Visor de eventos (eventvwr.msc), navega hasta Windows Logs → Security y utiliza la acción Filter Current Log (Filtrar registro actual). Puedes introducir identificadores separados por comas:

4624,4625,4688

Es una opción rápida para laboratorios o análisis puntuales en una sola máquina.

Consultas analíticas con PowerShell: Get-WinEvent

PowerShell ofrece el cmdlet Get-WinEvent, mucho más rápido y flexible que las interfaces gráficas. Utiliza siempre -FilterHashtable para que el filtrado se ejecute en el propio motor de eventos de Windows antes de devolver los objetos:

# Consultar los últimos 20 inicios de sesión fallidos (4625)
Get-WinEvent -FilterHashtable @{ LogName='Security'; Id=4625 } -MaxEvents 20

# Consultar eventos 4624 y 4625 registrados en las últimas 24 horas
Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    Id = 4624, 4625
    StartTime = (Get-Date).AddDays(-1)
} -MaxEvents 50

# Extraer el usuario y la IP de origen en fallos de autenticación
Get-WinEvent -FilterHashtable @{ LogName='Security'; Id=4625 } -MaxEvents 10 | 
    ForEach-Object {
        $xml = [xml]$_.ToXml()
        [PSCustomObject]@{
            TimeCreated = $_.TimeCreated
            TargetUser  = ($xml.Event.EventData.Data | Where-Object { $_.Name -eq 'TargetUserName' }).'#text'
            IpAddress   = ($xml.Event.EventData.Data | Where-Object { $_.Name -eq 'IpAddress' }).'#text'
            Status      = ($xml.Event.EventData.Data | Where-Object { $_.Name -eq 'Status' }).'#text'
        }
    }

Event Viewer no sustituye a un SIEM

El Visor de eventos local es óptimo para aprender, pero una operación SOC necesita correlacionar telemetría entre miles de endpoints, servidores y cortafuegos. Una plataforma SIEM permite ingestar estos eventos mediante agentes (como Winlogbeat o el agente de Azure Monitor), normalizarlos y cruzarlos en segundos. Para comprender cómo se orquestan estas alertas con automatizaciones, consulta nuestra guía sobre SIEM vs SOAR.

Windows Event Logs vs. Sysmon: aclaración conceptual

Los Windows Event Logs son la arquitectura nativa de eventos incluida en el propio sistema operativo Windows. Por su parte, nuestra guía sobre Sysmon (System Monitor) profundiza en esta utilidad complementaria de Microsoft Sysinternals que se instala adicionalmente como controlador del sistema para generar eventos más detallados (hashes criptográficos de ejecutables en memoria, consultas DNS por proceso y conexiones de red salientes vinculadas a ejecutables). Sysmon enriquece la visibilidad, pero no reemplaza a los eventos de seguridad nativos de Windows.

16. Itinerario junior y 5 laboratorios prácticos #

Para progresar de forma ordenada en tus competencias sobre qué necesita saber un analista SOC, aborda el estudio de los eventos en cinco etapas:

1. Etapa 1: Autenticación. Domina 4624, 4625, 4648, 4740 y los Logon Types (2, 3, 10).
2. Etapa 2: Privilegios y cuentas. Comprende 4672, 4720, 4728 y 4732.
3. Etapa 3: Ejecución y procesos. Estudia 4688, árboles padre-hijo y línea de comandos.
4. Etapa 4: Servicios de directorio. Analiza Kerberos (4768, 4769) y validación NTLM (4776).
5. Etapa 5: Integridad de telemetría. Monitoriza la limpieza de registros (1102) y cambios de directiva (4719).

5 Laboratorios guiados para realizar en tu propio equipo

17. Preguntas frecuentes sobre Windows Event Logs (FAQs) #

¿Qué Event IDs de Windows debería aprender primero para trabajar en SOC? #

Para comenzar, es prioritario comprender a fondo 4624, 4625, 4648, 4672, 4688, 4720, 4740, 4768, 4769, 4776, 1102 y 4719 antes que memorizar listas de cientos de identificadores sin contexto funcional.

¿El Event ID 4624 confirma que una conexión es legítima? #

No. Indica exclusivamente que las credenciales presentadas fueron técnicamente aceptadas por el sistema. Si un atacante utiliza credenciales robadas, se registrará un 4624. La legitimidad se evalúa analizando el usuario, origen, horario y Logon Type.

¿Por qué es tan importante el campo Logon Type? #

Porque distingue la vía técnica de acceso. Un Logon Type 2 refleja presencia física ante el equipo, un tipo 3 describe acceso a recursos de red como SMB, y un tipo 10 confirma una sesión remota interactiva como RDP.

¿En qué se diferencian los Windows Event Logs de Sysmon? #

Los Windows Event Logs son el sistema nativo de registro del sistema operativo. Sysmon es un componente adicional de Microsoft Sysinternals que se instala para aportar telemetría granular de host (hashes SHA256 de procesos, consultas DNS y conexiones de red por binario).

Si no veo el evento 4688, ¿significa que no se ejecutó ningún proceso? #

No. Puede significar simplemente que la política de auditoría de creación de procesos no está habilitada en ese equipo. La ausencia de un evento en el log nunca equivale a la ausencia del hecho real.

¿Para qué sirve el campo Logon ID en una investigación? #

Es un identificador de sesión único que vincula la autenticación inicial (4624), la asignación de privilegios (4672) y los procesos creados (4688) durante esa misma sesión de trabajo.

¿Por qué es tan crítico monitorizar el Event ID 1102? #

Porque indica que alguien vació manualmente el registro Security del equipo. En un entorno corporativo esto es sumamente anómalo y constituye un fuerte indicio de evasión de defensas o manipulación de evidencias.

Conclusión: el verdadero objetivo no es recordar números #

Con la práctica y el tiempo reconocerás de inmediato identificadores como 4624, 4625 o 4688 con la misma naturalidad con la que un administrador de redes reconoce los puertos 80, 443 o 22. Sin embargo, recordar el número no es la meta.

El verdadero objetivo es que al observar un evento 4624 te preguntes automáticamente: «¿Qué usuario? ¿Qué origen? ¿Qué Logon Type? ¿Qué Logon ID? ¿Qué actividad vino después?». Y al observar un evento 4688 te preguntes: «¿Qué proceso? ¿Cuál es su proceso padre? ¿Qué línea de comandos utilizó? ¿Qué conexiones generó?».

Windows Event Logs encaja dentro de una cadena analítica indispensable para las operaciones del Blue Team. Antes de intentar diseñar reglas analíticas complejas en un SIEM, consolida tu comprensión de la telemetría base consultando nuestra guía sobre qué son los logs de seguridad y cómo analizarlos o revisa la ruta de cómo convertirse en analista SOC para enfocar tu preparación.

Fuentes oficiales y documentación técnica revisada #

• Microsoft Learn: Event 4624: An account was successfully logged on (Especificación técnica de campos y Logon Types).
• Microsoft Learn: Event 4625: An account failed to log on (Códigos de error NTSTATUS y motivos de fallo).
• Microsoft Learn: Event 4672: Special privileges assigned to new logon (Asignación de privilegios de usuario).
• Microsoft Learn: Event 4688: A new process has been created (Auditoría de procesos y registro de línea de comandos).
• Microsoft Learn: Event 1102: The audit log was cleared (Auditoría de integridad de registros de seguridad).
• Microsoft Learn: Advanced Security Audit Policy Settings (Configuración de directivas avanzadas de auditoría).
• Microsoft Sysinternals: System Monitor (Sysmon) Documentation.

Última revisión técnica: 07 de octubre de 2026.

---