Un threat actor convirtió una cuenta comprometida en acceso persistente a Azure DevOps, pipelines de desarrollo y clusters de Kubernetes sin usar malware.
El equipo de respuesta a incidentes de Microsoft investigó un caso que resume el desafío central de la seguridad en entornos cloud modernos: cuando identidades, código fuente, pipelines y producción están conectados, una sola cuenta comprometida puede convertirse en llave maestra. Storm-3068, el threat actor detrás del ataque, no necesitó exploits de software ni malware — bastó con aprovechar procesos legítimos de gestión de identidad y herramientas administrativas nativas de Azure DevOps para moverse lateralmente desde una cuenta de usuario hasta credenciales de más de 50 recursos autenticados en la nube.
El punto de entrada: un proceso de autoservicio sin controles suficientes
Storm-3068 comprometió la cuenta inicial a través del proceso de restablecimiento de contraseña de autoservicio de la organización afectada. Una vez dentro, el atacante registró sus propios métodos de autenticación en la identidad comprometida, estableciendo acceso persistente sin depender de la contraseña original. Este movimiento — técnicamente legítimo desde la perspectiva del sistema — le permitió sobrevivir a cualquier intento posterior de cambio de credenciales por parte del usuario real.
La técnica no es nueva, pero su efectividad sigue siendo alta en organizaciones donde los flujos de autoservicio no están monitoreados con la misma rigurosidad que los accesos administrativos tradicionales. El Microsoft Detection and Response Team (DART), que lideró la investigación, identificó que el patrón de actividad posterior al reset mostraba características incompatibles con el comportamiento habitual del usuario legítimo — un indicador que muchas organizaciones todavía no correlacionan en tiempo real.
Azure DevOps como objetivo de alto valor: más que un repositorio de código
Con acceso persistente asegurado, Storm-3068 dirigió su atención a Azure DevOps. Usando herramientas administrativas legítimas y scripts automatizados, el atacante enumeró repositorios, proyectos, pipelines y entornos de deployment conectados a la cuenta comprometida. Azure DevOps resultó ser un punto de intersección crítico: no solo contenía código fuente, sino también configuraciones de deployment, conexiones de servicio y credenciales de acceso a infraestructura cloud.
El atacante creó un pipeline malicioso diseñado específicamente para recolectar credenciales de Kubernetes a escala. El pipeline desplegó un kube agent y ejecutó múltiples trabajos con el objetivo de recopilar archivos kubeconfig — los archivos que contienen detalles de conexión a clusters y tokens de autenticación. La cuenta comprometida tenía permisos para acceder a más de 50 recursos y servicios autenticados, y el pipeline aprovechó esa autorización para operar sin levantar alertas inmediatas en los sistemas de monitoreo de la organización.
Además del kube agent, Storm-3068 modificó scripts de pipeline para instalar el agente de gestión remota Atera y descargar la utilidad de tunelización Chisel. Estos componentes no son malware en el sentido tradicional — son herramientas legítimas de administración y networking — pero en este contexto funcionaron como infraestructura de acceso remoto alternativa. El atacante ejecutó comandos Chisel para establecer un túnel inverso hacia una dirección IP externa, exponiendo potencialmente el API server de Kubernetes a interacción remota directa.
Siete archivos kubeconfig: el inventario de acceso a producción
Usando los logs de auditoría de Azure DevOps y el historial de versiones de Git, los investigadores de DART reconstruyeron la siguiente fase del ataque. Storm-3068 agregó siete archivos kubeconfig robados a un repositorio dentro de Azure DevOps. Cada uno de esos archivos representaba credenciales válidas para acceder a clusters de Kubernetes específicos — en otras palabras, las llaves a segmentos críticos de la infraestructura de producción de la organización.
Este movimiento ilustra por qué Azure DevOps es un objetivo de alto valor para atacantes que buscan moverse más allá del código: los repositorios, pipelines, service connections y configuraciones de deployment funcionan como un mapa detallado del entorno más amplio de la organización. En este caso, el atacante no necesitó explotar vulnerabilidades técnicas en Kubernetes — simplemente recolectó las credenciales que los propios procesos de deployment legítimos usaban para autenticarse.
Para América Latina, este patrón tiene implicancias concretas en sectores donde la adopción de DevOps y Kubernetes está creciendo rápidamente sin que las prácticas de seguridad de identidad hayan madurado al mismo ritmo. Organizaciones en Brasil y México que están migrando cargas de trabajo críticas a Azure y adoptando pipelines de CI/CD enfrentan el mismo riesgo estructural: si los controles de identidad no están a la altura de la complejidad de la infraestructura cloud, un solo punto de entrada puede escalar a compromiso de producción. No hay datos públicos de incidentes similares reportados específicamente en LATAM, pero la dependencia regional de los mismos proveedores cloud y herramientas de DevOps sugiere que la superficie de exposición es comparable.
Respuesta coordinada: briefings diarios y colaboración con Threat Intelligence
Una vez involucrado, DART trabajó directamente con el cliente afectado, proporcionando briefings diarios a medida que la investigación avanzaba. El equipo analizó telemetría de sistemas de identidad, plataformas de desarrollo e infraestructura cloud para reconstruir cómo se desarrolló el ataque y dónde Storm-3068 había expandido su acceso más allá del compromiso inicial.
DART también colaboró con Microsoft Threat Intelligence para contextualizar la actividad dentro de patrones de amenaza más amplios, ayudando a refinar el enfoque de la investigación y priorizar esfuerzos de respuesta en los entornos afectados. Más allá de contener la intrusión, el equipo proporcionó recomendaciones orientadas a mejorar la resiliencia de la organización y reducir oportunidades de compromiso futuro — incluyendo monitoreo de actividad de reset de contraseña, fortalecimiento de protección para cuentas privilegiadas con autenticación multifactor resistente a phishing, y aplicación de principios de mínimo privilegio en identidades, plataformas de desarrollo y recursos cloud.
Nuestro análisis
Este caso confirma un patrón que ya habíamos visto en incidentes anteriores documentados por equipos de respuesta de otros proveedores cloud: las identidades se han convertido en el nuevo perímetro de ataque, y los entornos de desarrollo — especialmente plataformas como Azure DevOps, GitHub Enterprise, GitLab — son objetivos de alto valor porque conectan identidades con código, infraestructura y producción en un solo flujo de trabajo. Storm-3068 no necesitó malware sofisticado ni exploits de día cero — bastó con aprovechar procesos legítimos de gestión de identidad y herramientas administrativas nativas para moverse lateralmente y recolectar credenciales a escala.
Lo que distingue este incidente de compromisos tradicionales de identidad es la velocidad con la que el atacante pudo mapear el entorno y extraer credenciales de alto valor. En organizaciones donde Azure DevOps tiene permisos amplios sobre recursos cloud y donde los pipelines operan con cuentas de servicio privilegiadas, un solo punto de entrada puede escalar a compromiso de producción en cuestión de horas. El hecho de que Storm-3068 haya podido acceder a más de 50 recursos autenticados desde una sola cuenta comprometida sugiere que los controles de mínimo privilegio no estaban aplicados de manera efectiva — un problema recurrente en entornos cloud donde la velocidad de deployment suele priorizar sobre la segmentación de permisos.
¿Qué pasaría si el próximo atacante que comprometa una cuenta con acceso a Azure DevOps no se limite a recolectar credenciales, sino que modifique pipelines de producción para inyectar código malicioso directamente en aplicaciones desplegadas a escala?
—
*Nota: Este artículo fue generado con asistencia de IA y revisado editorialmente para garantizar precisión factual y coherencia con el estándar editorial de CiberseguridadLatam.*