Microsoft demostró que el compromiso de una sola identidad puede convertirse en una vía de acceso amplia dentro de los entornos de desarrollo y la nube, incluso sin utilizar software malicioso ni explotar vulnerabilidades. En un nuevo informe de la serie Cyberattack Series, el equipo Microsoft Detection and Response Team (DART) documentó el movimiento del grupo Storm-3068 desde una cuenta comprometida hasta Azure DevOps, las canalizaciones de desarrollo y los recursos de Kubernetes.
La intrusión comenzó mediante un proceso de restablecimiento de contraseña de autoservicio. Tras acceder a la cuenta del usuario, el atacante registró sus propios métodos de autenticación, lo que le proporcionó acceso persistente a la identidad. Después utilizó herramientas administrativas legítimas y scripts automatizados para inventariar los repositorios, proyectos, canalizaciones y entornos de despliegue en Azure DevOps.
De la identidad a las rutas de despliegue
Azure DevOps era un punto de gran valor porque conecta la identidad con el desarrollo de software y las operaciones en la nube. Mediante el mapeo de las rutas de despliegue y los recursos asociados, Storm-3068 identificó formas de desplazarse hacia otras partes del entorno.
Los investigadores descubrieron una canalización maliciosa diseñada para recopilar credenciales de Kubernetes a gran escala. La canalización desplegó un agente de Kubernetes y ejecutó varias funciones para recopilar archivos kubeconfig que incluían detalles de conexión a los clústeres y datos de autenticación. Gracias a los permisos de la cuenta comprometida, la canalización estaba autorizada a acceder a más de 50 recursos y autenticarse en distintos servicios.
También se modificaron scripts de las canalizaciones para instalar el agente de administración remota Atera y descargar la herramienta de creación de túneles Chisel. Se utilizaron comandos de Chisel para crear un túnel inverso hacia una dirección IP externa, lo que potencialmente permitió la interacción remota con clústeres de Kubernetes. El equipo de investigación reconstruyó la siguiente fase del ataque basándose en los registros de auditoría de Azure DevOps y en el historial de versiones de Git, donde se añadieron siete archivos kubeconfig robados a un repositorio.
¿Qué revela el caso a los defensores?
La importancia del incidente reside en que el primer punto de intrusión, por sí solo, no bastaba para explicar la magnitud del acceso final. El riesgo surgió de la interconexión entre los sistemas de identidad, los repositorios, las canalizaciones de compilación y despliegue y la infraestructura operativa. Por ello, proteger cada capa de forma aislada no garantiza contener una cuenta comprometida si sus permisos abren rutas confiables hacia capas posteriores.
DART respondió analizando datos de los sistemas de identidad, las plataformas de desarrollo y la infraestructura en la nube, y trabajó con el cliente mediante sesiones informativas diarias y directrices priorizadas para la contención y la remediación. También colaboró con Microsoft Threat Intelligence para situar la actividad en su contexto más amplio.
Medidas defensivas prácticas
- Supervisar la actividad de restablecimiento de contraseñas en busca de intentos repetidos o patrones dirigidos contra varios usuarios.
- Reducir la exposición de las cuentas con privilegios elevados a las rutas de restablecimiento de autoservicio y exigir autenticación multifactor resistente al phishing.
- Exigir la aprobación de los cambios de código y activar la protección de ramas para impedir modificaciones no autorizadas.
- Restringir los commits directos en las ramas críticas y exigir que los cambios cuenten con una revisión y una aprobación claras.
- Controlar los permisos de las canalizaciones de compilación y despliegue, y determinar quién puede crearlas, modificarlas o ejecutarlas.
- Aplicar el principio de mínimo privilegio a las identidades, las plataformas de desarrollo y los recursos en la nube para limitar el impacto del compromiso de una sola cuenta.
¿Por qué es importante esta noticia?
Este caso muestra que los registros de identidad, Azure DevOps, Git y los entornos de Kubernetes deben leerse como una imagen de seguridad interconectada, no como fuentes independientes. Las preguntas abiertas que confirma la fuente se refieren a la capacidad de las organizaciones para detectar el uso indebido de herramientas legítimas, revisar los permisos que atraviesan distintos entornos y evitar la filtración de archivos de credenciales a los repositorios antes de que se utilicen para acceder a producción.