Evento de Windows 4625: leer un inicio de sesión fallido

Qué es el 4625

El evento 4625 — «Error al iniciar sesión en una cuenta» — se escribe en el registro de seguridad de Windows cada vez que se rechaza un intento de autenticación, sea cual sea el motivo: contraseña incorrecta, cuenta inexistente, cuenta deshabilitada, inicio fuera del horario permitido. Su equivalente en caso de éxito es el 4624.

Es el evento más útil en un servidor Windows expuesto a internet, porque es donde un ataque de fuerza bruta se hace visible antes de tener éxito. Todo lo que hace una defensa a nivel de firewall empieza leyendo este flujo.

Si no ves ningún evento 4625 en un servidor que sabes expuesto, es la auditoría lo que está desactivado, no el servidor lo que está tranquilo. Comprueba y activa:

auditpol /get /subcategory:"Logon"
auditpol /set /subcategory:"Logon" /success:enable /failure:enable

Los campos que importan

Un registro 4625 es verboso y la mayor parte es ruido. Cinco campos llevan la información:

• Nombre de cuenta (bajo «Cuenta cuyo inicio de sesión ha fallado») — el usuario que se intentó. En un ataque real es un desfile de nombres que nunca existieron en tu máquina.
• Dirección de red de origen — la IP desde la que llegó el intento. Es el campo sobre el que actúas. Está vacío en los inicios de sesión locales por consola.
• Tipo de inicio de sesión — cómo se intentó entrar. 10 es RemoteInteractive (RDP), 3 es Red (SMB, o RDP tras algunas pasarelas), 2 es una consola física, 5 un servicio, 4 una tarea programada.
• Motivo del error y Estado / Subestado — el código hexadecimal que explica qué falló. Aquí está la distinción útil.
• Nombre de estación de trabajo — el nombre de host que envió el cliente. Las herramientas de ataque suelen mandar basura, una cadena aleatoria, o dejarlo en blanco, lo que ya es una señal.

Códigos de estado, descifrados

El campo que hay que leer es el Subestado; el Estado de nivel superior suele contener el genérico 0xC000006D. Aprende estos cinco y clasificarás casi cualquier 4625 de un vistazo:

• 0xC0000064 — el nombre de cuenta no existe. Casi siempre un ataque: tus propios usuarios conocen sus nombres de usuario.
• 0xC000006A — la cuenta existe pero la contraseña era incorrecta. O un usuario real equivocándose, o un bot que ha adivinado un usuario válido.
• 0xC0000234 — la cuenta está bloqueada. Si ves series de estos, tu directiva de bloqueo se está usando en tu contra.
• 0xC0000072 — la cuenta está deshabilitada. Con frecuencia es una cuenta olvidada que un atacante encontró y sigue probando.
• 0xC000006F / 0xC0000070 — inicio fuera del horario permitido, o desde una estación no autorizada. Poco frecuente, y conviene investigarlo en vez de ignorarlo.

Distinguir un ataque de una errata

Tres señales los separan, y conviene tener las tres antes de actuar automáticamente.

Ritmo y persistencia. Una persona hace dos o tres intentos en un minuto y luego o entra o te llama. Un bot mantiene un ritmo constante durante horas, toda la noche, sin pausa y sin llamar nunca a nadie.

Diversidad de cuentas. Una persona prueba una cuenta: la suya. Un bot recorre una lista — administrator, admin, user, test, sql, backup, scan — y la mayoría de esas cuentas no existen en tu máquina, que es exactamente la firma 0xC0000064 de arriba.

Origen. Tu gente entra desde un puñado de direcciones conocidas. Los ataques llegan de rangos de hosting, desde una dirección distinta cada pocos cientos de intentos, y a menudo desde varios países en la misma hora.

Esto agrupa los fallos del último día por dirección de origen y cuenta, de modo que las tres señales se ven a la vez:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddDays(-1)} |
  ForEach-Object {
    $d = ([xml]$_.ToXml()).Event.EventData.Data
    [pscustomobject]@{
      IP      = ($d | Where-Object Name -eq 'IpAddress')['#text']
      Account = ($d | Where-Object Name -eq 'TargetUserName')['#text']
      Status  = ($d | Where-Object Name -eq 'SubStatus')['#text']
    }
  } |
  Group-Object IP |
  Sort-Object Count -Descending |
  Select-Object -First 15 Count, Name,
    @{n='Accounts'; e={ ($_.Group.Account | Select-Object -Unique) -join ', ' }}

De leer eventos a bloquearlos

Leer los 4625 a mano es un diagnóstico, no una defensa — cuando lances la consulta, el ataque lleva ya una semana. Lo que cambia algo es hacerlo de forma continua y convertir un umbral en una regla de firewall.

La versión ingenua se suscribe al registro de seguridad, cuenta fallos por origen y llama a New-NetFirewallRule cuando un origen cruza la línea. Funciona, y luego se topa con los problemas con los que se topa cualquier script así: el conjunto de reglas crece hasta los miles y el firewall se arrastra, el registro rota bajo carga y se pierden eventos, el script muere en silencio tras un reinicio, y una coincidencia errónea deja al administrador fuera del único acceso.

RDP Protector ejecuta ese bucle como servicio, con una regla de firewall consolidada en vez de miles, una lista blanca que siempre gana a un bloqueo, y la decisión tomada localmente — así que aguanta cuando la red no aguanta. Lee el mismo flujo de eventos mostrado arriba; no se te oculta nada.