Un rociado, no un hallazgo técnico
La firma de seguridad Huntress reveló una campaña de password spraying que se desarrolló del 12 al 26 de junio de 2026 y alcanzó su punto máximo el 22 de junio. En esas dos semanas se dirigieron más de 81 millones de intentos de inicio de sesión contra cuentas de Microsoft 365. El tráfico salía de un rango IPv6 registrado a nombre de un único operador, y los atacantes no adivinaban contraseñas a ciegas. Reproducían pares de usuario y contraseña recogidos de filtraciones anteriores y sin relación entre sí, apostando a que la gente reutiliza sus credenciales de un servicio a otro. De aquella avalancha salieron 78 cuentas comprometidas en 64 organizaciones.
Lo llamativo es la ausencia de nada exótico. No hubo un día cero, ni malware ingenioso, ni una jugada en la cadena de suministro. Hubo volumen, credenciales reutilizadas y una vía de autenticación débil. Esa combinación está al alcance de cualquier atacante corriente, y por eso merece la atención de un propietario. La técnica es barata, se puede repetir cuantas veces haga falta 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 inicios de sesión esquivaron el MFA
El mecanismo fue una vía de acceso heredada. Los atacantes se autenticaron a través de las herramientas de línea de comandos de Azure con el flujo Resource Owner Password Credentials, conocido como ROPC, un método OAuth antiguo que acepta directamente un usuario y una contraseña y que, en muchos inquilinos, no llega a lanzar ninguna solicitud multifactor. Donde un inquilino tenía el MFA activado pero con un alcance estrecho, las credenciales reutilizadas entraron sin resistencia por el hueco. Huntress encontró una y otra vez las mismas configuraciones erróneas: MFA aplicado solo a aplicaciones seleccionadas, MFA exigido solo a los grupos de administradores, MFA requerido solo desde ubicaciones no confiables y políticas de Conditional Access olvidadas en modo de solo informe, donde registran pero nunca bloquean.
La lección menos evidente es que el MFA no es un interruptor, sino un mapa de cobertura. Un inquilino puede superar una auditoría que se limita a preguntar si el MFA existe y aun así dejar una puerta antigua sin cerrar. Los atacantes no derrotaron la autenticación multifactor. Encontraron los inicios de sesión en los que nunca se pedía. Toda la historia está en esa diferencia, y resulta invisible mientras nadie compruebe qué vías de autenticación sigue permitiendo un inquilino.
La media hora que cierra la brecha
Un problema de configuración tiene una respuesta de configuración, y casi todo se resuelve en una sesión administrativa breve, sin comprar nada. Bloquee la autenticación heredada y desactive el flujo ROPC, para que los inicios de sesión con usuario y contraseña que se saltan el MFA queden sencillamente rechazados. Exija la autenticación multifactor en cada aplicación y en cada inicio de sesión, no solo en las cuentas de administrador o en las ubicaciones no confiables, y pase Conditional Access del modo de solo informe al bloqueo activo. Después 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 un segundo motivo para moverse deprisa. Si unas credenciales reutilizadas abren un buzón con 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 acaba convertida en un suceso notificable y en una conversación con la autoridad de control. Cerrar la puerta cuesta una tarde de configuración. Dejarla abierta se paga en obligaciones de divulgación y en confianza perdida. Trate la capa de identidad como el perímetro en que se ha convertido.
Leer a continuación: Auditoría de IA no vio el fallo Linux que da root | Un fallo de 29 años en Squid filtra logins en claro
