Lo que detuvo 158,000 ataques diarios no aparece en ninguna cotización

Entramos a revisar otra cosa. El registro de eventos de Windows de un servidor de manufactura, filtrado por evento 4625 —inicio de sesión fallido— en las últimas seis horas:

IP ORIGEN            INTENTOS
85.239.151.18          11,204
109.205.211.106         7,891
109.205.211.107         7,433
109.205.211.108         6,902
94.26.68.37             3,180
94.26.68.38             2,800
─────────────────────────────
TOTAL                  39,410

Treinta y nueve mil cuatrocientos diez intentos fallidos. En seis horas. Proyectado al día: unos 158,000. Siete veces lo que ese mismo servidor recibía en julio.

Nadie en la empresa lo sabía. Y no por negligencia: el sistema funcionaba con normalidad. Nadie reportó lentitud, nada se cayó, ningún módulo dejó de abrir. Un ataque de fuerza bruta bien hecho no rompe nada — solo toca la puerta, sin parar, a ver si algún día abre.

El dato que cambió el diagnóstico#

Contar intentos es fácil y sirve de poco. Lo que importa es contra qué cuenta. Sacamos una muestra de 3,000 eventos y extrajimos el campo del usuario objetivo.

Esperábamos variedad: los diccionarios de ataque suelen probar admin, root, sa, test, nombres comunes, cuentas de servicio.

CUENTA OBJETIVO      INTENTOS (muestra de 3,000)
ADMINISTRADOR                             3,000
──────────────────────────────────────────────
cualquier otra                                0

El cien por ciento iba contra una sola cuenta: `ADMINISTRADOR`.

Y esa cuenta, en ese servidor, no existe con ese nombre desde hace meses. Fue renombrada.

Ahí está el desenlace completo. Cada uno de esos 158,000 intentos diarios falla en el primer paso, antes de que la contraseña importe. No están probando contraseñas contra una cuenta real: están probando contraseñas contra una cuenta que no está.

Lo incómodo#

Ese servidor tiene antivirus. Tiene reglas de firewall. Ninguno de los dos detuvo esto, y los dos tenían razón: no hay nada que detener. Son intentos de inicio de sesión legítimos en su forma, contra un servicio publicado a propósito. Técnicamente, el atacante está haciendo exactamente lo mismo que un empleado que teclea mal su contraseña. Solo que 158,000 veces al día.

Lo que evitó la brecha fue una decisión de un minuto que no genera factura, no tiene licencia anual y no aparece en ninguna propuesta comercial: cambiarle el nombre a la cuenta de administrador.

Esto es lo que casi nadie dice al vender seguridad. La mayor parte de lo que protege de verdad no es un producto. Es una lista de decisiones pequeñas, tomadas por alguien que sabía tomarlas, sobre cosas que ya estaban ahí.

La segunda incomodidad#

Aplicamos las mitigaciones. Cuatro días después volvimos a contar, esperando ver la curva caer.

Día de la mitigación         158,000 / día
Cuatro días después           22,206 / día

Bajó, pero siguió. Veintidós mil intentos diarios contra un servidor que ya había endurecido su acceso.

La conclusión es antipática y conviene decirla: nadie te avisa que dejaste de ser interesante. Los ataques automatizados no leen tu changelog. Siguen tocando durante días o semanas después de que dejaste de ser vulnerable. Esperar a que el ruido baje para dar algo por resuelto es una forma lenta de equivocarse.

Cómo verificamos que no hubo brecha#

Aquí es donde la mayoría de los reportes escriben «no se detectó evidencia de compromiso» y cambian de tema. Esa frase no significa nada si no dices qué buscaste.

Buscamos el evento 4624 —inicio de sesión exitoso— filtrado a los de origen externo, en toda la ventana del ataque. Cada uno se cruzó contra la lista de cuentas de la empresa y contra el horario de su titular.

Todos los ingresos exitosos externos correspondían a cuentas propias, en horarios que coinciden con el trabajo de esas personas. Ninguno vino de las seis direcciones atacantes. Ninguna cuenta desconocida entró.

Eso sí es una afirmación verificable. «No detectamos evidencia» no lo es.

Lo que hicimos#

1. Confirmamos el blindaje accidental. Verificamos que la cuenta renombrada realmente no responde con el nombre viejo, en lugar de asumirlo. Lo que salvó a esta empresa fue una decisión que nadie documentó y que cualquier reinstalación futura habría deshecho sin enterarse.

2. Contamos los dos signos. Fallidos y exitosos. Un reporte que solo cuenta ataques asusta; uno que además demuestra que nadie entró, informa.

3. Dejamos el conteo corriendo. El hallazgo se convirtió en un detector que corre solo y avisa cuando el patrón cambia — no cuando alguien se acuerda de revisar el visor de eventos.

4. Cambiamos la vía de entrada, no solo la cerradura. El servicio dejó de estar publicado a internet y pasó a una red privada donde el acceso se autentica antes de tocar el servidor. Ahí los 158,000 intentos diarios no llegan a la puerta: no encuentran la calle.

Lo que queda como regla#

Contar ataques no es medir riesgo. La pregunta útil es contra qué cuenta van. Un millón de intentos contra un usuario inexistente es ruido. Cien contra el nombre exacto de tu administrador es una emergencia.

Lo que más protege suele ser lo que menos se cobra. Renombrar una cuenta, quitar un servicio de internet, revisar quién es dueño de qué. Nada de eso se vende bien, y es lo que hace la diferencia.

Y una decisión de seguridad que nadie escribió no existe. Sobrevive hasta el día en que alguien reinstale el servidor con los valores de fábrica.

Caso real de una empresa manufacturera. Las direcciones IP mostradas son las de los atacantes. Se omitió todo dato que permita identificar a la empresa, sus cuentas o su infraestructura interna.