Todo empezó con un simulacro de incendio
En marzo, nuestro SOC vio cómo una operación de modelo de phishing como servicio convirtió a Railway, una plataforma de nube para desarrolladores con una reputación de IP impecable, en un motor de robo de tokens. Los señuelos de phishing mediante código de dispositivo alcanzaron a 344 organizaciones en cinco países en menos de tres semanas. Microsoft no tenía razón para calificar esos inicios de sesión como riesgosos. Y ese era justamente el punto.
Entonces hicimos algo que nunca habíamos hecho antes. Creamos a mano una política de acceso condicional que bloqueaba los rangos de IP de Railway, la validamos con 14 días de tráfico de la flota y la aplicamos a todos los inquilinos elegibles de Managed ITDR. Detuvo 305 intentos de ataque en la puerta. Ningún inicio de sesión legítimo se vio afectado.
Luego los atacantes se mudaron a nueva infraestructura. Siempre lo hacen.
Ese es el problema que construimos Adversary Infrastructure para resolver. Es la capacidad más nueva de Huntress Managed ITDR, y convierte esa respuesta de emergencia puntual en protección continua. Cuando un inquilino es atacado, todos los inquilinos reciben el bloqueo. Lo llamamos inmunidad de rebaño para la identidad.
Los atacantes alquilan infraestructura limpia y escalan con IA
La campaña de Railway nos reveló algo sobre cómo funcionan hoy los ataques a la identidad. Entre 344 víctimas, no encontramos dos señuelos de phishing idénticos. Cada uno estaba lo suficientemente personalizado para evadir el filtrado de correo. Ese tipo de variedad a ese volumen significa que la automatización o la IA está escribiendo los señuelos. El grupo detrás de esto, EvilTokens, vende una tienda con flujos de trabajo de IA para evadir filtros, personalizar pretextos y buscar bandejas de entrada como objetivos de fraude electrónico. Incluso tiene una mesa de soporte 24/7.
El lado de la infraestructura también cambió. Los atacantes ya no necesitan comprar alojamiento resistente a la interrupción. Alquilan espacio en la nube limpio, barato y confiable, levantan un relevo de tokens en minutos y lo desmantelan cuando queda expuesto. Las plataformas para desarrolladores, los túneles VDI y los relevos AiTM parecen legítimos para la calificación de riesgo de Microsoft hasta que alguien demuestra lo contrario.
La escala es difícil de exagerar. En una sola ventana de 14 días, 5.086 direcciones IP de atacantes distintas golpearon la flota de Huntress. Los partners no pueden curar listas de bloqueo a ese ritmo. Nadie puede, a mano.
Qué es Adversary Infrastructure
Adversary Infrastructure bloquea a los atacantes en el inicio de sesión de Microsoft 365, antes de que lleguen a obtener una sesión.
Figura 1: Adversary Infrastructure en la Huntress Platform
Cuando el Huntress SOC confirma la infraestructura de alojamiento, relevo o proxy detrás de un compromiso en un inquilino, la convertimos en una política de bloqueo de acceso condicional en todos los inquilinos elegibles que se hayan inscrito. Los ataques desde esa infraestructura fallan en el inicio de sesión en lugar de convertirse en incidentes que tienes que limpiar.
Es un bloqueo de precisión, originado en ataques reales que ya investigamos entre las más de 17 millones de identidades que protegemos. Solo los rangos de IP que son maliciosos, nada más. Huntress lo mantiene de principio a fin. No hay ninguna lista de bloqueo que tengas que curar, ninguna política que tengas que escribir, ningún feed de amenazas que tengas que consumir. Y está incluido en Managed ITDR for Microsoft 365 sin costo adicional.
Cómo funciona
Todo el ciclo va desde un incidente confirmado hasta el bloqueo en toda la flota, muchas veces el mismo día.
El SOC confirma un compromiso con un incidente real en un inquilino real, con las direcciones de alojamiento, relevo o proxy detrás de este.
Los ingenieros de detección validan la infraestructura. Tiene que ser espacio de centro de datos o alojamiento, acotado estrictamente a la evidencia, con cero inicios de sesión legítimos en toda la flota y reportes confirmados de al menos dos partners sin relación entre sí. Un segundo ingeniero revisa cada nominación. Si usuarios reales inician sesión desde una dirección, no se implementa.
Huntress implementa el bloqueo. Las campañas nuevas van primero a nuestros propios inquilinos canario. Luego una política de bloqueo con una ubicación con nombre por campaña, cada una etiquetada [HUNTRESS], se despliega a todos los inquilinos elegibles que se hayan inscrito.
Figura 2: Políticas de acceso condicional por campaña en Adversary Infrastructure
El siguiente ataque falla en el inicio de sesión. No se emite ningún token. El ataque nunca se convierte en un incidente.
Recibes el comprobante. Cada bloqueo genera un reporte de incidente de severidad baja que nombra la identidad objetivo, el origen y la campaña, y la credencial que el atacante intentó usar se rota.
Revisamos cada inquilino a diario, reparamos la desviación de configuración y actualizamos los rangos a medida que los atacantes rotan. Nunca tocamos las políticas que tú creaste. Los inquilinos que no pueden ejecutar acceso condicional igual reciben las mismas detecciones y reportes de incidente, solo que después del inicio de sesión en lugar de antes.
Dos campañas que dieron origen a Adversary Infrastructure
Cada campaña que convertimos en protección para toda la flota empezó como el peor día de alguien. Aquí hay dos.
LSHIY LLC: 81 millones de intentos de inicio de sesión desde un solo rango de IPv6. Tres meses después de Railway, nuestro SOC detectó un ataque de rociado de contraseñas que repetía credenciales validadas mediante ROPC, un flujo de autenticación heredado que se salta por completo la solicitud de MFA. Comprometió 78 cuentas en 64 organizaciones. Esta es la parte que dolió: 55 de esas cuentas tenían políticas de acceso condicional activas que exigían MFA. Las políticas parecían correctas. Simplemente no cubrían el flujo que usó el atacante. LSHIY ahora es una campaña activa de Adversary Infrastructure. El próximo inquilino que ese rango toque lo bloqueará en el inicio de sesión, tenga o no una brecha en su política de MFA.
1337 Services GmbH: diez semanas de repetición de tokens. Entre julio y septiembre, un atacante capturó sesiones mediante relevos AiTM y repitió los tokens robados desde el rango de IP 193.26.115[.]0/24 de un proveedor de alojamiento alemán. Respondimos en 79 organizaciones: 497 inicios de sesión exitosos contra más de 200.000 intentos fallidos. El operador rotó por seis direcciones dentro de ese rango, una tras otra, con períodos de inactividad entre fases. Un bloqueo escrito para una dirección no hacía nada contra la siguiente. Microsoft las marcó de forma individual. El bloqueo a nivel de rango, mantenido por Huntress y actualizado a medida que el atacante se mueve, está diseñado exactamente para este patrón.
En ambos casos, los primeros inquilinos afectados pagaron el precio de la limpieza: dispositivos fraudulentos, métodos de MFA eliminados, reglas ocultas en la bandeja de entrada, un correo de nómina enviado a un contador externo. Con Adversary Infrastructure, el próximo inquilino nunca llega tan lejos.
Dónde encaja Managed ISPM
Si te preguntas por qué los bloqueos de acceso condicional viven en ITDR cuando Managed ISPM ya administra el acceso condicional, aquí está la respuesta clara.
ISPM es postura. Despliega controles amplios y duraderos que cierran categorías enteras de ataques: bloquear el flujo de código de dispositivo, restringir la autenticación heredada y ROPC, exigir MFA para todas las aplicaciones. Estos controles no apuntan a un adversario en particular. Son la base, y permanecen vigentes. Cada política se ejecuta primero en Learning Mode durante 14 días, para que nada se rompa.
Adversary Infrastructure es respuesta. Está acotada de forma precisa a los rangos de IP exactos detrás de incidentes que el SOC ya reportó. Cambia a medida que rotan las campañas. Cada bloqueo genera un reporte de incidente. Bloquear el flujo de código de dispositivo es una política de ISPM. Ir tras Railway es una política de ITDR. Ambas son acceso condicional, cumpliendo funciones distintas.
También funcionan mejor juntas. ISPM construyó la infraestructura y la experiencia para desplegar acceso condicional en miles de inquilinos sin dejar a nadie bloqueado. Eso fue lo que nos permitió convertir la respuesta a Railway en un producto. La postura cierra la puerta. La respuesta atrapa a quien todavía intenta girar la manija.
¿Ya usas Managed ITDR? Activa Adversary Infrastructure para desbloquear esta nueva protección
Adversary Infrastructure ya está disponible en Managed ITDR for Microsoft 365 a partir de hoy, 5 de noviembre.
Los socios de ITDR existentes quedan excluidos por defecto y pueden activarlo desde la página de configuración de ITDR. Los socios que se incorporen a partir de hoy quedan incluidos por defecto. Los inquilinos elegibles necesitan Entra ID P1 o P2 (Business Premium, o E3 con P1, en adelante), los valores predeterminados de seguridad desactivados, y un inquilino saludable y totalmente incorporado en Huntress.
Debes estar incluido para estar protegido, y cada inquilino que incluyas fortalece a todo el grupo.
¿Quieres la historia completa? Únete a mí, Rich Mozeleski, y Matt Anderson el 19 de noviembre para la transmisión en vivo Herd Immunity for Microsoft 365: How We Stop Attacks at Sign-In. Repasaremos las campañas, la puerta de nominación y lo que viene a continuación.
¿Listo para probar Adversary Infrastructure en Managed ITDR? Comienza hoy tu prueba gratuita de 14 días de Managed ITDR.
