Registros de eventos de Windows y los Event IDs que más usan los defensores

#Qué son los registros de eventos de Windows

Windows lleva un registro continuo de lo que pasa en la máquina: servicios que arrancan, programas que fallan, personas que inician sesión. Cada registro es un evento. Todo evento tiene fecha y hora, un proveedor (el componente que lo escribió), un Event ID numérico, un nivel y un conjunto de campos que depende del tipo de evento. Los eventos se agrupan en registros, también llamados canales, y se guardan como archivos .evtx en %SystemRoot%\System32\Winevt\Logs.

Al empezar, tres registros importan más que el resto:

• Application guarda eventos escritos por programas y por algunos componentes de Windows. Una aplicación que se cierra sola o una actualización que falla suele aparecer aquí.
• System guarda eventos del propio Windows y de los drivers: servicios que arrancan y se detienen, el servicio de registro de eventos iniciando en el arranque (Event ID 6005), errores de drivers.
• Security guarda eventos de auditoría: inicios y cierres de sesión, uso de privilegios sensibles, creación de procesos, cambios en cuentas y políticas. Casi todo este artículo trata de él, y es el único de los tres que un usuario común no puede abrir.

Puedes ver esa diferencia de acceso desde PowerShell. En la máquina usada para este artículo (Windows 11, Windows PowerShell 5.1), este comando corrió en una shell sin derechos de administrador:

Get-WinEvent -ListLog System,Application | Format-Table LogName,RecordCount,IsEnabled -Auto

LogName     RecordCount IsEnabled
-------     ----------- ---------
System            36196      True
Application       19965      True

Al agregar Security al mismo comando, salió un error para ese registro: Windows no pudo obtener su información porque la operación no estaba autorizada. Tus conteos de registros serán otros.

#Por qué importa

Muchas detecciones en Windows se construyen sobre el registro Security. Una regla de SIEM para adivinación de contraseñas cuenta eventos 4625. Una regla para una sesión administrativa sospechosa mira 4624 y 4672 juntos. Una regla para manipulación de registros busca 1102. El artículo sobre SIEM del Manual de Campo explicó cómo funcionan esas reglas. Leer los eventos a mano en una máquina te permite comprobar si los supuestos de una regla se cumplen en tus sistemas.

El registro Security solo contiene lo que la política de auditoría le indica a Windows que registre. Si la política no audita los inicios de sesión fallidos, Windows no escribe ningún 4625, y una regla que los cuenta nunca se dispara. Desde el SIEM, eso se ve exactamente igual que una máquina tranquila. Por eso, revisar la política de auditoría va antes de leer el registro.

#Cómo funciona la auditoría

#La política de auditoría decide qué existe

Windows agrupa la configuración de auditoría en categorías, y cada categoría en subcategorías. Cada subcategoría puede registrar éxitos, fallos, ambos o nada. Las categorías son Account Logon, Account Management, Detailed Tracking, DS Access, Logon/Logoff, Object Access, Policy Change, Privilege Use y System.

La categoría Logon/Logoff reúne las subcategorías detrás de la mayoría de los eventos de este artículo: Logon (4624 y 4625), Logoff (4634), Account Lockout (que Microsoft también indica para el 4625) y Special Logon (4672). La creación de procesos, evento 4688, pertenece a la subcategoría Process Creation, dentro de Detailed Tracking.

auditpol es la herramienta integrada para leer la política. auditpol /list muestra los nombres de categorías y subcategorías y funciona en una shell normal. auditpol /get lee la configuración real. La referencia de Microsoft dice que requiere permiso de lectura sobre la política o el derecho "Manage auditing and security log" (SeSecurityPrivilege), y una shell normal, sin elevación, no tiene ninguno de los dos.

auditpol /list /category /v

En la máquina usada para este artículo, con Windows en portugués, ese comando corrió sin elevación y mostró cada categoría con su nombre traducido y un GUID. Logon/Logoff tenía el GUID {69979849-797A-11D9-BED3-505054503030}. El nombre en inglés siguió funcionando ahí con auditpol /list /subcategory:"Logon/Logoff", que listó doce subcategorías. Si tu sistema rechaza un nombre, pasa el GUID.

#Los Event IDs que más vas a usar

#4624 y 4625: inicios de sesión

Los dos eventos se escriben en el equipo donde ocurrió el inicio de sesión. Si alguien escribe una contraseña equivocada en tu laptop, el 4625 queda en el registro Security de tu laptop. Ambos comparten la mayoría de los campos:

• Subject es la cuenta que informó el inicio de sesión, muchas veces el propio equipo o SYSTEM.
• Logon Type dice cómo ocurrió el inicio de sesión. Los valores comunes son 2 (Interactive, en el teclado), 3 (Network, como una carpeta compartida), 4 (Batch), 5 (Service), 7 (Unlock), 10 (RemoteInteractive, Escritorio remoto) y 11 (CachedInteractive, credenciales de dominio guardadas en la máquina).
• New Logon (en el 4624) o Account For Which Logon Failed (en el 4625) es la cuenta que inicia sesión, con su Security ID, nombre y dominio. En el 4624, esa sección también trae el Logon ID de la nueva sesión.
• Failure Information (solo en el 4625) trae un código Status y un Sub Status. La página de Microsoft lista los códigos que conviene vigilar: 0xC000006A para contraseña incorrecta, 0xC0000064 para un nombre de usuario que no existe, 0xC000006D para nombre de usuario o información de autenticación incorrectos, 0xC0000072 para cuenta deshabilitada. La misma página indica 0xC0000234, "Account locked out", como el estado típico cuando la falla viene de una cuenta bloqueada. Varios 0xC0000064 seguidos pueden indicar que alguien está enumerando nombres de usuario.
• Process Information muestra el proceso que intentó el inicio de sesión, y Network Information da el nombre de la estación, la dirección de origen y el puerto de origen. 127.0.0.1 o ::1 significa localhost, y el puerto es 0 en inicios de sesión interactivos.

En Windows 10 y posteriores, el 4624 también trae Elevated Token, que indica si la sesión tiene privilegios de administrador.

#4634: cierre de sesión, y por qué importa el Logon ID

El 4634 dice que una sesión terminó. Solo, dice poco. Su valor está en el Logon ID: el mismo valor hexadecimal aparece en el 4624 que abrió la sesión, en cualquier 4672 de esa sesión, en los 4688 de los procesos que inició y en el 4634 que la cerró. Seguir un Logon ID por el registro reconstruye una sesión de principio a fin. Microsoft aclara que los Logon IDs solo son únicos entre reinicios del mismo equipo, así que siempre combina el ID con un rango de tiempo.

#4672: privilegios especiales

Windows escribe el 4672 cuando un nuevo inicio de sesión recibe alguno de una lista de privilegios sensibles, como SeDebugPrivilege (depurar programas), SeBackupPrivilege (hacer copias de seguridad de archivos y carpetas) o SeTcbPrivilege (actuar como parte del sistema operativo).

Cada inicio de sesión de SYSTEM genera un 4672, así que el registro tiene muchos. Microsoft recomienda mirar los casos en que la cuenta no es LOCAL SYSTEM, NETWORK SERVICE ni LOCAL SERVICE, ni un administrador que esperas que tenga esos privilegios.

#4688: creación de procesos

El 4688 se escribe cada vez que arranca un proceso nuevo, siempre que la subcategoría Process Creation esté auditada. Registra el nombre del proceso nuevo, el nombre del proceso creador (el padre), la cuenta, el Token Elevation Type (si el proceso corrió con un token completo, elevado o limitado) y el nivel de integridad.

También tiene un campo Process Command Line, que viene vacío por defecto. La página de Microsoft dice que solo se llena cuando la configuración de directiva de grupo "Administrative Templates\System\Audit Process Creation\Include command line in process creation events" está habilitada. Sin ella, sabes que powershell.exe arrancó, pero no qué le pidieron hacer.

#1102: se borró el registro

El 1102 significa que alguien borró el registro Security. Lo escribe el proveedor Microsoft-Windows-Eventlog y registra la cuenta que lo hizo. La guía de Microsoft es breve: normalmente no deberías ver este evento, rara vez hay motivo para borrar el registro Security a mano, y cada aparición merece una investigación.

#Qué agrega Sysmon

Sysmon (System Monitor) es una herramienta de Sysinternals publicada por Microsoft. Se instala como servicio y driver, sigue activo entre reinicios y escribe sus propios eventos en Applications and Services Logs/Microsoft/Windows/Sysmon/Operational. Es una descarga aparte, que no viene en la instalación predeterminada de Windows, y Microsoft indica como compatibles Windows 11 y Windows Server 2019 o posterior.

Frente al registro Security integrado, Sysmon da más detalle sobre actividad que de otro modo verías solo en parte:

• El Event ID 1, creación de procesos, incluye la línea de comandos completa, hashes del archivo (SHA1 por defecto, con MD5, SHA256 e IMPHASH disponibles) y un ProcessGuid que sigue siendo único aunque Windows reutilice IDs de proceso.
• El Event ID 3 registra conexiones de red con el proceso detrás de cada una. Viene deshabilitado por defecto.
• Otros IDs cubren creación de archivos (11), consultas DNS (22), cambios en el registro de Windows, named pipes, suscripciones WMI y un proceso que abre otro, como lsass.exe (10).

Un archivo de configuración XML decide qué eventos incluye o excluye Sysmon. Microsoft afirma que Sysmon no analiza los eventos que genera y no intenta ocultarse de los atacantes. La lectura queda a cargo de un SIEM o de un analista.

Instalar Sysmon modifica el sistema, por eso el laboratorio de este artículo no lo hace.

#Práctica: encuentra tu propio inicio de sesión fallido

Vas a crear un inicio de sesión fallido en tu propio equipo, con tu propia cuenta, y lo vas a encontrar de tres maneras. No cambies la política de auditoría durante este laboratorio. Si resulta que la política no registra inicios de sesión fallidos, ese resultado ya es lo que tenías que aprender: anótalo y detente ahí.

#Paso 1: abre un PowerShell elevado

Haz clic derecho en Windows PowerShell o en Terminal y elige Ejecutar como administrador. Comprueba que la shell de verdad está elevada:

([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)

True significa que puedes leer el registro Security. En la máquina usada para este artículo, la shell disponible devolvió False. Los comandos de abajo corrieron ahí de todos modos, y sus fallos se informan tal como se observaron, porque vale la pena conocerlos. Donde iría la salida elevada, este artículo describe los campos que debes buscar, según la documentación de Microsoft.

#Paso 2: revisa la política de auditoría

auditpol /get /category:"Logon/Logoff"

En una shell elevada, esto muestra cada subcategoría con su configuración. Busca la línea Logon. Para este laboratorio tiene que incluir fallos, es decir, éxito y fallo, o solo fallo. Si dice que no hay auditoría, Windows no va a escribir el 4625 y el resto del laboratorio no va a encontrar nada.

Sin elevación, en la máquina usada para este artículo, el comando mostró el error 0x00000522 con un mensaje de que el cliente no tiene el privilegio necesario, y terminó con el código 1314.

#Paso 3: genera el evento

Presiona Win+L para bloquear la pantalla. Escribe una contraseña equivocada una vez y luego inicia sesión con la correcta. Anota la hora.

Usa la contraseña, no el PIN. Si normalmente usas Windows Hello, elige la opción de contraseña en la pantalla de inicio de sesión. Este artículo no probó qué genera un PIN incorrecto.

#Paso 4: encuentra el fallo con Get-WinEvent

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 5 | Format-List TimeCreated, Message

-FilterHashtable aplica el filtro mientras se leen los eventos, lo que la documentación de Microsoft describe como más eficiente que pasar todo a Where-Object. -MaxEvents 5 se queda con las cinco coincidencias más recientes, porque Get-WinEvent devuelve primero las más nuevas.

En una shell elevada, el primer resultado debería tener la hora que anotaste. En su Message, revisa:

• Logon Type. El ejemplo de 4625 de Microsoft es un inicio de sesión interactivo, tipo 2, con el proceso que llama C:\Windows\System32\winlogon.exe.
• Account For Which Logon Failed, que debería ser tu cuenta.
• Status y Sub Status. Para una contraseña incorrecta, busca 0xC000006A en uno de los dos.
• Source Network Address y Source Port. Para un inicio de sesión en tu propio teclado, espera un valor local como 127.0.0.1 y puerto 0, como en el ejemplo de Microsoft.

Sin elevación, este mismo comando te engaña. En la máquina usada para este artículo, no informó un problema de permisos. Mostró el error de que no se encontró ningún evento que coincidiera con los criterios de selección. Un Get-WinEvent -LogName Security -MaxEvents 1 simple, en la misma shell, mostró la causa real: una operación no autorizada. Si ves "no se encontraron eventos" en una shell sin elevación, revisa la elevación antes de concluir que el registro está vacío.

#Paso 5: encuentra el inicio de sesión exitoso

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} -MaxEvents 5 | Select-Object TimeCreated, Id

Deberías ver un 4624 unos segundos después de tu 4625, con otros 4624 alrededor, porque los servicios y el propio sistema inician sesión todo el tiempo. Abre el mensaje completo del más cercano a tu hora y revisa el Logon Type y el nombre de la cuenta. Agregar StartTime=(Get-Date).AddMinutes(-15) a la hashtable limita la búsqueda a los últimos quince minutos.

Una contraseña equivocada seguida de la correcta, en la misma cuenta, en el teclado, con segundos de diferencia, es un error de tipeo. El mismo fallo repetido contra muchas cuentas desde una sola dirección de red apunta a adivinación de contraseñas, y las reglas de detección se escriben para distinguir esos dos casos.

#Paso 6: la misma búsqueda con wevtutil

wevtutil qe Security /c:5 /rd:true /f:text /q:"*[System[(EventID=4625)]]"

wevtutil es la herramienta de línea de comandos más antigua para registros de eventos. qe consulta eventos, /c:5 limita la cantidad, /rd:true lee del más nuevo al más antiguo, /f:text imprime texto en lugar de XML y /q recibe un filtro XPath. Con elevación, obtienes los mismos eventos del paso 4. Quita /f:text para ver el XML crudo, con los nombres de campo que usan las reglas de detección, como TargetUserName, Status y LogonType. En un Windows en otro idioma, el texto del mensaje aparece traducido, pero los nombres de campo en el XML siguen en inglés.

Sin elevación, en la máquina usada para este artículo, informó que no pudo abrir la consulta de eventos porque se denegó el acceso, y terminó con el código 5.

#Paso 7: míralo en el Visor de eventos

Ejecuta eventvwr.msc. Si te lo pide, permite que se ejecute como administrador. Ve a Registros de Windows > Seguridad, elige Filtrar registro actual y escribe 4625 en el campo de Event IDs. Abre el evento. La pestaña General muestra el mismo mensaje que leíste en PowerShell. La pestaña Detalles, en vista XML, muestra los nombres crudos de los campos. Deja este evento abierto: el artículo sobre Sigma compara una regla con él.

#Errores comunes

• Confiar en "no se encontraron eventos" en una shell normal. Como mostró el paso 4, una consulta Get-WinEvent -FilterHashtable sin elevación sobre el registro Security puede informar que no hay coincidencias en lugar de acceso denegado.
• Suponer que un evento existe sin revisar la política. Sin configuración de auditoría, no hay evento. Lo mismo vale para los campos: la línea de comandos del 4688 queda vacía hasta que otra política la active.
• Leer un evento aislado. Un solo 4625 dice poco. Mira el 4624 que le sigue, el Logon ID y el rango de tiempo.
• Borrar el registro después del laboratorio para dejar todo ordenado. Destruyes la evidencia que acabas de crear y generas un 1102 que alguien quizá tenga que investigar.
• Olvidar que los registros rotan. En la máquina usada para este artículo, Get-WinEvent -ListLog Application mostró un tamaño máximo de 20971520 bytes en modo Circular: cuando el registro se llena, los eventos viejos se sobrescriben. Revisa el registro Security de la misma forma, con elevación, antes de contar con los eventos del mes pasado.

#Cómo seguir

• Lee la página de Microsoft de cada evento de este artículo. Todas terminan con recomendaciones de monitoreo de seguridad que ya son casi ideas de detección listas.
• Arma una máquina virtual en un laboratorio casero legal, instala Sysmon ahí con un archivo de configuración, ejecuta algunos comandos y compara el evento 1 de Sysmon con el 4688 del mismo proceso.
• Convierte el evento que encontraste en una detección: el siguiente artículo, cómo escribir tu primera regla Sigma, construye y prueba una regla justo para este 4625.

#Fuentes

• Microsoft Learn, 4625(F) An account failed to log on
• Microsoft Learn, 4624(S) An account was successfully logged on
• Microsoft Learn, 4634(S) An account was logged off
• Microsoft Learn, 4672(S) Special privileges assigned to new logon
• Microsoft Learn, 4688(S) A new process has been created
• Microsoft Learn, 1102(S) The audit log was cleared
• Microsoft Learn, Get-WinEvent
• Microsoft Learn, Sysmon
• Microsoft Learn, auditpol get
• Microsoft Learn, wevtutil