🛡️ Windows Security Log: detectar intentos de inicio de sesión fallidos
Laboratorio CIBERMURO: [LAB-BT-01]
Windows registra gran cantidad de información relacionada con la seguridad del sistema. Entre esos datos se encuentran los intentos de inicio de sesión que no consiguen autenticarse correctamente.
En esta práctica vamos a provocar un fallo de autenticación de forma controlada, localizarlo en el registro de seguridad de Windows 11 e interpretar la información que proporciona el Event ID 4625.
Comprobar que Windows registra un intento fallido de inicio de sesión, localizar la evidencia y entender qué información puede utilizar un analista Blue Team/SOC.
1. ¿Qué es el Event ID 4625?
El evento 4625 se registra cuando se produce un intento de inicio de sesión que no consigue autenticarse.
No significa automáticamente que exista un ataque. Un usuario puede equivocarse al escribir su contraseña y generar exactamente el mismo tipo de evento.
Lo interesante desde el punto de vista de seguridad aparece cuando se estudia el contexto:
- qué cuenta intenta autenticarse;
- cuántas veces ocurre;
- desde qué equipo o dirección IP;
- qué tipo de inicio de sesión se intenta;
- cuál es el motivo del fallo;
- si el comportamiento se repite siguiendo algún patrón.
Un evento aislado constituye una evidencia, pero no demuestra por sí solo que se esté produciendo un ataque.
2. Preparar la práctica
La práctica se realiza sobre un equipo con Windows 11. Vamos a utilizar dos herramientas incluidas en el propio sistema:
- Visor de eventos, para realizar una investigación visual.
- PowerShell, para buscar los mismos eventos mediante comandos.
No necesitamos instalar ningún programa adicional.
3. Generar un fallo de autenticación controlado
Primero necesitamos generar nuestro propio evento para saber exactamente qué estamos buscando.
- Guarda cualquier trabajo que tengas abierto.
- Pulsa
Win + Lpara bloquear Windows. - Selecciona tu cuenta habitual.
- Si utilizas Windows Hello, entra en Opciones de inicio de sesión y selecciona la autenticación mediante contraseña.
- Introduce una contraseña incorrecta una sola vez.
- Después introduce la contraseña correcta y vuelve a entrar en Windows.
No repetimos innecesariamente el fallo. En sistemas donde existe una política de bloqueo, muchos intentos consecutivos pueden bloquear temporalmente la cuenta.
Ya tenemos nuestra primera evidencia: conocemos aproximadamente la hora en la que se produce el intento fallido.
4. Abrir el Visor de eventos
Pulsa:
Win + R
Escribe:
eventvwr.msc
y pulsa Enter.
En el panel izquierdo navega hasta:
Visor de eventos
└── Registros de Windows
└── Seguridad
El registro Seguridad contiene numerosos eventos relacionados con autenticación, cuentas, privilegios y otras acciones auditadas por Windows.
5. Buscar el Event ID 4625
En el panel derecho selecciona:
Filtrar registro actual...
En el campo destinado a los identificadores de evento escribe:
4625
Pulsa Aceptar.
Windows muestra únicamente los intentos de inicio de sesión fallidos registrados.
Busca ahora el evento cuya hora coincida con la prueba que acabas de realizar.
6. Primera evidencia
Abre el evento con doble clic.
Deberías encontrar una cabecera similar a:
Nombre del registro: Security Origen: Microsoft-Windows-Security-Auditing Id. del evento: 4625 Categoría de la tarea: Logon Palabras clave: Audit Failure
Realiza una captura de pantalla en la que se vea:
- el identificador 4625;
- la fecha y hora;
- el origen Microsoft-Windows-Security-Auditing;
- parte de la información del intento fallido.
Esta captura constituye la primera evidencia de la práctica.
7. Interpretar el evento
Un evento 4625 contiene bastante información. No necesitamos memorizar todos sus campos. Nos centramos inicialmente en los que tienen mayor utilidad.
👤 Nombre de cuenta
Indica qué cuenta se intenta utilizar.
Por sí solo no identifica a la persona que realiza el intento: únicamente indica las credenciales que se están intentando utilizar.
🔑 Motivo del error
Windows indica por qué no se consigue completar la autenticación.
Dos códigos especialmente interesantes son:
| Código | Interpretación |
|---|---|
0xC0000064 |
El nombre de usuario no existe o es incorrecto. |
0xC000006A |
La cuenta existe, pero la contraseña introducida es incorrecta. |
Una sucesión de nombres de usuario distintos podría ser interesante desde el punto de vista de una posible enumeración de cuentas. Muchos intentos contra una misma cuenta también pueden justificar una investigación.
🧩 Tipo de inicio de sesión — Logon Type
El campo Logon Type ayuda a saber qué tipo de autenticación se intenta realizar.
| Tipo | Significado habitual |
|---|---|
| 2 | Inicio de sesión interactivo directamente en el equipo. |
| 3 | Acceso mediante red. |
| 4 | Proceso por lotes. |
| 5 | Servicio. |
| 7 | Desbloqueo del equipo. |
| 10 | Inicio interactivo remoto, por ejemplo mediante Remote Desktop. |
El tipo es importante porque no todos los 4625 representan la misma actividad.
Un fallo interactivo realizado físicamente en nuestro ordenador tiene un contexto muy diferente de múltiples intentos de tipo 3 procedentes de otro equipo de la red.
🌐 Dirección de red de origen
Cuando el intento procede de la red, puede aparecer una dirección IP de origen.
Por ejemplo:
Source Network Address: 192.168.1.50
Este dato puede resultar especialmente valioso durante una investigación porque permite relacionar el fallo con otro dispositivo.
En determinados inicios de sesión locales puede no existir una dirección remota relevante.
💻 Workstation Name
Puede indicar el nombre del equipo desde el que se inicia la petición de autenticación.
De nuevo, su utilidad depende del tipo de inicio de sesión.
⚙️ Authentication Package
Indica el mecanismo de autenticación utilizado. Podemos encontrar, entre otros:
- NTLM;
- Kerberos;
- Negotiate.
En una investigación profesional este dato permite entender mejor cómo se intenta realizar la autenticación.
8. Ahora lo hacemos con PowerShell
El Visor de eventos resulta cómodo para investigar manualmente uno o pocos eventos, pero en Blue Team necesitamos también consultar registros mediante comandos.
Abre Terminal o PowerShell como administrador.
Ejecuta:
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 10
Este comando solicita:
LogName='Security'→ buscar en el registro Seguridad;Id=4625→ mostrar únicamente fallos de inicio de sesión;-MaxEvents 10→ devolver como máximo los diez más recientes.
Ahora obtenemos desde PowerShell la misma información que anteriormente localizamos mediante la interfaz gráfica.
9. Mostrar los detalles del evento
Podemos solicitar una salida más legible:
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 5 |
Format-List TimeCreated, Id, ProviderName, Message
Aquí podemos comprobar:
- fecha y hora;
- Event ID;
- proveedor;
- contenido completo del evento.
Guarda también una captura de esta salida. Será nuestra segunda evidencia.
10. Buscar únicamente los eventos recientes
En un equipo utilizado durante meses pueden existir muchos eventos. Podemos limitar la búsqueda a un periodo determinado.
Por ejemplo, para analizar la última hora:
$inicio = (Get-Date).AddHours(-1)
Get-WinEvent -FilterHashtable @{
LogName = 'Security'
Id = 4625
StartTime = $inicio
}
Esta forma de trabajar empieza a parecerse mucho más a una consulta utilizada durante una investigación real.
11. Contar los intentos fallidos
También podemos comprobar cuántos eventos 4625 aparecen durante ese periodo:
$inicio = (Get-Date).AddHours(-1)
(
Get-WinEvent -FilterHashtable @{
LogName = 'Security'
Id = 4625
StartTime = $inicio
}
).Count
Un contador aislado no determina si existe un ataque, pero sirve para detectar rápidamente un volumen inusual y decidir si merece la pena investigar.
12. Comprobar la política de auditoría
Si no aparece ningún 4625 después de provocar el fallo, antes de concluir que Windows no lo registra debemos comprobar la configuración de auditoría.
Desde una Terminal o consola con permisos administrativos podemos ejecutar:
auditpol /get /category:*
Buscamos la configuración relacionada con los eventos de Logon/Logoff e inicio de sesión.
En un Windows 11 normal la auditoría de inicio de sesión contempla los intentos correctos y fallidos. Sin embargo, políticas locales, configuraciones corporativas o modificaciones anteriores pueden cambiar el comportamiento.
Primero comprobamos la configuración existente. No modificamos una política de auditoría simplemente porque no obtenemos el resultado esperado.
13. ¿Cuándo empieza a ser sospechoso?
Un único 4625 puede tener una explicación completamente normal:
- un usuario se equivoca de contraseña;
- una aplicación conserva credenciales antiguas;
- un servicio utiliza una contraseña que ha cambiado;
- una unidad de red intenta volver a conectarse;
- una tarea programada utiliza credenciales incorrectas.
Sin embargo, empiezan a resultar interesantes patrones como:
- decenas o cientos de 4625 en poco tiempo;
- una misma cuenta atacada repetidamente;
- muchos nombres de usuario diferentes;
- la misma IP intentando varias cuentas;
- direcciones IP inesperadas;
- intentos de acceso remoto cuando no deberían existir;
- actividad en horarios poco habituales;
- una secuencia de fallos seguida de un inicio de sesión correcto.
14. Ejemplo de razonamiento Blue Team
Imaginemos que encontramos:
21:03 → 4625 → admin 21:03 → 4625 → administrador 21:03 → 4625 → soporte 21:04 → 4625 → root 21:04 → 4625 → backup
Todos los eventos proceden además de la misma dirección IP.
Esto no demuestra automáticamente que exista un ataque, pero ya existe un patrón que merece investigación.
Podríamos estar observando, por ejemplo, un intento automatizado de descubrir una cuenta válida.
En cambio:
20:41 → 4625 → usuario habitual 20:42 → inicio correcto del mismo usuario
puede ser simplemente una contraseña escrita incorrectamente.
15. Qué evidencia obtenemos
Al finalizar la práctica deberíamos conservar:
- Captura 1: Event ID 4625 localizado en el Visor de eventos.
- Captura 2: detalles principales del evento.
- Captura 3: consulta del 4625 desde PowerShell.
- Resultado: identificación de la cuenta, tipo de logon, motivo del fallo y origen cuando esté disponible.
No es necesario publicar nombres reales de usuarios, direcciones IP públicas u otra información sensible. Para un artículo público se pueden ocultar o anonimizar estos datos.
16. ¿Qué demuestra esta práctica?
- que Windows registra los fallos de autenticación;
- que podemos localizarlos mediante el Visor de eventos;
- que podemos consultarlos mediante PowerShell;
- que un 4625 aporta contexto útil para una investigación;
- que podemos correlacionar hora, cuenta, tipo de acceso y posible origen.
- que cada 4625 sea un ataque;
- que una contraseña haya sido comprometida;
- que el atacante haya conseguido entrar;
- que una IP sea necesariamente maliciosa;
- que un gran número de eventos tenga una única explicación.
17. Aplicación práctica para un usuario doméstico
Aunque esta técnica forma parte del trabajo habitual de seguridad, también puede resultar útil en un ordenador doméstico.
Por ejemplo, podemos investigar por qué aparecen intentos de autenticación inesperados o comprobar si algún programa, servicio o dispositivo intenta utilizar credenciales antiguas.
Lo importante no consiste en alarmarse ante cualquier evento, sino en aprender a buscar patrones y contexto.
18. Aplicación profesional: Blue Team / SOC
Esta práctica reproduce a pequeña escala varias tareas habituales de un analista defensivo:
- consulta de registros;
- filtrado por Event ID;
- investigación temporal;
- interpretación de autenticaciones;
- búsqueda de patrones;
- uso de PowerShell para análisis;
- obtención y conservación de evidencias;
- diferenciación entre actividad normal y actividad potencialmente sospechosa.
En un entorno profesional este tipo de eventos normalmente no se analiza equipo por equipo. Se centraliza en herramientas SIEM como Microsoft Sentinel, Splunk, Wazuh u otras plataformas, donde pueden correlacionarse miles de eventos procedentes de diferentes equipos.
Sin embargo, entender primero el evento directamente en Windows permite comprender qué información recibe posteriormente un SIEM.
19. Conclusión
El Event ID 4625 constituye una de las evidencias básicas para estudiar fallos de autenticación en Windows.
En esta práctica generamos deliberadamente un fallo, comprobamos que Windows lo registra, localizamos el evento mediante el Visor de eventos y repetimos la consulta utilizando PowerShell.
El aprendizaje más importante no consiste en memorizar el número 4625, sino en adoptar una metodología:
Un evento aislado nos informa de algo que ha ocurrido. El análisis comienza cuando relacionamos esa evidencia con el resto del sistema.