Un rociado, no una brecha técnica

La firma de seguridad Huntress reveló una campaña de password spraying que se ejecutó del 12 al 26 de junio de 2026, con su punto máximo el 22 de junio, en la que se dirigieron más de 81 millones de intentos de acceso contra cuentas de Microsoft 365. El tráfico procedía de un rango de IPv6 registrado a un único operador, y los atacantes no adivinaban contraseñas a ciegas. Reproducían pares de nombre de usuario y contraseña obtenidos de filtraciones anteriores no relacionadas, apostando a que las personas reutilizan sus credenciales entre servicios. De esa avalancha, 78 cuentas fueron comprometidas en 64 organizaciones.

Lo llamativo es la ausencia de cualquier cosa exótica. No hubo un día cero, ni malware ingenioso, ni un truco de cadena de suministro. Fue volumen más credenciales reutilizadas más una vía de autenticación débil. Esa combinación está al alcance de cualquier atacante común, y por eso merece la atención de un propietario: la técnica es barata, repetible y apunta a la capa de identidad que la mayoría de las empresas dan por asegurada con la autenticación multifactor.

Cómo los accesos esquivaron el MFA

El mecanismo fue una vía de inicio de sesión antigua. Los atacantes se autenticaron a través de las herramientas de línea de comandos de Azure usando el flujo Resource Owner Password Credentials, conocido como ROPC, un método OAuth más antiguo que acepta directamente un nombre de usuario y una contraseña y que, en muchos inquilinos, no activa ningún aviso multifactor. Donde un inquilino tenía el MFA activado pero limitado de forma estrecha, las credenciales reutilizadas pasaron directas por el hueco. Huntress encontró las mismas configuraciones erróneas una y otra vez: MFA aplicado solo a aplicaciones seleccionadas, MFA exigido solo a grupos de administradores, MFA requerido solo desde ubicaciones no confiables y políticas de Conditional Access dejadas en modo solo de informe, donde registran pero nunca bloquean.

La lección menos obvia es que el MFA no es un interruptor, sino un mapa de cobertura. Un inquilino puede superar una auditoría que pregunta si existe el MFA y aun así dejar una puerta antigua sin cerrar. Los atacantes no derrotaron la autenticación multifactor; encontraron los inicios de sesión donde nunca se pedía. Esa distinción es toda la historia, y resulta invisible a menos que alguien compruebe qué vías de autenticación sigue permitiendo un inquilino.

La media hora que cierra la brecha

Este es un problema de configuración con una respuesta de configuración, y la mayor parte es una breve sesión administrativa en lugar de una compra. Bloquee la autenticación antigua y desactive el flujo ROPC, para que los inicios de sesión con usuario y contraseña que omiten el MFA sean simplemente rechazados. Exija la autenticación multifactor en cada aplicación y cada inicio de sesión, no solo en las cuentas de administrador o en las ubicaciones no confiables, y pase Conditional Access del modo solo de informe al bloqueo activo. Luego revise los registros de inicio de sesión en busca del patrón de rociado fallido y restablezca cualquier credencial que una filtración pasada haya podido exponer.

Para una empresa europea hay una segunda razón para actuar rápido. Si unas credenciales reutilizadas abren un buzón que contiene datos personales, el incidente puede activar el deber de notificación del RGPD en un plazo de 72 horas, de modo que una brecha de identidad silenciosa puede convertirse en un evento notificable y en una conversación con el regulador. El INCIBE recomienda precisamente esta higiene de configuración. El coste de cerrar la puerta es una tarde de configuración; el coste de dejarla abierta se mide en obligaciones de divulgación y confianza perdida. Trate la capa de identidad como el perímetro en que se ha convertido.