Durante años, imaginar un ciberataque implicaba pensar en una persona frente a una computadora: alguien que obtenía una contraseña, exploraba una red, buscaba privilegios y decidía cuál sería el siguiente movimiento. Esa imagen sigue siendo válida para muchas intrusiones, pero empieza a quedarse corta frente a una nueva generación de amenazas capaces de automatizar buena parte del trabajo que antes requería intervención humana.
La transformación resulta especialmente relevante en la nube. Una vez que un atacante consigue controlar una identidad con permisos suficientes, ya no necesita necesariamente desplazarse de servidor en servidor como lo haría un operador humano. Puede utilizar las interfaces y APIs de la plataforma para consultar recursos, descubrir configuraciones, acceder a secretos o intentar eliminar componentes completos de una infraestructura. En otras palabras, la nube puede convertirse en un entorno que una máquina es capaz de explorar y manipular a gran velocidad.
El caso de Storm-3168, que es una designación de Microsoft Security Research para un grupo de amenazas (threat actor) asociado con JADEPUFFER, un operador de Sysdig descubierto en julio de 2026 y documentado en septiembre. Storm-3168 es una operación contra un entorno de Azure en la que dos service principals comprometidos fueron utilizados para realizar reconocimiento, acceder a credenciales y ejecutar una secuencia de acciones destructivas contra distintos recursos Cloud.
El episodio cobra todavía más importancia cuando se coloca junto a la investigación publicada en julio por Sysdig Threat Research. La compañía documentó a JADEPUFFER como lo que consideró el primer caso de ransomware agentic observado de extremo a extremo. Es decir, que un agente basado en un modelo de lenguaje que fue capaz de encadenar reconocimiento, explotación, movimiento lateral y destrucción de una base de datos con una intervención humana mínima.
Esto no significa que Storm-3168 deba describirse simplemente como “una IA que entró en Azure y borró todo”. Esa interpretación sería demasiado simplista. Lo que Microsoft documentó es una operación altamente automatizada y compatible con la evolución hacia ataques orquestados mediante agentes de IA.
La diferencia de la que se habla en el presente texto es importante: el riesgo no está únicamente en que una inteligencia artificial pueda atacar, sino en que una identidad comprometida tenga permiso para ejecutar acciones destructivas y que esas acciones puedan automatizarse a velocidad de máquina.
Storm-3168: ¿qué ocurrió en el ataque automatizado contra Azure?
Para entender lo sucedido conviene imaginar primero una empresa cuyo centro de operaciones no está concentrado en un edificio lleno de servidores, sino repartido dentro de una plataforma Cloud. Allí pueden convivir aplicaciones, bases de datos, máquinas virtuales, almacenamiento, certificados, contraseñas, claves de API y sistemas de respaldo. Microsoft Azure ofrece precisamente este tipo de servicios de computación y almacenamiento, por lo que una cuenta con privilegios suficientes puede tener acceso a una parte considerable de la infraestructura digital de una organización.
En el caso investigado por Microsoft, la operación comenzó con dos service principals comprometidos pertenecientes al mismo tenant. Un service principal puede entenderse, para un público no especializado, como una identidad digital que utiliza una aplicación o servicio para identificarse ante Azure y realizar determinadas acciones. No es un empleado que inicia sesión manualmente, es una identidad que permite que un proceso automatizado diga “soy esta aplicación y tengo autorización para hacer esto”.
El problema aparece cuando esa identidad cae en manos de un atacante. Si el service principal dispone de permisos administrativos, el atacante no necesariamente necesita crear una nueva cuenta con privilegios. Puede utilizar la identidad legítima y aprovechar las autorizaciones que ya posee. Microsoft advierte que las workload identities (entre ellas los service principals y otras identidades utilizadas por aplicaciones) pueden representar un riesgo significativo cuando reciben privilegios elevados.
La primera de las identidades comprometidas pasó aproximadamente 15 horas y 30 minutos realizando reconocimiento, con más de 300 operaciones de lectura exitosas destinadas a enumerar máquinas virtuales, suscripciones, grupos de recursos y otros componentes del entorno Azure. Es el equivalente digital de entrar en un edificio, encender las luces de cada habitación y elaborar un plano antes de decidir qué puertas abrir.
Pero la segunda identidad mostró una velocidad muy diferente. Microsoft observó que, unos 90 minutos después de que comenzara el reconocimiento de la primera, esa segunda cuenta fue capaz de enumerar máquinas virtuales y grupos de recursos pertenecientes a dos suscripciones en apenas cinco segundos. Más tarde, accedió a configuraciones de Azure App Service, posiblemente para localizar credenciales expuestas.
La secuencia alcanzó su punto crítico poco después. Microsoft registró más de 150 operaciones relacionadas con destrucción de recursos o recopilación de credenciales durante aproximadamente 35 minutos. Más de 100 intentos de eliminación de cuentas de almacenamiento se concentraron en una ventana de alrededor de siete minutos. La cifra permite visualizar el problema: lo que para una persona implicaría revisar y ejecutar numerosas acciones, para una identidad utilizada mediante automatización puede convertirse en una cadena de solicitudes ejecutadas en cuestión de minutos.
La actividad afectó o intentó afectar distintos componentes de Azure, entre ellos Storage Accounts, Key Vault, Function Apps, App Services, máquinas virtuales y bases de datos SQL. No todos los intentos tuvieron éxito. Microsoft señala, por ejemplo, que las operaciones contra determinadas bases de datos Azure SQL fallaron porque se utilizó una versión de API incompatible con ese recurso. También hubo eliminaciones bloqueadas por mecanismos de protección.
Ese detalle resulta especialmente importante porque muestra que un ataque automatizado no es necesariamente perfecto. Una automatización puede equivocarse, encontrar una barrera o utilizar una instrucción incompatible. La diferencia es que puede detectar el resultado y continuar rápidamente con otra acción. En el caso de JADEPUFFER analizado anteriormente por Sysdig, el agente llegó a diagnosticar un fallo de autenticación y produjo una corrección funcional en aproximadamente 31 segundos.
¿Cómo la IA convierte la nube en un objetivo programable?
Aquí aparece uno de los conceptos fundamentales para comprender el cambio: las APIs.
Una API, o Application Programming Interface, es un mecanismo que permite que diferentes programas se comuniquen y soliciten acciones a otros servicios. Para simplificarlo, puede imaginarse como el mostrador automático de una empresa, en lugar de que una persona entre al edificio y pida algo directamente a un empleado, un sistema envía una solicitud estructurada y recibe una respuesta. En las plataformas Cloud, muchas operaciones administrativas pueden ejecutarse mediante APIs.
Eso cambia considerablemente el escenario para un atacante automatizado. Si una identidad tiene autorización para eliminar un recurso, no necesariamente hace falta que alguien abra el portal de Azure, localice el recurso y pulse “eliminar”. Un proceso puede enviar la solicitud directamente a la plataforma. Y si ese proceso es capaz de encadenar instrucciones, analizar resultados y continuar con la siguiente acción, la infraestructura puede convertirse en un entorno altamente programable.
La investigación de Google Threat Intelligence apunta precisamente hacia esta evolución. En septiembre de 2026, Google informó que había observado adversarios pasar de usos más básicos de la IA a flujos de trabajo agentic y automatización habilitada por IA. Según el informe, en el segundo trimestre de 2026 se observó un caso en el que actores comprometieron un recurso Cloud y posteriormente planificaron, construyeron y ejecutaron una campaña automatizada de recolección masiva de credenciales en menos de seis horas.
La diferencia entre una herramienta automatizada tradicional y un agente es que este último puede incorporar un cierto grado de adaptación. Un script convencional puede recibir una orden como “ejecuta estas 20 acciones”. Un agente puede recibir un objetivo más amplio y decidir qué acciones realizar en función de los resultados que va obteniendo. Sysdig describió este comportamiento en JADEPUFFER mediante payloads que contenían razonamiento en lenguaje natural, priorización de objetivos y correcciones ante errores.
Por eso, hablar de una nube programable por un atacante no significa que toda la infraestructura se transforme literalmente en código, significa que los numerosos servicios que componen un entorno Cloud pueden ser controlados mediante identidades, permisos y APIs. Si esas piezas están conectadas y una identidad comprometida posee privilegios suficientes, una automatización puede convertir una intrusión inicial en una secuencia de acciones sobre múltiples servicios.
El verdadero riesgo podría describirse como: identidad comprometida + privilegios + automatización
La amenaza, entonces, no puede atribuirse exclusivamente a la inteligencia artificial. Hay una combinación mucho más concreta: una identidad comprometida, privilegios suficientes, capacidad de automatización y una infraestructura Cloud ampliamente interconectada. La IA puede acelerar o facilitar la coordinación, pero necesita un entorno sobre el cual actuar.
Pensemos en una aplicación empresarial que necesita leer información de una base de datos y guardar archivos en Azure Storage. Para funcionar correctamente, sus responsables le asignan permisos. Con el tiempo, quizá también obtiene permisos para modificar configuraciones, consultar secretos o administrar otros recursos. La aplicación sigue funcionando y nadie vuelve a revisar esos privilegios. Si un atacante consigue comprometer su identidad, lo que inicialmente era una autorización legítima puede convertirse en una vía para atacar la propia infraestructura.
Microsoft advierte precisamente de este riesgo. Una identidad de carga de trabajo privilegiada comprometida puede utilizarse para realizar reconocimiento, escalar privilegios, moverse entre recursos y manipular o exfiltrar información sensible. Además, estas identidades no siempre están sujetas a los mismos controles diseñados para usuarios humanos, lo que puede hacer que pasen inadvertidas durante más tiempo.
El problema aumenta cuando el atacante también busca los mecanismos de recuperación. Microsoft observó intentos de afectar bloqueos relacionados con Azure Site Recovery y Azure Backup, además de cuentas de almacenamiento vinculadas con recuperación. Aunque algunas de estas operaciones fueron bloqueadas, el comportamiento muestra por qué los respaldos se convierten en objetivos especialmente valiosos durante una operación destructiva.
No obstante, Microsoft señaló que en esta actividad concreta no observó una nota de rescate ni confirmó una exfiltración exitosa de datos. La investigación sí encontró destrucción de recursos, intentos de obtener credenciales y acciones dirigidas contra mecanismos de recuperación, elementos compatibles con una operación que podría apoyar objetivos de ransomware o extorsión.
Los impactos de un ciberataque automatizado contra infraestructura Cloud
El primer impacto puede ser la interrupción de servicios. Una empresa moderna puede depender de aplicaciones alojadas en la nube para vender productos, atender clientes, procesar pagos o gestionar operaciones internas. Si los componentes que sostienen esas aplicaciones son eliminados o modificados, el problema deja de ser exclusivamente tecnológico y se convierte rápidamente en un problema de negocio.
Imaginemos una empresa de comercio electrónico cuya aplicación, base de datos y almacenamiento funcionan en Azure. Si un atacante elimina el almacenamiento donde se encuentran determinados recursos o inutiliza componentes necesarios para ejecutar la aplicación, los clientes podrían comenzar a recibir errores. Para el usuario final quizá solo aparezca una página que no carga; detrás de esa pantalla puede existir una cadena de recursos Cloud que dejó de funcionar.
El segundo impacto es la destrucción o pérdida de información. Las cuentas de almacenamiento pueden contener datos de aplicaciones, archivos, registros o información utilizada por procesos empresariales. Microsoft documentó más de 100 intentos de eliminar Storage Accounts durante la secuencia destructiva de Storm-3168.
El tercero es el compromiso de secretos. Azure Key Vault, por ejemplo, está diseñado para proteger claves criptográficas, certificados y secretos como contraseñas o cadenas de conexión. Puede imaginarse como una caja fuerte digital desde la que las aplicaciones obtienen las credenciales que necesitan. Si un atacante consigue acceder a esos secretos, el problema puede extenderse más allá del recurso originalmente comprometido.
Microsoft también registró más de 30 solicitudes exitosas de ListKeys durante la actividad de Storm-3168. Estas solicitudes buscaban obtener las claves de acceso de cuentas de almacenamiento, lo que podía facilitar el acceso posterior a información almacenada en ellas.
Pero quizá el impacto más difícil de gestionar sea el tiempo. Google Threat Intelligence ha advertido que los flujos de trabajo agentic reducen la latencia asociada con la intervención humana, mientras que Sysdig ha mostrado casos donde un agente puede fallar, analizar el resultado y volver a intentarlo en segundos. En un incidente de este tipo, la defensa no solo necesita detectar qué está ocurriendo: necesita hacerlo antes de que la siguiente acción automática amplíe el daño.
CISO: las identidades Cloud también son una superficie de ataque
Para un CISO (Chief Information Security Officer o director de Seguridad de la Información), esta evolución obliga a ampliar el mapa tradicional de riesgos. El CISO es el responsable de definir y dirigir la estrategia de ciberseguridad de una organización, ya que supervisa cómo se protegen los sistemas, las identidades, los datos y la infraestructura frente a amenazas digitales.
Durante mucho tiempo, buena parte de la estrategia de ciberseguridad se concentró en las cuentas de los empleados: quién tiene acceso, qué contraseña utiliza, si cuenta con MFA (Multi-Factor Authentication o autenticación multifactor) y qué ocurre con sus permisos cuando cambia de puesto o abandona la empresa.
Cabe destacar que la MFA añade una capa adicional de seguridad al exigir más de una forma de comprobar la identidad de una persona (por ejemplo, una contraseña junto con un código enviado al teléfono, una aplicación de autenticación o un dato biométrico), de modo que conocer únicamente la contraseña no sea suficiente para acceder a la cuenta.
Sin embargo, en la nube hay que añadir otro grupo que puede pasar desapercibido: las identidades que pertenecen a aplicaciones, servicios y automatizaciones. Estas cuentas no son utilizadas por personas, pero pueden tener permisos para consultar información, ejecutar procesos o modificar recursos; por ello, si una de ellas es comprometida, el atacante puede aprovechar directamente las autorizaciones que tenga asignadas.
La diferencia es relevante. Un empleado normalmente inicia y termina una sesión. Una aplicación puede funcionar durante las 24 horas del día, ejecutar procesos automáticamente y conservar permisos durante meses. Si nadie revisa esos permisos, una identidad no humana puede terminar disponiendo de un alcance mayor del que realmente necesita.
Microsoft recomienda que las organizaciones eviten asignar roles privilegiados a workload identities cuando no sean necesarios y que revisen periódicamente sus permisos. La razón es sencilla: si una identidad de este tipo es comprometida, el atacante puede aprovechar directamente los privilegios asignados a ella.
La consecuencia es un cambio de perspectiva: la pregunta ya no es solamente quién puede entrar, sino qué puede hacer cada identidad una vez dentro. Esa distinción resulta fundamental en un entorno donde las acciones pueden ser ejecutadas automáticamente contra cientos de recursos.
¿Cómo proteger Azure frente a ataques automatizados y destructivos?
- Revisar las identidades privilegiadas
El primer paso consiste en identificar service principals, cuentas de servicio, aplicaciones y otras identidades no humanas con permisos elevados. El objetivo no debe ser elaborar únicamente una lista de “quién tiene acceso”, sino establecer con precisión qué recursos puede consultar, modificar, eliminar o administrar cada identidad. Microsoft recomienda revisar y reducir los privilegios asignados a las identidades de carga de trabajo.
Una revisión efectiva puede descubrir situaciones como una aplicación que solo necesita consultar una base de datos, pero que también conserva permisos para eliminar recursos de almacenamiento. En condiciones normales quizá nunca utilice ese permiso; durante una intrusión, sin embargo, puede convertirse en la diferencia entre un incidente contenido y una interrupción generalizada.
- Aplicar el principio de mínimo privilegio
El principio de Least Privilege consiste en otorgar únicamente los permisos necesarios para realizar una función determinada. Microsoft integra este concepto dentro de su modelo Zero Trust, junto con otros dos principios: verificar explícitamente y asumir que puede producirse una intrusión.
La idea puede expresarse de una manera muy sencilla: si una identidad cae, su radio de destrucción debe ser limitado. Una aplicación que necesita leer un archivo no debería poder eliminar toda la cuenta de almacenamiento; una automatización que administra un recurso concreto no debería convertirse automáticamente en administradora de toda la suscripción.
En Azure, Microsoft recomienda combinar RBAC, permisos mínimos y mecanismos como el acceso Just-In-Time para reducir la exposición de privilegios administrativos. El objetivo de Zero Trust no es garantizar que una intrusión jamás sucederá, sino reducir sus consecuencias cuando ocurra.
- Proteger y rotar secretos
Las credenciales de aplicaciones, certificados, tokens y claves de API deben considerarse activos críticos. Microsoft señala que las credenciales expuestas públicamente deben tratarse como comprometidas y revocarse o rotarse; eliminar posteriormente el contenido publicado no significa que el secreto haya dejado de estar expuesto.
Este punto fue especialmente relevante en Storm-3168. Microsoft encontró que el client ID, client secret y tenant ID asociados con uno de los service principals habían aparecido anteriormente en texto plano dentro de una incidencia pública de GitHub. Aunque posteriormente el contenido fue editado, el historial público permitió que el secreto siguiera siendo accesible.
Herramientas como Azure Key Vault permiten centralizar secretos, certificados y claves y establecer controles específicos sobre quién o qué aplicación puede acceder a ellos. La recomendación no consiste simplemente en “guardar las contraseñas en otro lugar”, sino en reducir su exposición y controlar su ciclo de vida.
- Proteger los respaldos y mecanismos de recuperación
Un respaldo que puede ser eliminado por la misma identidad que administra el sistema productivo no ofrece una protección suficiente frente a una cuenta comprometida. Por ello, los mecanismos de recuperación necesitan controles independientes y privilegios separados.
Microsoft considera que los respaldos pueden ser la última línea de defensa frente a ransomware, eliminación accidental y ataques destructivos. Sus recomendaciones para Azure Backup incluyen mínimo privilegio, separación de responsabilidades y controles adicionales para operaciones críticas.
Esto resulta especialmente relevante porque Storm-3168 intentó afectar mecanismos relacionados con recuperación. Aunque las protecciones existentes bloquearon algunas operaciones, el episodio demuestra por qué los respaldos deben diseñarse bajo la premisa de que una identidad privilegiada puede llegar a ser comprometida.
- Vigilar el comportamiento de las identidades
La seguridad Cloud no debería limitarse a comprobar si una identidad está autorizada. También debe preguntarse si su comportamiento coincide con lo esperado.
Una aplicación que normalmente consulta una base de datos puede levantar una alerta si, de repente, comienza a enumerar cientos de recursos, solicitar claves de almacenamiento, consultar secretos y eliminar cuentas. En Storm-3168, precisamente esa combinación de actividades (reconocimiento, acceso a configuraciones, solicitudes de claves y operaciones destructivas) permitió observar la progresión de la actividad.
Este enfoque es particularmente importante en el contexto de agentes de IA porque una acción individual puede parecer legítima. Una solicitud para consultar una máquina virtual puede ser completamente normal. Cientos de solicitudes de descubrimiento seguidas por intentos masivos de eliminación constituyen un patrón muy diferente.
- Preparar una respuesta a velocidad de máquina
Aquí aparece una paradoja: si los atacantes utilizan automatización para acelerar sus operaciones, los defensores también necesitan automatización.
Las plataformas SIEM, XDR y SOAR pueden ayudar a correlacionar eventos, identificar comportamientos sospechosos y ejecutar determinadas acciones de respuesta. Microsoft, por ejemplo, plantea una evolución hacia capacidades de seguridad apoyadas por IA para investigar grandes volúmenes de actividad sin depender exclusivamente de que un analista revise manualmente cada evento.
Esto no significa entregar el control total de la infraestructura a una máquina. Significa establecer previamente qué acciones pueden ejecutarse de manera automática cuando existen señales suficientemente claras. Por ejemplo, una organización podría definir mecanismos para aislar una identidad que comienza a realizar operaciones destructivas anómalas, revocar credenciales comprometidas o detener determinadas automatizaciones.
La decisión crítica consiste en establecer qué puede hacer automáticamente el sistema de defensa y qué requiere autorización humana. Cuanto mayor sea la velocidad del ataque, más importante resulta que esa frontera esté definida antes de que ocurra el incidente.
El reto del CISO: responder a ciberataques a velocidad de máquina
Storm-3168 cambia una pregunta tradicional de la seguridad Cloud. Ya no basta con preguntar: “¿Cómo impedimos que el atacante entre?”. También hay que preguntar: “Si una identidad es comprometida, ¿hasta dónde puede llegar?”.
Microsoft documentó que las acciones observadas fueron posibles porque las identidades comprometidas ya disponían de los roles necesarios para realizar determinadas operaciones. Esto significa que el impacto no dependió únicamente de la técnica utilizada por el atacante, sino también de cómo había sido diseñada previamente la arquitectura de permisos.
Ese punto conecta directamente con Zero Trust. Microsoft resume su enfoque para Azure en tres principios:
- Verificar explícitamente.
- Utilizar el mínimo privilegio y.
- Asumir que puede producirse una intrusión.
Aplicados a las identidades de aplicaciones y servicios, estos principios buscan limitar el alcance de una cuenta comprometida y reducir el movimiento lateral dentro de la infraestructura.
La consecuencia para los responsables de seguridad es clara, las identidades humanas y no humanas deben formar parte del mismo mapa de riesgo. Un administrador puede representar un riesgo si su cuenta es comprometida; una aplicación con permisos administrativos puede representar un riesgo similar o mayor si opera permanentemente y puede ejecutar acciones sin intervención humana.
Y aquí aparece el verdadero desafío de la nueva etapa de la ciberseguridad: la velocidad. Google Threat Intelligence señala que los flujos agentic reducen la intervención humana en determinadas operaciones ofensivas, mientras que Sysdig ha mostrado agentes capaces de adaptar su comportamiento en segundos. La defensa, por tanto, necesita reducir también la distancia entre detectar una anomalía y actuar sobre ella.
Conclusión: la IA cambia la velocidad de los ciberataques Cloud
Storm-3168 no es importante únicamente porque varios recursos de Azure fueran atacados. Su relevancia está en lo que revela sobre la evolución de las amenazas: una identidad legítima puede convertirse en una herramienta de destrucción cuando sus credenciales son comprometidas, sus privilegios son demasiado amplios y sus acciones pueden automatizarse a gran escala.
Esto permite extraer una conclusión más amplia. La IA no necesariamente crea técnicas de ataque completamente nuevas; puede hacer que técnicas conocidas sean más rápidas, escalables y adaptables. Un atacante ya podía intentar robar una credencial, enumerar recursos o eliminar una base de datos. La diferencia está en cuánto tiempo, conocimiento especializado y supervisión humana necesita para encadenar todas esas acciones.
Para las organizaciones, la respuesta tampoco consiste únicamente en instalar otra herramienta de seguridad. Implica gobernar las identidades, aplicar mínimo privilegio, proteger secretos, separar los mecanismos de recuperación, observar el comportamiento de las aplicaciones y preparar respuestas automatizadas para aquellos escenarios en los que esperar a un análisis manual puede ser demasiado lento.
La nueva carrera de la ciberseguridad Cloud ya no consiste solamente en impedir que un atacante consiga entrar. Consiste en evitar que un acceso comprometido pueda transformarse, en cuestión de minutos, en una cadena automatizada de decisiones capaces de afectar toda una infraestructura.
Porque cuando el atacante puede operar a velocidad de máquina, la pregunta decisiva deja de ser quién llegó primero y pasa a ser quién puede limitar el daño antes de que termine la siguiente instrucción.
