Lo que salió mal en Storm-2949 no fue “un exploit mágico” ni una brecha clásica con malware. Fue una cadena de abuso de identidades y permisos en Azure que terminó en exfiltración de datos desde Azure Key Vault y Azure SQL Database, apoyándose en el uso (y a menudo abuso) de App Services como plano de ejecución. El resultado práctico en empresa es claro: cuando el control de identidad se degrada, el perímetro desaparece y la segmentación por red no compensa.
Este post se centra en el caso Storm-2949 descrito por Microsoft (mayo de 2026) desde un enfoque de postmortem operativo: qué condiciones habilitan el salto desde “robo de identidad” a “compromiso total”, qué señales suelen estar ya en los logs, y qué medidas de contención y prevención son realistas en organizaciones con múltiples suscripciones, equipos y pipelines.
Qué salió mal: la identidad como punto único de fallo
En el ataque Storm-2949 el elemento decisivo fue que la identidad (usuarios, service principals y/o managed identities) se convirtió en el vector principal para operar dentro de Azure con apariencia legítima. En un entorno corporativo, esto ocurre cuando los permisos están sobredimensionados, las credenciales de aplicaciones se gestionan como “configuración” y no como activos de alto riesgo, y el monitoreo se centra en red y endpoints, dejando en segundo plano la telemetría del plano de control.
La consecuencia real es que el atacante no necesita ejecutar binarios ni “instalar nada”: le basta con invocar APIs (directamente o a través de App Services) para leer secretos, enumerar recursos y extraer datos. En la práctica, esto reduce la fricción de detección porque muchas acciones se parecen a operaciones de administración habituales, especialmente si la organización tiene automatización agresiva y “hace de todo” con identidades de aplicación.
Un patrón típico que agrava el impacto es el uso de identidades compartidas para varios entornos (dev/test/prod) o para múltiples aplicaciones. Cuando esa identidad tiene acceso a Key Vault y a la vez puede actuar sobre App Services, la cadena se acelera: extraer secretos habilita acceso a más servicios; y tener un runtime gestionado facilita ejecutar llamadas hacia servicios internos sin levantar sospechas de un host desconocido.
Cómo se encadenó el acceso: de App Services a Key Vault y SQL sin malware
El abuso de App Services como “plataforma de ejecución” encaja especialmente bien en organizaciones donde las apps ya tienen conectividad, identidades asignadas y acceso a secretos. En vez de pivotar con técnicas de post-explotación en máquinas, el atacante puede usar componentes existentes para operar: App Services con identidades administradas, settings con referencias a secretos, y permisos preexistentes para leer de Key Vault o autenticarse contra SQL.
En empresa se ve con frecuencia esta dependencia: App Service obtiene credenciales o tokens (directa o indirectamente) para acceder a SQL Database y a otros backends. Si el atacante logra controlar la identidad o su contexto de ejecución, o logra operar con permisos equivalentes, el salto desde “puedo leer secretos” a “puedo leer datos” es cuestión de minutos. La exfiltración no necesita túneles extraños: basta con consultas legítimas y exportaciones usando canales permitidos por la propia plataforma.
Para aterrizarlo en consecuencias reales: una única lectura de secretos en Key Vault puede revelar cadenas de conexión, certificados, claves de firma, o credenciales de terceros. Con eso, el atacante no solo extrae datos de SQL; también puede suplantar integraciones, firmar tokens en sistemas mal diseñados o moverse lateralmente a otros recursos que confían en esos materiales criptográficos.
Señales tempranas que suelen estar en tu tenant (y se pasan por alto)
En incidentes como Storm-2949, las señales raramente son “un antivirus saltó”. Suelen ser trazas de identidad y administración: picos de operaciones en el plano de control, accesos a Key Vault fuera de patrones normales, o actividad de App Services que no encaja con el comportamiento esperado (por ejemplo, lecturas de secretos no asociadas a despliegues).
Un problema práctico es que muchos equipos ven los logs “a posteriori” y de forma fragmentada: el equipo de plataforma mira App Service, el de datos mira SQL, y el de seguridad mira AAD. El atacante vive en los huecos. Cuando por fin se correlaciona, el daño ya está hecho y la rotación de secretos se vuelve urgente y disruptiva.
- Accesos a Key Vault anómalos: no solo fallos de autenticación; también lecturas exitosas de secretos/keys/certs desde identidades que normalmente no lo hacen.
En un entorno corporativo, esto se traduce en revisar eventos de auditoría de Key Vault para detectar lecturas masivas, accesos fuera de horario o desde identidades “infra” que no deberían tocar secretos de aplicaciones. Si no existe baseline, el primer paso es construirlo por aplicación y por identidad, no por suscripción completa.
- Cambios “pequeños” en App Services: modificaciones de configuración, identidad asignada, referencias a Key Vault o cambios en slots que parecen rutinarios.
Estos cambios son especialmente peligrosos porque se confunden con operaciones de CI/CD. En empresas con muchos despliegues diarios, un actor con identidad comprometida puede camuflarse entre la actividad normal. Por eso conviene separar identidades de despliegue de identidades de ejecución, y alertar cuando una identidad de pipeline toca settings sensibles o asignaciones de identidad.
- Actividad de datos inusual en SQL: picos de consultas, exportaciones o accesos desde aplicaciones que “no son de reporting”.
Aquí el matiz empresarial es que la exfiltración puede parecer una carga legítima. Sin controles de acceso por identidad (y no solo por red) y sin auditoría activa, se descubre tarde. El indicador útil no es solo “más consultas”, sino “consultas desde el principal equivocado” o desde una app que no debería acceder a ciertos esquemas.
Contención sin apagar la empresa: decisiones y trade-offs reales
Cuando se confirma una cadena de abuso de identidad, la respuesta instintiva suele ser “revocar todo” o “rotar todos los secretos”. En la práctica, eso puede tumbar producción si los sistemas dependen de secretos estáticos o si múltiples apps comparten el mismo Key Vault. En Storm-2949, el riesgo es que el atacante ya tenga materiales suficientes para reautenticarse aunque se corten algunos caminos.
La contención efectiva en corporativo prioriza cortar persistencia y reducir radio de acción con el menor impacto: deshabilitar o restringir identidades sospechosas, bloquear rutas de acceso a Key Vault desde identidades de alto riesgo, y forzar rotación selectiva empezando por secretos que abren más puertas (certificados de firma, credenciales de integración, claves con privilegios amplios). El trade-off es aceptar una ventana de degradación controlada (por ejemplo, deshabilitar temporalmente features no críticas) a cambio de no colapsar el servicio.
- Congelar cambios en App Services sensibles: detener despliegues y bloquear modificaciones de configuración/identidad hasta completar el triage.
Esto es incómodo para los equipos de producto, pero evita que el atacante siga “mezclándose” con el ruido operativo. Si no se congela, la investigación se vuelve poco fiable porque el estado cambia constantemente y el atacante puede aprovechar el flujo normal de cambios.
- Rotación priorizada de secretos en Key Vault: empezar por los que permiten acceso a datos (SQL) y los que habilitan suplantación (certificados/keys).
La rotación masiva indiscriminada suele romper integraciones de terceros y sistemas legacy. En cambio, una rotación basada en impacto reduce el tiempo de recuperación. Si se detecta que una identidad tenía permisos de lectura, hay que asumir compromiso de esos secretos, aunque el acceso no parezca “excesivo”.
Cómo hacerlo en la práctica: hardening de identidades y controles verificables
La prevención realista contra un caso como Storm-2949 no se basa en “más herramientas”, sino en restricciones concretas sobre identidades, Key Vault y App Services, más verificación continua. El objetivo es que una identidad comprometida no sea suficiente para leer secretos críticos y después extraer datos de SQL, o al menos que ese camino sea ruidoso y bloqueable.
Lo primero es revisar permisos efectivos (no intenciones) y separar identidades por función: despliegue, ejecución, operación. En demasiadas empresas una identidad de pipeline tiene capacidad de cambiar settings, asignar identidades y también leer Key Vault. Esa combinación convierte cualquier fuga de credenciales en un compromiso sistémico.
- Reducir privilegios de identidades de App Service: asignar permisos mínimos en Key Vault (solo secretos necesarios, no “get/list” global), y evitar que la misma identidad tenga roles amplios en la suscripción.
Acción verificable: comprobar en Azure RBAC y/o en las políticas de acceso de Key Vault (según el modelo usado) que la identidad de ejecución no tiene permisos de enumeración masiva. En entornos maduros, además se valida que no existan asignaciones heredadas a nivel de resource group que “regalen” acceso a varios vaults.
- Restringir cambios de configuración en App Services: limitar quién puede modificar settings, identidad administrada, y referencias a Key Vault; auditar y alertar cambios fuera de pipelines autorizados.
Acción verificable: revisar Azure Activity Logs para operaciones de tipo write sobre el recurso de App Service, y establecer alertas cuando el actor no sea la identidad del pipeline o cuando el cambio afecte a configuraciones sensibles. En empresas con varios equipos, esto requiere un modelo de “propietarios” por app, no un rol global compartido.
- Acotar acceso a SQL por identidad: evitar credenciales estáticas reutilizables y asegurar que el acceso desde aplicaciones esté segmentado por base de datos/esquema.
Acción verificable: confirmar que los principals usados por la app en SQL no tienen permisos de lectura global ni capacidades de exportación no justificadas. Donde sea posible, exigir que las rutas de acceso se correspondan con identidades de ejecución específicas, de forma que una lectura anómala sea atribuible y bloqueable.
Recomendaciones para entornos corporativos
Storm-2949 muestra una realidad incómoda en Azure: cuando una identidad (humana o de aplicación) tiene permisos amplios y puede operar con App Services, el atacante puede moverse y exfiltrar datos sin desplegar malware. En ese contexto, la seguridad “por red” o la dependencia de señales de endpoint no basta, porque el abuso ocurre en el plano de control y en accesos legítimos a servicios gestionados.
Las lecciones accionables se concentran en tres frentes: reducir privilegios efectivos en Key Vault y en las identidades de ejecución, controlar y auditar cambios en App Services como si fueran cambios de seguridad, y tratar el acceso a SQL como un flujo de alto riesgo que debe estar segmentado por identidad. Si hoy tu organización no puede responder rápido a “qué identidades pueden leer qué secretos” y “qué aplicaciones pueden consultar qué datos”, el camino de robo de identidad a compromiso total ya está pavimentado.
¿Te interesa la seguridad en Cloud?
Comparto análisis técnicos, laboratorios prácticos y experiencias reales sobre Cloud Security.