Entradas Mensuales

Síguenos en:

Canal Oficial Telegram de elhacker.NET Grupo Facebook elhacker.NET Twitter elhacker.NET Canal Youtube elhacker.NET Comunidad Steam: Grupo elhacker.NET Mastodon

Entradas populares

PostHeaderIcon Storm-3168 borra recursos de Azure en ataque destructivo de 7 minutos


El grupo Storm-3168 llevó a cabo un ataque destructivo contra un entorno de Azure en tan solo siete minutos, utilizando identidades de nube comprometidas. Esta operación demuestra cómo el robo de credenciales de una aplicación puede otorgar a un intruso un control total sobre los datos, los servicios y las protecciones de recuperación, evidenciando la creciente amenaza de los ataques automatizados en la nube. Esta actividad ha sido vinculada al agente JADEPUFFER.



Storm-3168 utilizó identidades de nube comprometidas para llevar a cabo un ataque destructivo contra un entorno de Azure en cuestión de minutos. La operación muestra cómo una credencial de aplicación robada puede darle a un intruso un control amplio sobre los datos alojados, los servicios y las protecciones de recuperación.

También resalta la creciente amenaza de los ataques automatizados a la nube. La actividad está vinculada a las operaciones de ransomware agente JADEPUFFER, documentadas anteriormente en una intrusión diferente.

Los investigadores encontraron dos principales de servicio comprometidos dentro de un mismo inquilino (tenant), donde uno mapeaba el entorno y el otro destruía recursos y recopilaba claves de almacenamiento.

Microsoft rastrea al actor como Storm-3168. Los investigadores no determinaron que la IA controlara directamente estas operaciones de Azure. Los analistas de Microsoft identificaron la actividad de Azure.

Microsoft indicó en un informe que la campaña tuvo como objetivo cuentas de almacenamiento de Azure, bases de datos SQL, Key Vaults, Function Apps, App Services y controles de recuperación.

La investigación no confirmó ninguna nota de rescate ni el robo exitoso de datos, pero la combinación apunta a un objetivo probablemente centrado en la extorsión.

El caso subraya un problema de seguridad en la nube que comienza mucho antes de que se emita un comando de eliminación. El ID de cliente, el secreto y el ID del inquilino de un principal de servicio habían aparecido en texto plano en un problema público de GitHub, aunque los investigadores no pudieron verificar que se utilizara este secreto. Eliminar un secreto de una publicación no lo revoca ni borra su historial.

Storm-3168 elimina recursos de Azure

A principios de junio de 2026, la primera identidad comprometida pasó unas 15 horas y 30 minutos realizando más de 300 operaciones de lectura exitosas.

Listó máquinas virtuales, suscripciones, grupos de recursos y otros activos. Unos 90 minutos después, la segunda identidad revisó máquinas virtuales y grupos en dos suscripciones en solo cinco segundos.

Ese segundo principal de servicio examinó posteriormente los almacenes de configuración de App Service, posiblemente buscando credenciales expuestas, e intentó consultar sin éxito recursos de Azure OpenSearch.

Setenta segundos después de su última acción de inventario, intentó recuperar una clave de una cuenta de almacenamiento que no existía. Menos de un segundo después, comenzó la secuencia destructiva.

Durante aproximadamente siete minutos, Storm-3168 realizó más de 100 intentos de eliminar cuentas de almacenamiento, y la mayoría de las cuentas objetivo fueron eliminadas con éxito.

Timeline (Source - Microsoft)
Línea de tiempo (Fuente – Microsoft)

También eliminó un Key Vault, una Function App y un plan de App Service vinculados al mismo grupo de recursos. Los bloqueos de recursos y la protección contra eliminación a nivel de cuenta detuvieron varios intentos, lo que demuestra que las salvaguardas independientes pueden limitar el daño.

El intruso también intentó eliminar varias bases de datos Azure SQL en paralelo, pero todos los intentos fallaron porque utilizó una versión de API no compatible.

Por separado, atacó los bloqueos de protección de Site Recovery y Azure Backup. Informes anteriores sobre fallos en los roles de la API de Azure muestran por qué los roles de nube con nombres restringidos aún requieren revisiones cuidadosas de permisos.

Las identidades robadas aumentan los riesgos de recuperación

Alrededor de 30 minutos después de las últimas acciones destructivas, la misma identidad envió más de 30 solicitudes exitosas de ListKeys para cuentas de almacenamiento de Azure, incluidas cuentas relacionadas con Site Recovery.

Las claves de acceso pueden exponer datos sensibles y crear una vía para una recopilación posterior. La secuencia también tuvo como objetivo cuentas de almacenamiento con nombres relacionados con terraform y respaldos (backup), aumentando el riesgo de una recuperación deteriorada.

El tiempo y el uso de múltiples identidades sugieren una automatización coordinada. Microsoft observó cinco tokens distintos para el principal de servicio utilizado en la eliminación y recopilación de claves; cuatro admitían la eliminación, mientras que uno se encargaba del inventario de almacenamiento y la recuperación de claves.

Dos tokens de eliminación estuvieron activos durante la misma ventana de 70 segundos, distribuyendo las operaciones entre objetivos de almacenamiento y SQL.

Las organizaciones deben revocar y rotar rápidamente cada credencial expuesta públicamente y luego investigar su uso previo. Debes mantener los secretos fuera del código fuente, tickets, repositorios y archivos de configuración, aplicando el principio de privilegio mínimo a las identidades de carga de trabajo.

Un informe separado sobre la exposición de credenciales de Azure Arc demuestra cómo los secretos de despliegue accesibles pueden convertirse en puntos de entrada poderosos.

Tú, como administrador, deberías restringir el acceso a los respaldos y controles de recuperación, monitorear los intentos de cambiar o eliminar protecciones y revisar regularmente los permisos de identidad.

Los equipos de seguridad también deben buscar descubrimientos de recursos inesperados, recuperación de claves en alto volumen y actividad de eliminación inusual. Los informes relacionados sobre los riesgos de acceso a Key Vault ilustran la importancia de rastrear el uso de credenciales riesgosas en todo el inquilino.


Fuentes:
https://cybersecuritynews.com/storm-3168/

0 comments :

Post a Comment

Los comentarios pueden ser revisados en cualquier momento por los moderadores.

Serán publicados aquellos que cumplan las siguientes condiciones:
- Comentario acorde al contenido del post.
- Prohibido mensajes de tipo SPAM.
- Evite incluir links innecesarios en su comentario.
- Contenidos ofensivos, amenazas e insultos no serán permitidos.

Debe saber que los comentarios de los lectores no reflejan necesariamente la opinión del STAFF.