Las identidades de aplicaciones de Azure robadas permitieron a JadePuffer convertir el acceso a la nube en destrucción

Microsoft atribuyó a JadePuffer una actividad destructiva en tenants de Azure. La empresa sigue a este actor como Storm-3168. En un incidente descrito en detalle, el atacante tomó el control de dos service principals y los utilizó para descubrir recursos, obtener credenciales, eliminar servicios en la nube e interferir con las medidas de protección de recuperación.

Microsoft publicó su informe el 25 de septiembre de 2026 y describió una actividad ocurrida a principios de junio. Otros informes señalan que Microsoft observó dos ataques en junio, aunque el relato detallado documenta principalmente una de las secuencias.

La operación causó daños considerables sin explotar ninguna vulnerabilidad de software divulgada. En su lugar, JadePuffer actuó mediante identidades de aplicaciones comprometidas, cuyos permisos permitían realizar operaciones que podían parecer tareas legítimas de administración de la nube.

Dos service principals se repartieron las tareas del ataque

Los service principals de Azure son identidades de aplicaciones que utilizan el software y los procesos automatizados para autenticarse y acceder a recursos. Se les pueden asignar permisos de control de acceso basado en roles de Azure sin necesidad de una cuenta de usuario interactiva.

JadePuffer comprometió dos de estas identidades en el mismo tenant. Una se utilizó principalmente para mapear el entorno durante unas 15,5 horas y completó más de 300 operaciones de lectura satisfactorias en máquinas virtuales, suscripciones, grupos de recursos y otros activos de Azure.

La segunda identidad actuó mucho más rápido. Unos 90 minutos después del inicio del reconocimiento general, enumeró máquinas virtuales y grupos de recursos en dos suscripciones en solo cinco segundos.

Esta división apunta a un flujo de trabajo organizado: una identidad elaboró un inventario amplio, mientras que la otra realizó tareas de reconocimiento más concretas y acciones destructivas. Sin embargo, las pruebas disponibles no permiten determinar si esta división se controló mediante IA, automatización convencional o instrucciones directas de un operador.

Los investigadores de Microsoft Yossi Weizman y Tushar Mudi señalaron que un reconocimiento de este nivel podría dar al atacante visibilidad sobre todo el entorno de Azure de la víctima. La operación no se limitó a identificar cargas de trabajo individuales.

El segundo service principal también consultó los almacenes de configuración de Azure App Service, posiblemente para buscar credenciales incrustadas en la configuración de las aplicaciones. También buscó sin éxito recursos de Azure OpenSearch e intentó ejecutar una operación ListKey en una cuenta de almacenamiento que no existía.

Menos de un segundo después de esa solicitud fallida, comenzaron las eliminaciones.

Las cuentas de almacenamiento y los servicios auxiliares se eliminaron en cuestión de minutos

El atacante realizó más de 100 intentos de eliminar cuentas de Azure Storage y la mayoría se completó correctamente. También eliminó un Azure Key Vault, una Function App y un plan de App Service del mismo grupo de recursos.

Según la información publicada sobre los ataques observados en Azure, la fase destructiva duró aproximadamente siete minutos y tuvo como objetivo máquinas virtuales y App Services, además de cuentas de almacenamiento, Key Vaults y Function Apps. La descripción más detallada de Microsoft recoge el reconocimiento de máquinas virtuales, pero no informa de que se confirmara su eliminación.

JadePuffer también intentó eliminar varias bases de datos de Azure SQL. Los intentos fracasaron porque el actor proporcionó una versión de API no compatible. Esto demuestra que incluso una secuencia rápida y automatizada puede fallar si las solicitudes no se ajustan al servicio atacado.

Después, la operación volvió a centrarse en el almacenamiento. Unos 30 minutos después de la fase de eliminación, el service principal comprometido solicitó un inventario de las cuentas de Azure Storage, incluidas las asociadas a Azure Site Recovery.

A continuación, completó más de 30 solicitudes ListKeys satisfactorias y obtuvo claves de acceso al almacenamiento. Según la configuración de las cuentas, estas claves pueden proporcionar acceso directo a ellas, al margen de los permisos originales del service principal en Azure RBAC.

El atacante también intentó debilitar las medidas de copia de seguridad y recuperación. No logró eliminar los bloqueos de Azure Site Recovery, y los bloqueos de recursos y las protecciones aplicadas a las cuentas de almacenamiento impidieron que se eliminaran algunas de las cuentas atacadas.

Estas medidas marcaron una diferencia tangible. No detuvieron la operación, pero limitaron su alcance.

Un secreto de GitHub podría explicar el acceso, pero la atribución sigue sin estar clara

Microsoft no pudo determinar exactamente cómo se comprometieron los dos service principals. Sin embargo, sí detectó una posible exposición importante relacionada con una de las identidades.

Un empleado de la organización afectada había publicado en texto sin cifrar el ID de cliente, el secreto de cliente y el ID del tenant del service principal en una incidencia pública de GitHub. Más tarde, editó la incidencia para eliminar el secreto, pero el valor original seguía disponible en el historial público de ediciones.

Microsoft no pudo confirmar que JadePuffer obtuviera o utilizara esa credencial expuesta. Por tanto, el hallazgo apunta a una posible vía de acceso, pero no demuestra que fuera el vector inicial.

La diferencia es importante: eliminar un secreto de la versión actual de una publicación no invalida las copias, el contenido almacenado en caché, el historial del repositorio ni los registros de ediciones de la plataforma. Una vez que una credencial se publica en un sistema público, los defensores deben considerarla comprometida y rotarla, en lugar de confiar en que basta con eliminar el contenido.

Como señaló Ross Filipek, CISO de Corsica Technologies, las operaciones realizadas mediante una identidad de aplicación también pueden parecer tareas normales de administración de la nube. Esto puede dificultar su detección si la supervisión se centra en los inicios de sesión fallidos o en sesiones humanas sospechosas, en lugar de buscar comportamientos inusuales en las API de las identidades de cargas de trabajo.

Desde principios de año, Microsoft también ha observado infraestructura vinculada a JadePuffer sondeando Azure App Services de varios clientes. Entre las rutas probadas figuraban rutas de administración de WordPress, PHP-CGI, el endpoint de validación de código de LangFlow en /api/v1/validate/code y rutas similares a las ubicaciones de web shells.

No se sabe si esos sondeos condujeron al compromiso descrito en este informe.

El patrón de ransomware está claro, pero la participación de la IA no tanto

Microsoft describió la actividad como coherente con tácticas de ransomware o extorsión. La eliminación de recursos de producción, los intentos de obtener claves de almacenamiento y los esfuerzos por interferir con la recuperación encajan con una estrategia de presión destructiva.

Sin embargo, los investigadores no encontraron ninguna nota de rescate, no confirmaron ninguna exigencia económica y no pudieron demostrar que se hubiera exfiltrado información. Por tanto, calificar el incidente como ransomware describe el patrón operativo aparente, no una extorsión consumada y verificada.

En julio, Sysdig identificó a JadePuffer como la primera operación de ransomware documentada impulsada por un modelo de lenguaje grande, según la cobertura de los hallazgos de Microsoft y de la actividad anterior del actor. Su análisis describía agentes de IA que automatizaban distintas etapas, como el reconocimiento, el robo de credenciales, el movimiento lateral, la persistencia y el cifrado.

Según se informó, JadePuffer amplió más tarde sus objetivos para incluir activos de IA, conjuntos de datos de entrenamiento y bases de datos vectoriales, y utilizó una herramienta llamada EncForge.

El incidente de Azure sí demuestra un alto grado de automatización coordinada. Por sí solo, no demuestra que un agente de IA eligiera o dirigiera cada llamada a la API.

Nick Tausek, arquitecto principal de automatización de seguridad en Swimlane, hizo esta distinción y coincidió con la advertencia general de Microsoft: la IA agéntica podría permitir a los atacantes ejecutar operaciones más rápido y en más recursos, pero una coordinación veloz no demuestra que la IA controlara toda la secuencia.

Para los defensores, el riesgo práctico es similar en ambos casos. Las identidades de la nube pueden ejecutar cientos de solicitudes de reconocimiento y eliminación mucho más rápido de lo que un equipo de respuesta humano puede revisarlas manualmente.

Los defensores deben rotar las credenciales expuestas y limitar los permisos de las identidades de aplicaciones

Las organizaciones que utilizan Azure deberían empezar por identificar los service principals con amplios permisos sobre el almacenamiento, los sistemas de recuperación, Key Vault, la configuración de aplicaciones y las operaciones de eliminación de recursos. Deben revisar las asignaciones de Azure RBAC para asegurarse de que respetan el principio de mínimo privilegio, sobre todo cuando una misma identidad puede actuar en varias suscripciones.

Microsoft recomienda las siguientes medidas:

• Habilitar los planes adecuados de Microsoft Defender for Cloud para las cargas de trabajo críticas de Azure.
• Evaluar de forma continua si las credenciales y los secretos de las aplicaciones han quedado expuestos.
• Rotar de inmediato cualquier credencial publicada o cuya seguridad se sospeche comprometida.
• Establecer controles para todo el ciclo de vida de los secretos: creación, almacenamiento, caducidad y revocación.
• Reducir los permisos de los service principals y las identidades de cargas de trabajo al mínimo necesario.
• Revisar repositorios, incidencias, comentarios e historiales de cambios públicos en busca de credenciales expuestas.

También conviene aplicar bloqueos de recursos y protecciones en las cuentas de almacenamiento cuando resulte adecuado desde el punto de vista operativo. En este incidente, esas medidas impidieron directamente algunos intentos de eliminación, incluidos los dirigidos contra recursos protegidos de almacenamiento y recuperación.

La supervisión debe tener en cuenta las secuencias de acciones, no solo los eventos aislados. Entre las señales de alerta figuran la enumeración rápida de todas las suscripciones, el acceso a los almacenes de configuración de App Service, un gran número de solicitudes ListKeys de almacenamiento y múltiples operaciones de eliminación realizadas por un service principal.

Microsoft mencionó Project Perception y MDASH como iniciativas destinadas a ayudar a los defensores a investigar incidentes y responder en entornos amplios mediante flujos de trabajo con apoyo de IA. Sea cual sea la tecnología empleada, el desafío inmediato está claro: las identidades de aplicaciones deben supervisarse como actores con privilegios, no tratarse como procesos en segundo plano de confianza.