JadePuffer/Storm-3168: ransomware agente usa un secret filtrado en GitHub para borrar un tenant Azure completo

JadePuffer/Storm-3168: el primer ransomware agente que usó secretos de GitHub para destruir un tenant Azure

El 25 de septiembre de 2026, Microsoft Security Research publicó el detalle técnico de una campaña del operador que Sysdig bautizó como JadePuffer (trackeado por Microsoft como Storm-3168). Lo que vimos en julio era la prueba de concepto: una IA agente orquestando todo el ciclo de un ransomware. Lo que Microsoft acaba de documentar es la primera ejecución en producción contra un tenant Azure real: 15 horas de reconocimiento automatizado, 7 minutos de destrucción masiva, 100 cuentas de almacenamiento borradas, y un Key Vault perdido. El vector de entrada, además, no fue un exploit Zero Day: fue un secret filtrado en un issue público de GitHub que el equipo dio por cerrado al editarlo.

Si tu organización corre algo en Azure — aunque sea una Function App de soporte o un par de VMs Linux para staging — esta campaña te concierne. Y no por la sofisticación del ataque, que es notable, sino por lo absurdo del punto de partida: alguien publicó credenciales en un issue, lo editó “para borrar el secret”, y asumió que el problema estaba resuelto. El historial de edición siguió ahí, accesible para cualquiera que supiera mirar.

Qué es JadePuffer y por qué importa que sea “agente”

Sysdig Threat Research documentó a JadePuffer en julio de 2026 como el primer ransomware completamente orquestado por un agente de IA. La diferencia con un ransomware tradicional no es el cifrado ni el ransomware note: es el cómo se decide cada paso. En una operación clásica, un operador humano interpreta los resultados de cada comando y decide el siguiente movimiento. En JadePuffer, un agente de lenguaje grande ejecuta la cadena completa — reconocimiento, robo de credenciales, movimiento lateral, persistencia y cifrado — sin esperar validación humana entre etapas.

El segundo caso que Sysdig publicó en julio, bautizado EncForge, ya mostraba que el agente había evolucionado para apuntar específicamente a artefactos de IA: datasets de entrenamiento, modelos, bases de datos vectoriales. La tercera fase, que es la que Microsoft acaba de detallar, lleva la automatización al plano cloud: reconocimiento masivo de Azure, destrucción paralela de recursos, y collection de credenciales para extender el ataque después del wipe inicial.

El vector de entrada: un secret filtrado en GitHub

Microsoft no pudo confirmar el camino exacto, pero encontró el rastro más probable: el client ID, el client secret y el tenant ID de uno de los service principals comprometidos habían estado expuestos en texto plano en un issue público de GitHub de la propia organización afectada. Un empleado los publicó — probablemente para pedir ayuda en un debug o en una integración. Después de algún tiempo, alguien editó el issue para borrar el secret.

El problema: borrar el contenido de un issue público no invalida la credencial. El historial de edición sigue siendo público. Cualquier comentario previo a la edición quedó cacheado en los archives de GitHub, en los logs de crawlers, en Wayback Machine, en el watch de cualquier usuario que llegó a leerlo. Microsoft lo dice explícitamente en su reporte: tratar cualquier secret publicado en internet como comprometido, revocarlo o rotarlo de inmediato, y no confiar nunca en que “ya lo borré” resuelve el problema.

El segundo vector que Microsoft observó, sin confirmación de que fuera el usado en este caso, es probing automatizado contra Azure App Services de múltiples clientes. El agente probaba rutas sensibles en aplicaciones web: paneles de administración de WordPress, PHP-CGI, el endpoint /api/v1/validate/code de LangFlow, y rutas típicas de web shells. No hubo overlap con los tenants afectados en este incidente, pero el patrón sugiere que Storm-3168 mantiene un brazo de reconocimiento permanente probando toda superficie accesible.

Reconocimiento: 15 horas y media para mapear un tenant entero

Una vez con el service principal en la mano, el atacante usó dos identidades comprometidas del mismo tenant, repartiendo el trabajo:

• Service principal 1 (reconocimiento): durante aproximadamente 15 horas y 30 minutos, enumeró Virtual Machines, suscripciones, resource groups y recursos individuales. Más de 300 operaciones de lectura exitosas. Eso le dio al atacante visibilidad completa del Azure de la organización.
• Service principal 2 (reconocimiento focalizado + destrucción + collection): arrancó 90 minutos después que el primero y enumeró VMs y resource groups en dos suscripciones en cinco segundos. Después, 16 horas más tarde, volvió para enumerar Azure App Service configuration stores (probablemente buscando credenciales expuestas) e intentar una operación ListKey contra una cuenta de almacenamiento inexistente.

Ambas identidades usaron infraestructura vinculada a Storm-3168, el mismo fingerprint de red, y el user agent python-requests/2.34.2. La coordinación temporal entre las dos identidades, más el hecho de que una sola identidad emitió múltiples tokens superpuestos para tareas distintas, deja claro que no hay un humano detrás decidiendo cada paso. Es un agente ejecutando un plan.

La secuencia destructiva: 7 minutos que borraron un Azure

El momento clave del ataque fue una ventana de 7 minutos en la que el service principal 2 ejecutó más de 100 intentos de borrado de cuentas de almacenamiento. La mayoría tuvieron éxito. En el mismo resource group, también borró:

• Un Azure Key Vault
• Una Function App
• El App Service plan asociado

Intentó además borrar varias Azure SQL Databases en paralelo. Todos esos intentos fallaron porque el atacante usó una versión de API no soportada para el tipo de recurso Azure SQL Database. Sin saberlo, le hicieron un favor a la víctima: ese error impidió que el wipe alcanzara también las bases de datos.

El atacante también intentó borrar las protecciones de backup y recuperación: Site Recovery locks y Azure Backup protection locks. Estos intentos también fallaron. La razón: la víctima tenía Azure resource locks configurados. Microsoft lo destaca como la primera línea de defensa que funcionó cuando todo lo demás había caído:

“Azure resource locks y protecciones a nivel de cuenta de almacenamiento bloquearon los intentos de borrado para algunas cuentas, demostrando el valor de salvaguardas independientes que permanecen efectivas incluso cuando una identidad comprometida tiene permisos administrativos amplios.”

El agente intentó borrar específicamente cuentas de almacenamiento con nombres que sugerían terraform y backup. La intención era clara: inhibir la recuperación además de borrar los datos primarios. Eso es exactamente la técnica MITRE T1490 (Inhibit System Recovery), parte del playbook clásico de ransomware.

Collection de credenciales: 30 minutos después del wipe

Aproximadamente media hora después de la fase destructiva, el mismo service principal volvió con un plan distinto: pidió inventario de cuentas de almacenamiento y ejecutó más de 30 solicitudes ListKeys exitosas. Eso le dio al atacante las access keys de las cuentas, que son credenciales de largo plazo con acceso completo de lectura, escritura y borrado a los blobs y file shares.

Las cuentas objetivo incluían específicamente cuentas relacionadas con Azure Site Recovery. El patrón sugiere que el siguiente paso habría sido exfiltrar datos — respaldos incluidos — usando esas mismas keys. Microsoft no confirmó exfiltración exitosa en este incidente, pero las keys ya estaban en manos del atacante.

Por qué la automatización aquí se nota

Microsoft identificó 5 tokens únicos emitidos para el service principal usado en destrucción y collection. Cuatro tokens se usaron para borrado. El quinto se usó para inventario de almacenamiento y recuperación de keys. Dos de los tokens de borrado estuvieron activos simultáneamente durante un período de 70 segundos: uno enfocado en cuentas de almacenamiento, el otro mezclando Storage y SQL. Esa paralelización no es algo que un humano improvise. Es un script ejecutando múltiples hilos contra ARM con un rate plan precalculado.

Los role assignments que el agente usó venían dados por la configuración preexistente: un grupo le daba Storage Account Contributor, un Contributor directo autorizaba los borrados de la Function App y la recuperación de una key adicional, y un SQL DB Contributor directo autorizaba los intentos de borrado SQL. La lección aquí es incómoda: el atacante no escaló privilegios durante el ataque. Los permisos que necesitaba ya estaban asignados de forma rutinaria a los service principals de la organización.

Lo que tienes que revisar HOY si corres algo en Azure

Las recomendaciones de Microsoft, traducidas a una checklist operativa para sysadmins Linux con workloads en Azure:

1. Auditar los service principals por credenciales expuestas en repos públicos. El primer paso no es técnico: es buscar en GitHub, GitLab, Bitbucket y logs de CI/CD cualquier coincidencia con tus client_id y tenant_id. Herramientas como trufflehog, git-secrets y los scanners de Defender for Cloud hacen esto automáticamente. Lo que encuentres hay que revocarlo y rotarlo, no solo editar el comentario del issue donde apareció.
2. Aplicar principio de mínimo privilegio a las workload identities. El ataque funcionó porque los service principals tenían Contributor y Storage Account Contributor. Para una Function App que solo lee de un container específico, basta con Storage Blob Data Reader en el scope del container. Para una app que escribe logs, Storage Blob Data Contributor solo sobre el container de logs. Cualquier permiso por encima de eso es deuda técnica esperando un incidente.
3. Configurar Azure resource locks en recursos críticos. Los resource locks CanNotDelete y ReadOnly son la red de seguridad cuando una identidad comprometida tiene permisos que no debería. Aplicarlos a Key Vaults, cuentas de almacenamiento con datos de clientes, y a las vaults de Recovery Services. El costo de un resource lock es esencialmente cero; el costo de no tenerlo ya lo viste en este caso.
4. Habilitar la protección de borrado a nivel de cuenta de almacenamiento. Cada Storage Account tiene una opción de soft delete y de deletion protection que retiene los datos borrados entre 7 y 365 días. Activada por defecto en cuentas nuevas, pero es común encontrarla desactivada en cuentas heredadas. Microsoft confirmó que esta protección fue una de las que salvó cuentas en este incidente.
5. Activar Microsoft Defender for Cloud para los servicios relevantes. Defender for Storage, Defender for Key Vault, Defender for App Service, Defender for Resource Manager y Defender for Databases son los que generan las detecciones que Microsoft lista en su tabla de telemetría. Si tienes alguno desactivado por costo, reconsidera el cálculo: el costo de Defender for Storage sobre 100 cuentas es menor que el costo de un día de incidente.
6. Separar las identidades de producción de las de staging. El patrón de “un solo service principal para todo” es exactamente lo que aprovechan estos ataques. Crear service principals dedicados por workload y por ambiente (prod, staging, dev) limita el blast radius cuando uno se ve comprometido. La gestión es ligeramente más cara, pero pagadera con un pipeline de Terraform o Bicep.

Lo que cambia si usas agentes de IA en tu infraestructura

El caso JadePuffer/Storm-3168 no es solo un Azure attack. Es un caso de AI-assisted lateral movement. El agente no necesita encontrar un Zero Day ni engañar a un usuario con phishing: usa las mismas APIs administrativas que cualquier pipeline de CI/CD legítimo. Desde el punto de vista del Activity Log de Azure, todo se ve como operaciones ARM normales ejecutadas por service principals con permisos asignados.

La diferencia entre un atacante humano y el agente es la velocidad de reconocimiento. 300 operaciones de lectura en 15 horas con un humano sentado frente a una consola es una operación forense detectable. 300 operaciones de lectura distribuidas en threads paralelos con un agente que va ajustando la siguiente consulta en función del resultado anterior es indistinguible del ruido normal de un equipo DevOps trabajando.

Microsoft recomienda dos herramientas internas para responder a este tipo de amenaza a la misma velocidad: Project Perception, un sistema multi-agente de Microsoft para investigar y responder a incidentes en entornos grandes, y MDASH (Microsoft Defender for AI Security), que descubre activos de IA y reduce exposición en aplicaciones agentic. Si no usas Microsoft Defender XDR, las equivalencias open source son Wazuh con reglas custom para ARM, Stratus Red Team para simular el TTPs de JadePuffer en tu propio tenant, y Cartography de Lyft para mapear relaciones entre service principals y recursos — el grafo que el atacante construyó en 15 horas con 300 lecturas, pero construido de forma proactiva desde la configuración real.

Indicadores de compromiso que puedes bloquear ya

Microsoft publicó tres IPs que deberías añadir a tus reglas de denegación y a tu SIEM:

# IOCs Storm-3168/JadePuffer — 25-sep-2026
45.131.66[.]106    # App Service probing + malicious ARM requests
34.153.223[.]102   # App Service probing
64.20.53[.]230     # App Service probing

Para cualquiera de estas IPs, monitoriza:

• Conexiones hacia Azure App Services desde rangos no esperados (estas IPs están asociadas a infraestructura de comando y control del operador).
• Cualquier actividad ARM que venga precedida de un User-Agent: python-requests/2.34.2 desde una IP externa — los service principals de tu tenant normalmente usan el SDK de Azure o la CLI, no requests directos.
• Picos de operaciones Microsoft.Storage/storageAccounts/delete o Microsoft.KeyVault/vaults/delete en una ventana corta. Un borrado puntual es normal en rotación de recursos; diez o más en cinco minutos es la señal de alarma.

El contexto: tres campañas de ransomware agente en tres meses

JadePuffer no es un caso aislado. En los últimos tres meses hemos visto al menos tres operaciones documentadas que usan agentes de IA como vector principal o apoyo:

• Sysdig documenta JadePuffer (julio 2026): primer ransomware completamente orquestado por un agente de IA, dirigido a bases de datos PostgreSQL con cifrado automatizado.
• EncForge (julio 2026): JadePuffer evoluciona para apuntar a artefactos de IA — datasets de entrenamiento, modelos, bases vectoriales — con malware específico para cifrar este tipo de recursos.
• Storm-3168 contra Azure (junio 2026, publicado septiembre): la campaña que Microsoft acaba de detallar. Reconocimiento masivo, destrucción paralela, collection de credenciales, todo automatizado.

El patrón común: cada vez que se concede a un atacante — humano o agente — acceso programático amplio a un entorno cloud, la velocidad del ataque escala al ritmo de la automatización disponible. Los ransomware operators lo aprendieron con los scripts de post-explotación en la década de 2010. Ahora lo están aplicando al cloud con LLMs como orquestador.

Resumen accionable

• Auditar esta semana los service principals de tu tenant Azure contra repos públicos. Cualquier coincidencia con tu tenant_id o client_id se trata como comprometida y se rota.
• Aplicar resource locks en Key Vaults y cuentas de almacenamiento con datos de cliente. Es la red de seguridad que Microsoft confirmó haber detenido parte del ataque.
• Revisar role assignments de los service principals activos. Contributor y Owner sobre suscripciones completas son innecesarios en el 95% de los casos reales.
• Activar las detecciones de Defender for Cloud para Storage, Key Vault, App Service y Resource Manager si las tienes en plan Free o desactivadas por costo.
• Simular el TTPs de JadePuffer con Stratus Red Team en un tenant de prueba. Verificar que tus alertas se disparan antes de que pase en producción.
• Bloquear las tres IPs de los IOCs publicados por Microsoft en tus reglas de firewall y en tu SIEM, y auditar logs históricos por conexiones previas.

El ataque a Azure del operador JadePuffer es la confirmación pública de lo que la industria de seguridad viene anticipando desde que Sysdig publicó el primer reporte: los ransomware agentes ya están en producción, ya están automatizando reconocimiento y destrucción a escala cloud, y ya están encontrando su camino de entrada en los mismos lugares donde los atacantes manuales han fallado durante años — los secrets olvidados en repos públicos. La diferencia es que ahora lo hacen en minutos donde un humano tardaría días, y que la ventana para detectarlos se reduce a la misma velocidad. Si tu postura de seguridad en Azure sigue siendo la de 2024, este es el momento de actualizarla.

Preguntas frecuentes

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux