Microsoft vincula al grupo Storm-3168 con un ataque destructivo que utilizó identidades de aplicaciones comprometidas para eliminar cuentas de almacenamiento y otros servicios en la nube. La investigación apunta a una operación compatible con tácticas de extorsión, aunque no confirma robo de datos ni una petición de rescate.
Un ataque contra un entorno de Microsoft Azure ha dejado al descubierto el daño que puede causar una identidad digital comprometida cuando dispone de permisos elevados. En apenas siete minutos, los atacantes intentaron eliminar más de 100 cuentas de almacenamiento. La mayoría de las que fueron objetivo de la operación acabaron borradas.
Microsoft atribuye la actividad al grupo que identifica como Storm-3168, vinculado a JADEPUFFER, un actor de amenazas que ya había sido investigado por su utilización de inteligencia artificial en operaciones de extorsión informática.
El incidente ocurrió a comienzos de junio de 2026, pero sus detalles han sido divulgados ahora por el equipo de investigación de seguridad de Microsoft. Durante aproximadamente 18 horas, los atacantes exploraron el entorno afectado, localizaron recursos y terminaron ejecutando una secuencia de acciones destructivas.
La investigación contiene una advertencia para empresas y administraciones que dependen de servicios en la nube: no hace falta comprometer la contraseña personal de un empleado para causar un daño grave. También pueden resultar decisivas las credenciales utilizadas por aplicaciones y procesos automatizados.
Dos identidades comprometidas para explorar y destruir
Microsoft observó la utilización de dos identidades de aplicación, conocidas técnicamente como service principals, pertenecientes al mismo entorno de Azure.
Estas identidades permiten que programas y servicios se autentiquen y realicen tareas sin necesidad de que una persona inicie sesión cada vez. Su funcionamiento es habitual en infraestructuras empresariales.
En este caso, los investigadores detectaron que una de las identidades se utilizó principalmente para reconocer el entorno, mientras que la segunda participó en la recopilación de información y en las operaciones destructivas.
La primera realizó más de 300 consultas de lectura durante unas 15 horas y media. Su actividad permitió identificar máquinas virtuales, suscripciones y grupos de recursos.
La segunda también consultó información del entorno y, más adelante, fue utilizada para lanzar numerosas solicitudes contra distintos servicios.
Esta división del trabajo permitió que los atacantes conocieran la infraestructura antes de actuar sobre ella. Microsoft considera que la coordinación y los tiempos de las operaciones apuntan a una ejecución automatizada o mediante scripts.
Siete minutos bastaron para borrar la mayoría de las cuentas atacadas
Después de la fase de reconocimiento, la actividad cambió bruscamente.
Microsoft contabilizó más de 150 operaciones relacionadas con destrucción de recursos o recopilación de credenciales en 35 minutos. Dentro de ese intervalo, la secuencia destructiva principal se concentró en unos siete minutos.
Los atacantes intentaron eliminar más de 100 cuentas de Azure Storage. Según Microsoft, la mayoría de las cuentas a las que se dirigieron las solicitudes fueron efectivamente eliminadas.
Azure Storage se utiliza para alojar distintos tipos de información empresarial. La pérdida de una cuenta puede afectar a aplicaciones y procesos que dependen de ella.
El informe no publica un balance económico del incidente ni detalla cuántos archivos concretos resultaron inaccesibles. Tampoco identifica a la organización perjudicada.
Por tanto, la cifra de cuentas eliminadas no debe confundirse con una cantidad confirmada de datos perdidos de manera irrecuperable.
También atacaron bases de datos y servicios de aplicaciones
La operación no se limitó al almacenamiento.
Los investigadores observaron acciones dirigidas contra Azure Key Vault, Function Apps, App Services y bases de datos Azure SQL, además de mecanismos vinculados a la recuperación de sistemas.
Entre los recursos que sí fueron eliminados figuraban un almacén de claves, una aplicación de funciones y un plan de servicio de aplicaciones relacionados entre sí.
Los atacantes también intentaron borrar varias bases de datos Azure SQL.
En este punto, el resultado fue diferente: todos los intentos de eliminación de esas bases de datos fracasaron porque las solicitudes empleaban una versión de la interfaz de programación que no era compatible con ese tipo de recurso.
El fallo de esas operaciones evitó que la secuencia observada tuviera un alcance destructivo mayor sobre las bases de datos.
No significa, sin embargo, que estas quedaran protegidas gracias a una estrategia deliberada de defensa. Según Microsoft, las solicitudes fallaron por una incompatibilidad técnica.
Las protecciones independientes evitaron parte del borrado
No todas las solicitudes destructivas tuvieron éxito.
Microsoft comprobó que determinados recursos resistieron los intentos de eliminación gracias a bloqueos de Azure y mecanismos específicos de protección contra el borrado.
Estas medidas impidieron suprimir algunas cuentas de almacenamiento incluso cuando la identidad comprometida disponía de permisos administrativos amplios.
El resultado pone de manifiesto una diferencia importante: tener autorización para administrar recursos no siempre equivale a poder eliminar todas sus protecciones.
Los atacantes también trataron de actuar sobre mecanismos relacionados con Azure Backup y Azure Site Recovery, dos servicios vinculados a la protección y recuperación de información.
Microsoft interpreta estos movimientos como un posible intento de dificultar la restauración del entorno después del ataque.
La investigación no confirma que los delincuentes consiguieran desactivar todos los mecanismos de recuperación. Sí documenta intentos de interferir en ellos.
El posible origen del ataque: unas credenciales expuestas en GitHub
Uno de los hallazgos más relevantes de la investigación está relacionado con la gestión de las credenciales.
Microsoft detectó que el identificador de una aplicación, su clave secreta y el identificador del entorno de Azure habían sido publicados previamente en texto legible dentro de una incidencia pública de GitHub.
La información había sido compartida por un empleado de la organización afectada.
Posteriormente, la incidencia se editó para retirar la clave secreta. Sin embargo, el dato continuó accesible en el historial público de modificaciones.
Microsoft no ha podido confirmar que esa exposición fuera la vía concreta utilizada por los atacantes para comprometer la identidad.
La coincidencia resulta relevante, pero no constituye una prueba definitiva del mecanismo inicial de acceso.
El episodio permite ilustrar, no obstante, un problema conocido en la seguridad de las aplicaciones: borrar una credencial de una publicación no impide que siga funcionando.
Si una clave ha quedado expuesta, la medida de protección consiste en revocarla o sustituirla, además de investigar si fue utilizada mientras estuvo disponible.
Qué es un service principal y por qué resulta tan sensible
Un service principal es una identidad digital que permite a una aplicación actuar dentro de un entorno de Microsoft Azure.
Por ejemplo, una herramienta empresarial puede necesitar consultar determinados recursos o automatizar tareas de mantenimiento. En lugar de utilizar la cuenta personal de un empleado, funciona mediante una identidad específica con permisos definidos.
El problema aparece cuando esa identidad tiene más privilegios de los que necesita o cuando sus credenciales quedan al alcance de terceros.
En la operación investigada, Microsoft determinó que los atacantes actuaron aprovechando permisos que ya estaban asignados a las identidades comprometidas.
No fue necesario que todas las solicitudes eludieran los controles de autorización de Azure: parte de las acciones destructivas estaban permitidas para aquellas identidades.
Este detalle explica por qué las cuentas técnicas merecen tanta atención como las cuentas humanas.
Una credencial de aplicación puede convertirse en una vía de acceso a recursos críticos si no está protegida y limitada adecuadamente.
Después del borrado, los atacantes buscaron claves de acceso
La investigación detectó una segunda fase relevante después de las acciones destructivas.
Aproximadamente 30 minutos después de la última operación de borrado, la identidad comprometida consultó de nuevo los recursos de almacenamiento y realizó más de 30 solicitudes exitosas para obtener claves de acceso.
Estas claves pueden permitir que una aplicación autorizada acceda a determinados recursos de almacenamiento.
Microsoft considera que la actividad podría haber facilitado nuevas acciones sobre datos sensibles.
Sin embargo, no observó una extracción de información confirmada durante el incidente investigado.
Es una distinción esencial: obtener credenciales que podrían servir para acceder a datos no demuestra que esos datos fueran efectivamente descargados o enviados a los atacantes.
La empresa tampoco identificó una nota de rescate vinculada a esta intrusión.
Microsoft vincula la operación con tácticas de ransomware
La destrucción de recursos y los intentos de interferir en mecanismos de recuperación llevaron a Microsoft a considerar que la operación encaja con tácticas utilizadas en ataques de ransomware y extorsión.
El ransomware suele asociarse al cifrado de archivos seguido de una exigencia económica para recuperarlos. Sin embargo, algunas operaciones de extorsión también recurren al borrado, al robo de información o a la amenaza de interrumpir servicios.
En el incidente de Azure, Microsoft documentó destrucción de recursos y recopilación de credenciales.
No confirmó una petición de rescate ni una exfiltración exitosa de datos.
Por ello, la investigación respalda hablar de una actividad destructiva compatible con objetivos de extorsión, pero no de un secuestro de información completamente acreditado en este caso.
La finalidad exacta de los atacantes continúa siendo una valoración de los investigadores basada en sus acciones.
JADEPUFFER ya había sido relacionado con ataques mediante IA
El nombre JADEPUFFER comenzó a aparecer en investigaciones públicas durante julio de 2026.
La empresa de seguridad Sysdig documentó entonces una operación contra una infraestructura que utilizaba Langflow, una herramienta empleada para desarrollar aplicaciones basadas en modelos de inteligencia artificial.
Los investigadores consideraron que el atacante había utilizado un agente basado en un gran modelo de lenguaje para encadenar tareas de reconocimiento, recopilación de credenciales y actuaciones contra una base de datos.
Sysdig presentó aquel caso como la primera operación de extorsión mediante ransomware documentada que, según su evaluación, había sido ejecutada de principio a fin con ayuda de un agente de IA.
Esa caracterización procede de Sysdig y se refiere al incidente que investigó.
En la actividad posterior de Azure, Microsoft observó una coordinación intensa entre identidades comprometidas y un elevado volumen de operaciones. El informe atribuye la campaña al mismo actor, pero no demuestra por sí solo que cada una de las acciones realizadas en Azure fuese decidida autónomamente por un modelo de IA.
ENCFORGE, la evolución del grupo hacia infraestructuras de inteligencia artificial
Tras el primer incidente de Langflow, Sysdig investigó una segunda actuación contra la misma instalación.
En ella identificó ENCFORGE, una herramienta de ransomware desarrollada para atacar recursos utilizados en proyectos de inteligencia artificial y aprendizaje automático.
Según los investigadores, el programa estaba preparado para reconocer cerca de 180 extensiones de archivo.
Entre sus posibles objetivos figuraban modelos, conjuntos de datos de entrenamiento, bases de datos vectoriales e índices empleados en aplicaciones de IA.
La relevancia de esta evolución radica en el tipo de activos afectados.
Para una empresa que desarrolla sistemas de inteligencia artificial, perder modelos entrenados o conjuntos de datos puede perjudicar procesos de investigación y servicios que dependen de ellos.
No obstante, la existencia de ENCFORGE en aquella investigación no significa que Microsoft haya confirmado su utilización en el ataque de Azure descrito ahora.
Son episodios vinculados al mismo actor según los investigadores, pero con características técnicas y evidencias diferentes.
Los ataques automatizados pueden concentrar el daño en pocos minutos
El caso muestra la importancia de la velocidad de ejecución.
Los atacantes dedicaron horas a conocer el entorno. Después, una parte considerable de las acciones destructivas se concentró en siete minutos.
Esta combinación dificulta la respuesta cuando una organización únicamente detecta los problemas después de que empiecen a fallar sus servicios.
La automatización también permite que distintas acciones se ejecuten con una coordinación temporal muy estrecha.
Microsoft observó que las identidades comprometidas realizaron consultas y operaciones simultáneas o muy próximas entre sí.
La empresa considera que este patrón refleja un uso de automatización, aunque el ritmo de ejecución no basta, por sí solo, para demostrar que una inteligencia artificial tomó todas las decisiones.
Lo que sí confirma es que los mecanismos de protección deben funcionar incluso cuando las operaciones maliciosas se suceden con rapidez.
La investigación detectó actividad contra otros clientes de Azure
Microsoft ha identificado también intentos reiterados de sondeo de aplicaciones alojadas en Azure que estaban relacionados con infraestructura atribuida a Storm-3168.
La actividad afectó a servicios de distintos clientes.
Sin embargo, la empresa distingue estos sondeos del incidente destructivo: no comprobó que las aplicaciones examinadas pertenecieran al mismo entorno comprometido.
Tampoco encontró una relación de acceso que demostrase que esos intentos fueran la vía utilizada para obtener los permisos empleados en la destrucción de recursos.
Este matiz evita presentar como víctimas confirmadas a todas las organizaciones cuyos servicios recibieron solicitudes sospechosas.
Un intento de identificar una debilidad no equivale necesariamente a una intrusión exitosa.
Cómo pueden protegerse las empresas que utilizan Microsoft Azure
El informe de Microsoft deja varias recomendaciones dirigidas a administradores de sistemas y responsables de seguridad.
La prioridad es proteger las identidades utilizadas por aplicaciones y procesos automatizados. Estas cuentas deben disponer únicamente de los permisos necesarios para su función.
También resulta esencial controlar dónde se almacenan sus credenciales. Las claves y secretos no deberían aparecer en repositorios públicos, archivos compartidos sin protección o incidencias accesibles desde internet.
Si una credencial queda expuesta, eliminar el texto publicado no basta: debe revocarse o sustituirse.
Microsoft aconseja, además, proteger de forma independiente los recursos destinados a la recuperación, para que una identidad comprometida no pueda eliminar fácilmente tanto los sistemas de producción como sus mecanismos de respaldo.
La supervisión de operaciones inusuales —especialmente las relacionadas con eliminación de recursos y acceso a claves— puede ayudar a detectar actividad sospechosa.
Las copias de seguridad deben resistir una cuenta comprometida
Una de las conclusiones más importantes del ataque es que los mecanismos de recuperación también fueron objetivos de los atacantes.
Esta circunstancia obliga a revisar cómo se protegen las copias de seguridad y los recursos que permiten restaurar los servicios.
No basta con disponer de respaldos si las mismas credenciales comprometidas pueden eliminarlos o alterar sus protecciones.
Las organizaciones necesitan separar las autorizaciones y limitar el acceso a los componentes de recuperación.
En el incidente investigado, ciertos bloqueos de Azure consiguieron impedir parte de los borrados. Microsoft presenta ese resultado como una demostración de la utilidad de las salvaguardas independientes.
La capacidad de recuperación debe mantenerse incluso cuando una identidad con permisos amplios resulta comprometida.
Un problema que también afecta a las empresas españolas
Las conclusiones del informe son relevantes para cualquier organización que utilice servicios en la nube, incluidas las empresas españolas.
Microsoft no ha identificado públicamente a la víctima principal ni ha comunicado que la operación destructiva descrita tuviera lugar en España.
Por tanto, no existe base para atribuir este incidente a una empresa o administración española concreta.
Sin embargo, los riesgos descritos no dependen del país: credenciales expuestas, permisos excesivos y recursos de recuperación insuficientemente protegidos pueden aparecer en entornos empresariales de distintas jurisdicciones.
El caso invita a revisar una práctica habitual en los proyectos digitales: otorgar permisos amplios a una aplicación para facilitar su puesta en marcha y mantenerlos después sin comprobar si siguen siendo necesarios.
La comodidad inicial puede aumentar la exposición si esas credenciales terminan comprometidas.
Qué está demostrado y qué continúa sin aclararse
La investigación de Microsoft permite establecer varios hechos relevantes.
Está documentado que dos identidades de aplicación comprometidas participaron en la actividad detectada. También se observaron más de 300 consultas durante el reconocimiento inicial y más de 100 intentos de eliminación de cuentas de almacenamiento durante la secuencia destructiva.
Microsoft confirmó que la mayoría de las cuentas de almacenamiento atacadas fueron eliminadas, mientras algunas resistieron gracias a mecanismos de protección. Los intentos de borrar las bases de datos Azure SQL fracasaron.
También se sabe que las credenciales de una identidad habían aparecido anteriormente en una incidencia pública de GitHub.
No está confirmado que esa publicación fuera la vía utilizada para iniciar el ataque. Tampoco se ha acreditado una extracción exitosa de datos ni se ha encontrado una nota de rescate relacionada con el episodio.
La atribución a JADEPUFFER procede de la investigación de Microsoft y de su relación con actividades previamente documentadas por Sysdig.
La nueva amenaza para la nube está en los permisos que ya existen
El ataque vinculado a JADEPUFFER muestra una forma de comprometer infraestructuras que no requiere aprovechar una vulnerabilidad desconocida en cada servicio.
Los atacantes utilizaron identidades con permisos existentes para explorar el entorno y solicitar operaciones de borrado. Allí donde los permisos y las protecciones lo permitieron, parte de los recursos desapareció.
La investigación también muestra que ciertos controles funcionaron: algunos bloqueos impidieron eliminaciones y las solicitudes contra las bases de datos fallaron.
El resultado no permite afirmar que todos los entornos de Microsoft Azure estén expuestos de la misma manera. Sí demuestra que una identidad técnica mal protegida puede concentrar un riesgo considerable cuando administra recursos críticos.
Con la automatización, ese riesgo adquiere una dimensión temporal adicional. Una vez completado el reconocimiento, los atacantes pueden intentar causar daños en un intervalo muy reducido.
La lección del incidente es concreta: proteger las claves de las aplicaciones, limitar sus permisos y separar los mecanismos de recuperación puede marcar la diferencia entre un intento destructivo y la pérdida efectiva de servicios.
Toqueteo
Toqueteo
Toqueteo