La filtración de 3,6 millones de registros de Azure: por qué tu organigrama es ahora el plano de un atacante
El 31 de julio de 2026, un actor de amenaza con el alias **TheHatman** comenzó a publicar anuncios en foros clandestinos de ciberdelincuencia ofreciendo bases de datos de empleados supuestamente extraídas de los tenants de Microsoft Azure y Entra de nueve grandes empresas. Los dumps se anunciaban con entre aproximadamente 145.000 y más de 800.000 registros por organización, totalizando alrededor de 3,64 millones de registros de empleados entre las víctimas nombradas. Hudson Rock, en colaboración con InfoStealers.com, publicó el análisis técnico principal de la campaña el 16 de agosto de 2026. Para el 17 de agosto, la historia había saltado a la cobertura de prensa de seguridad mainstream, con TCS, una de las víctimas nombradas, presentando una declaración formal ante la Bolsa de Valores de Bombay el 10 de agosto.
El episodio es notable no por lo robado —no hay evidencia de compromiso de datos de clientes— sino por lo que el material robado habilita a continuación. Un directorio de empleados es la materia prima para compromiso de correo corporativo, spear phishing a escala, movimiento lateral hacia plataformas SaaS y ransomware dirigido por identidad. La filtración se entiende mejor como un multiplicador de fuerza que facilita cualquier otro ataque contra las organizaciones afectadas, no como un evento de brecha aislado.
Este artículo recorre qué ocurrió, qué muestra y qué no muestra la evidencia, y qué deben hacer en respuesta todos los equipos de seguridad cloud y de identidad.
Qué se tomó realmente
Los datos anunciados son material de directorio de empleados: nombres, IDs de empleado, cargos, líneas de reporte, información de contacto y, en algunos casos, datos de estructura organizacional que mapean las cuentas de administrador global y las convenciones de nomenclatura de cuentas de servicio de los tenants afectados. Los listados de TheHatman describían el material como extraído "directamente" de los tenants corporativos de Azure y Entra usando credenciales comprometidas, y el momento y la escala de los dumps han llevado a varios investigadores a concluir que el proceso de recolección fue al menos parcialmente automatizado una vez obtenido el acceso inicial.
Es importante ser preciso sobre qué no está en los datos anunciados. No hay evidencia de que se haya tocado información de clientes, sistemas de clientes o sistemas operativos. No hay evidencia de una vulnerabilidad de plataforma o zero-day de Microsoft Azure. No hay evidencia de compromiso del plano de control de Microsoft Entra ID. La campaña —basada en lo divulgado y en el propio análisis de Hudson Rock— se apoya en credenciales robadas, recolectadas en muchos casos por malware de tipo infostealer en endpoints individuales, y luego usadas para autenticarse legítimamente en los tenants afectados y extraer datos de directorio a través de APIs legítimas.
Esta distinción importa porque cambia el playbook de respuesta. La remediación no es "parchear un bug de plataforma de Microsoft". La remediación es higiene de credenciales y de sesión, aplicación de acceso condicional e ingeniería de detección alrededor de lecturas legítimas pero sospechosas del directorio.
Las víctimas
Las nueve organizaciones nombradas incluyen McDonald's, Vodafone, Kyndryl y TCS, entre otras. La lista completa se describe en la cobertura de Cybernews, SecurityWeek, BleepingComputer y The Register. Algunas de las víctimas han disputado el encuadre más agresivo del incidente.
TCS presentó una declaración formal ante la Bolsa de Valores de Bombay el 10 de agosto, tras recibir alertas de threat intelligence sobre la posible exposición de datos de empleados. La posición de la compañía es que no ha encontrado evidencia creíble de una brecha de sus propios sistemas o entornos de clientes. TCS reportó que la información referenciada parece tener más de cuatro años de antigüedad y estar limitada a detalles básicos de empleados como nombres, IDs, cargos e información de contacto, añadiendo que nada apunta a datos de clientes, sistemas de clientes o sistemas operativos propios afectados.
La declaración de TCS es en sí misma un caso de estudio útil de cómo manejar la divulgación de una brecha alleged en mercados públicos. Es específica, se compromete a una revisión continua, reconoce la threat intelligence que disparó la investigación, y no sobre-reclama ni inocencia ni compromiso. Otras organizaciones nombradas han emitido respuestas menos públicas pero se reporta que están llevando a cabo investigaciones similares.
El hecho de que una de las organizaciones nombradas dispute públicamente el encuadre más agresivo del incidente es en sí mismo evidencia de que la mecánica subyacente de la campaña es más matizada que lo que sugiere el titular "Fortune 500 breach". Es consistente con la hipótesis de trabajo de que el atacante recolectó datos de forma oportunista desde múltiples tenants comprometidos a lo largo del tiempo y ahora está empaquetando el material agregado como una sola venta.
Por qué esto probablemente no es una vulnerabilidad de Azure
El análisis de Hudson Rock, reproducido por múltiples medios, es la evaluación técnica pública más creíble hasta la fecha. El razonamiento del investigador es directo: una vulnerabilidad a nivel de plataforma en Microsoft Azure o Entra habría producido víctimas en empresas de todos los tamaños, porque toda organización que ejecuta Entra estaría expuesta. La lista de víctimas observada —nueve grandes empresas, todas de nivel Fortune 500— no encaja con el patrón que produciría un zero-day de Azure.
"A juzgar por el tamaño masivo de las organizaciones impactadas, parece altamente probable que esta campaña se origine en explotación dirigida de infecciones de Infostealer en lugar de una vulnerabilidad sistémica de día cero en Azure", escribió Hudson Rock. "Si se tratara de una vulnerabilidad generalizada, probablemente veríamos un espectro mucho más amplio de organizaciones impactadas, incluyendo negocios pequeños, en lugar de solo estas masivas empresas de nivel Fortune 500".
Microsoft no ha publicado, hasta la fecha de este artículo, un aviso de seguridad vinculado a la campaña. La ausencia de un aviso es consistente con la hipótesis de robo de credenciales en lugar de con una vulnerabilidad de plataforma.
Cómo entró el atacante
Dos mecanismos principales han sido citados en la cobertura pública de la campaña: password spray y MFA fatigue. Ambos son bien conocidos y bien documentados. El password spray se apoya en probar un número pequeño de contraseñas comunes contra muchas cuentas en el mismo objetivo organizacional, esperando encontrar usuarios que hayan elegido contraseñas débiles. El MFA fatigue, a veces llamado MFA bombing o prompt bombing, se apoya en disparar un alto volumen de prompts de autenticación al dispositivo de un usuario y esperar que el usuario apruebe uno para que los prompts paren.
Ambos ataques se mitigan con controles que llevan años disponibles en Entra ID. Las políticas de Conditional Access pueden requerir MFA resistente a phishing, pueden requerir dispositivos compliant o hybrid-joined, pueden bloquear autenticación legacy y pueden aplicar límites de frecuencia de inicio de sesión. La configuración de cross-tenant access puede restringir lo que una identidad externa puede hacer dentro de un tenant. La continuous access evaluation puede revocar una sesión cuando un cambio de control debería invalidarla.
El hecho de que la campaña haya tenido éxito contra al menos algunas de las nueve organizaciones nombradas es, por sí mismo, evidencia de que uno o más de esos controles no estaban aplicados o no estaban aplicados consistentemente.
Vale la pena señalar un tercer mecanismo más moderno: el robo de tokens de un navegador ya autenticado. Cuando el malware infostealer extrae un token de sesión vivo de un navegador autenticado, el atacante puede reproducir una sesión que ya ha satisfecho MFA. MFA sube el coste pero no cierra el camino. Los controles que vinculan la sesión a un dispositivo conocido —requisitos de dispositivo compliant de Conditional Access y las funcionalidades de token protection de Entra ID— son lo que rompe la reproducción. Como han observado múltiples investigadores, los ataques de MFA fatigue sortean el prompt en lugar de atravesarlo.
Por qué un dump de directorio es tan valioso
Una filtración de directorio de empleados no es una brecha en el sentido en que lo es una brecha de base de datos de clientes. No hay datos de tarjetas de pago, no hay información de salud, no hay PII a la escala de una base de datos de consumo. Lo que sí hay es la arquitectura del objetivo.
Las líneas de reporte le dicen a un atacante quién reporta a quién. Esa información es la base para spear phishing: un atacante haciéndose pasar por un ejecutivo senior puede construir una solicitud que se siente natural para un subordinado porque el subordinado realmente le reporta a ese ejecutivo. Los nombres de cuentas de servicio le dicen al atacante qué identidades no humanas existen en el tenant, lo cual es útil para dirigir password spray contra cuentas que tienen patrones de nomenclatura predecibles. Los identificadores de administradores globales, si están presentes, le dicen al atacante qué cuentas merecen los intentos de compromiso de mayor esfuerzo.
El ataque aguas abajo del que una organización debería preocuparse no es la divulgación del directorio en sí. Es el intento de compromiso de correo corporativo que aterriza en la bandeja de entrada de un controller tres semanas después, escrito por alguien que sabe exactamente a quién reporta ese controller, firmado con un nombre ejecutivo plausible, haciendo referencia a una relación real con un proveedor con el que el controller realmente ha trabajado. El dump de directorio hace que ese email sea más convincente. Todo lo demás en el playbook del atacante permanece igual.
Ingeniería de detección: qué buscar
La firma de este ataque, vista en los logs de Entra ID, es un patrón de lecturas legítimas de directorio desde sesiones de autenticación de apariencia legítima que se originan desde localizaciones o contextos de sesión inesperados. Las señales específicas a investigar incluyen:
- Eventos de inicio de sesión desde países o ASNs que no forman parte de las operaciones de negocio normales para el usuario afectado. - Inicios de sesión que tienen éxito sin un paso de autenticación interactiva, sugiriendo un token reproducido. - Múltiples inicios de sesión exitosos a la misma cuenta en una ventana corta de tiempo desde distintas geolocalizaciones. - Lecturas de alto volumen contra endpoints de Microsoft Graph como `/users`, `/groups`, `/organization` y `/directoryRoles` desde una sola sesión o desde un número pequeño de sesiones. - App registrations y service principals nuevos o modificados dentro del tenant, en particular con permisos elevados de Graph. - Fallos de Conditional Access que sin embargo resultan en un inicio de sesión exitoso, indicando un bypass de control o una mala configuración.
Para organizaciones con Microsoft Sentinel, las consultas de caza relevantes se agrupan alrededor de patrones de exfiltración de datos dirigida por identidad. Un punto de partida útil es alertar sobre cualquier sesión que enumere con éxito más de un umbral de usuarios, grupos o directory roles vía Microsoft Graph, particularmente cuando esa enumeración viene de una sesión que se autenticó sin un paso interactivo reciente.
Para organizaciones que aún no han desplegado Microsoft Sentinel o tooling equivalente, la misma lógica de detección puede implementarse contra los logs de sign-in y auditoría de Entra ID usando consultas de Azure Monitor log o un SIEM de terceros. Los datos están ahí; el trabajo de ingeniería es convertirlos de entradas de log en alertas de alta confianza.
Mitigación y remediación
El playbook de mitigación para una organización que sospecha que puede ser una víctima nombrada o innominada —o que quiere endurecerse contra el mismo ataque— tiene tres anillos concéntricos.
El anillo interior es higiene de credenciales y sesión. Aplicar MFA resistente a phishing usando llaves de seguridad FIDO2 o passkeys de plataforma. Requerir dispositivo compliant de Conditional Access o dispositivo hybrid-joined para cualquier inicio de sesión que pueda leer datos de directorio. Habilitar token protection en Entra ID para vincular los tokens de sesión al dispositivo que los adquirió. Configurar cross-tenant access settings para restringir lo que cualquier identidad externa puede hacer en tu tenant. Habilitar continuous access evaluation para asegurar que los cambios de control invalidan inmediatamente las sesiones activas.
El anillo medio es detección y respuesta. Incorporar las consultas de caza listadas arriba en tu workflow diario de monitoreo. Ejecutar una revisión enfocada de los últimos 90 días de actividad de Microsoft Graph en el tenant, buscando los patrones descritos. Validar que ninguna app registration o service principal haya sido añadido por actores no confiables. Confirmar que ninguna política de Conditional Access haya sido debilitada o eliminada sin un ticket de cambio correspondiente. Confirmar que ninguna cuenta break-glass haya sido usada.
El anillo exterior es el problema más amplio de exposición del directorio de empleados. Trata tu organigrama interno como un activo defensivo, no solo como un artefacto de RRHH. Restringe quién puede ver el organigrama completo y el roster de administradores globales. Audita los terceros que tienen acceso a esos datos. Considera si tu sistema de RRHH, tu producto SaaS de organigrama y tu proveedor de identidad están filtrando más datos de directorio de los operacionalmente necesarios. Cada uno de esos es un camino secundario potencial para el mismo tipo de dump.
Qué decir al equipo ejecutivo
El encuadre a nivel de consejo para este incidente es directo. Un atacante usó credenciales robadas, recolectadas desde endpoints individuales por malware de tipo infostealer, para autenticarse legítimamente en los tenants de Azure de nueve grandes organizaciones y extraer datos de directorio de empleados. El atacante está vendiendo esos datos en foros clandestinos. Los datos en sí mismos no son información de clientes, pero son la materia prima para la próxima ola de compromiso de correo corporativo, spear phishing y ransomware dirigido por identidad contra las organizaciones afectadas.
La pregunta ejecutiva es si los controles de identidad de la organización son lo bastante buenos para prevenir el mismo ataque. ¿MFA resistente a phishing aplicado en todas partes? ¿Requisitos de dispositivo compliant de Conditional Access en vigor? ¿Token protection habilitado? ¿Cross-tenant access settings configurados? ¿Continuous access evaluation activa? Si alguna de esas respuestas es no, la organización es candidata para la próxima versión de esta campaña.
Reflexión final
La filtración del directorio de Azure no es una brecha de Microsoft Azure. Es una brecha de higiene de credenciales que casualmente produjo salida con forma de Azure. La solución no es un parche de plataforma de Microsoft. La solución es disciplina de controles de identidad, aplicada con el mismo rigor que las organizaciones maduras aplican a la segmentación de red y la gestión de parches.
Las fuentes verificadas para las afirmaciones técnicas incluyen el análisis de Hudson Rock en InfoStealers.com (16 ago 2026), la cobertura de Cybernews por Paulina Okunytė, SecurityWeek por Ionut Arghire, BleepingComputer por Ionut Ilascu, la cobertura de The Register y el análisis de Purple Shield Security por Yonatan Hoorizadeh. La declaración de TCS ante la Bolsa de Bombay es la fuente autoritativa para la posición de TCS.