JadePuffer destruye recursos de Azure en siete minutos mediante ataques de proxy

Resumen del incidente

En junio de 2026, el equipo de seguridad de Microsoft publicó en su blog oficial, Microsoft Security Blog, un informe detallado que describía dos incidentes diferentes en los que se había utilizado una identidad de servicio previamente comprometida para atacar recursos alojados en la plataforma Azure. Los atacantes fueron identificados internamente con el nombre en código JadePuffer, y la investigación interna asignó a estos eventos el identificador Storm‑3168. Cada uno de los incidentes tuvo lugar en un inquilino (tenant) distinto, lo que indica que el adversario había logrado obtener credenciales de servicio válidas y, a continuación, había actuado como un agente proxy para ejecutar una gran cantidad de operaciones de lectura, escritura y destrucción contra los recursos en la nube.

Métodos de ataque y cronología

En el primer incidente, la identidad de servicio comprometida permaneció activa durante aproximadamente quince horas y treinta minutos, período durante el cual el atacante llevó a cabo una fase de reconocimiento continuo que incluyó más de trescientas lecturas de datos y consultas a la infraestructura. En contraste, el segundo incidente mostró una velocidad mucho mayor: en apenas treinta y cinco minutos, el actor malintencionado lanzó más de ciento cincuenta acciones dirigidas a la destrucción o a la recolección de credenciales, y la fase central de destrucción se concentró en un intervalo de alrededor de siete minutos, tiempo durante el cual se intentó eliminar más de cien cuentas de almacenamiento.

Durante esos siete minutos críticos, el atacante primero enumeró los recursos objetivo mediante llamadas a la API que listan los activos disponibles. A continuación, ejecutó llamadas al endpoint Delete de la API con la intención de borrar cuentas de almacenamiento y otros servicios asociados. Aunque una parte significativa de los recursos había sido previamente protegida mediante bloqueos de recursos o mecanismos de protección contra eliminación, lo que impidió que muchas de las solicitudes de borrado se completaran, el número total de intentos enviados fue muy elevado. Este comportamiento evidencia que los scripts automatizados del atacante estaban diseñados para generar un alto volumen de llamadas en un corto lapso, maximizando la probabilidad de éxito antes de que las defensas pudieran reaccionar.

• Más de 100 intentos de eliminación de cuentas de almacenamiento
• Más de 150 acciones de destrucción o recolección de credenciales
• Más de 300 solicitudes de lectura durante el primer incidente
• Más de 30 llamadas a ListKeys aproximadamente treinta minutos después

Evidencia y fuentes

Microsoft clasificó este tipo de actividad bajo la etiqueta Storm‑3168 y señaló que los atacantes aprovecharon las credenciales de la identidad de servicio obtenidas para ejecutar operaciones en modo proxy, es decir, actuando como si fueran la propia entidad legítima. Un informe adicional de iThome mencionó que algunas de las credenciales comprometidas habían aparecido previamente en un issue público de GitHub, aunque Microsoft no confirmó que esas credenciales específicas fueran la fuente directa de la intrusión.

Durante la investigación, el equipo de seguridad de Microsoft no detectó ninguna comunicación de rescate ni evidencias claras de exfiltración de datos confidenciales. La única actividad posterior observada fue que, aproximadamente treinta minutos después de la fase de destrucción inicial, el atacante realizó más de treinta solicitudes al endpoint ListKeys, lo que indica un intento continuo de obtener más información de claves y secretos asociados a los recursos comprometidos.

Impacto y efectividad de la defensa

Los mecanismos de bloqueo de recursos (resource lock) y de protección contra eliminación (delete protection) jugaron un papel crucial en la mitigación del daño durante este ataque, ya que impidieron que la mayoría de las cuentas de almacenamiento fueran borradas de forma irreversible. Además, los intentos de eliminación dirigidos a bases de datos Azure SQL fallaron porque la versión de la API utilizada por el atacante no era compatible con la operación de borrado, lo que redujo aún más el potencial de pérdida.

A pesar de que estas defensas lograron bloquear una parte importante de la actividad destructiva, el atacante logró enumerar los recursos y extraer claves, lo que demuestra que el bloqueo de recursos por sí solo no es suficiente para prevenir completamente un ataque basado en un agente proxy. Microsoft recomendó a los inquilinos afectados que revisaran de inmediato el uso de todas las credenciales de identidades de servicio, activaran el acceso condicional y aplicaran el principio de privilegios mínimos para limitar el alcance de cualquier posible compromiso futuro.

De cara al futuro, Microsoft anunció que incorporará alertas en tiempo real dentro del servicio de monitorización de Azure para detectar comportamientos anómalos de identidades de servicio, y que reforzará las comprobaciones de compatibilidad de versiones de API con el objetivo de reducir la superficie de ataque que se basa en el uso de versiones obsoletas. Asimismo, las organizaciones son instadas a rotar periódicamente las claves de sus identidades de servicio y a aplicar políticas de protección contra eliminación más estrictas a los recursos considerados críticos o sensibles.