Una investigación reciente revela cómo el compromiso de una sola cuenta puede poner en riesgo toda una infraestructura en la nube. Un atacante logró escalar privilegios desde la recuperación de contraseñas hasta acceder a Azure DevOps, canalizaciones de desarrollo y recursos de Kubernetes. Lo más alarmante es que el incidente no utilizó malware ni fallos de software, sino que se basó en el abuso de servicios confiables.

Una sola cuenta comprometida puede abrir la puerta a todo un entorno de nube. Una investigación reciente muestra cómo un atacante utilizó una identidad comprometida para moverse desde la recuperación de contraseñas hacia Azure DevOps, tuberías de desarrollo y recursos de Kubernetes.

El incidente no dependió de un fallo de software o de malware personalizado. En su lugar, el intruso abusó de servicios confiables que las organizaciones utilizan a diario, convirtiendo los derechos de acceso ordinarios en una ruta hacia el código fuente, la configuración de despliegue y las credenciales de infraestructura.

Los analistas de Microsoft identificaron la actividad como Storm-3068 y descubrieron que el actor tomó el control de una cuenta a través de un restablecimiento de contraseña de autoservicio.

Microsoft afirmó en un informe que el registro de sus propios métodos de autenticación le otorgó al atacante un acceso persistente.

El caso ilustra por qué los sistemas de desarrollo se han convertido en objetivos atractivos. Ataques anteriores contra cuentas de Microsoft Entra ID abusaron de manera similar de funciones legítimas de la nube, aunque involucraron a un actor diferente.

Aquí, los repositorios conectados, las tuberías de automatización y los recursos de la nube amplificaron el impacto de una sola identidad comprometida.

Convierten una cuenta comprometida en acceso

Después de ganar el control de la cuenta, Storm-3068 utilizó herramientas administrativas legítimas y scripts automatizados para examinar proyectos de Azure DevOps, repositorios, tuberías y entornos de despliegue.

Este descubrimiento ayudó al intruso a comprender qué sistemas estaban conectados y dónde podrían estar disponibles credenciales valiosas. Azure DevOps resultó útil porque integraba el desarrollo de software y las operaciones de la nube.

Un fallo independiente de Azure DevOps MCP resaltó otra forma de hacer mal uso del acceso autorizado, pero esta intrusión, en cambio, explotó los permisos existentes de una cuenta para mapear rutas de despliegue confiables y recursos conectados.

El actor creó entonces una tubería maliciosa destinada a recopilar credenciales de Kubernetes a escala. Desplegó un agente de kube y ejecutó múltiples trabajos destinados a recopilar archivos de configuración de clústeres que contenían detalles de conexión e información de autenticación necesaria para acceder a los recursos de Kubernetes.

Microsoft señaló que el atacante desplegó una tubería autorizada para acceder a más de 50 recursos y autenticarse en servicios. Los investigadores descubrieron más tarde que siete archivos de configuración de clúster robados habían sido añadidos a un repositorio, proporcionando las credenciales necesarias para acceder a los clústeres de Kubernetes seleccionados.

Esa secuencia muestra cómo una plataforma de desarrollo puede revelar más que el código fuente. Los repositorios, las conexiones de servicio y la configuración de despliegue pueden proporcionar una hoja de ruta hacia el entorno más amplio de una organización, permitiendo que un atacante extienda su acceso a través de relaciones ya confiadas por la empresa.

Acceso a la nube

Storm-3068 también alteró scripts de la tubería para instalar el agente de gestión remota Atera y descargar la utilidad de tunelización Chisel.

Los investigadores afirmaron que estos cambios tenían como objetivo crear rutas alternativas de acceso remoto y exponer el servidor API de Kubernetes para una posible interacción con los clústeres.

Los comandos de Chisel establecieron un túnel inverso hacia una dirección IP externa, aunque la fuente proporcionada no reveló dicha dirección.

Los registros de auditoría de Azure DevOps y el historial de versiones de Git ayudaron a los investigadores a reconstruir la intrusión e identificar las credenciales robadas colocadas en el repositorio.

El equipo de respuesta de Microsoft analizó registros en sistemas de identidad, plataformas de desarrollo e infraestructura de nube para determinar hasta dónde se había movido el atacante.

Trabajó con la organización afectada mediante sesiones informativas diarias, orientación priorizada para la contención y recomendaciones destinadas a reducir las oportunidades de otro compromiso.

DART también colaboró con Microsoft Threat Intelligence para situar la actividad en un contexto de amenazas más amplio. Esa coordinación ayudó a refinar la investigación y a centrar los esfuerzos de respuesta en los entornos afectados a medida que surgían nuevos detalles.

Deberías monitorear la actividad de restablecimiento de contraseñas en busca de intentos repetidos o patrones que involucren a múltiples usuarios. Deberías reducir la exposición de las cuentas privilegiadas a los flujos de trabajo de restablecimiento de autoservicio y exigir una autenticación multifactor resistente al phishing, medidas relevantes para la exposición del portal de restablecimiento de contraseñas reportada a principios de este mes.

Tus equipos de desarrollo deberían exigir aprobaciones para los cambios de código, aplicar la protección de ramas y restringir los commits directos a ramas críticas para que las actualizaciones sigan los procesos de revisión establecidos.

Los permisos de la tubería también deberían limitar quién puede crear, modificar o ejecutar flujos de trabajo de compilación y despliegue, reduciendo las oportunidades de cambios no autorizados. Finalmente, deberías aplicar el acceso de privilegio mínimo en identidades, plataformas de desarrollo y recursos de la nube.

Revisiones regulares de los controles de identidad, DevOps y nube pueden reducir la probabilidad de que una sola cuenta comprometida se convierta en una vía de entrada a los entornos de producción a través de las propias conexiones confiables de tu organización.

Fuentes:
https://cybersecuritynews.com/hackers-turn-one-compromised-account/