Microsoft describió el 25 de septiembre de 2026 operaciones destructivas en la nube atribuidas a Storm-3168 que emplearon principales de servicio de Azure comprometidos. La investigación relata intentos de borrar recursos y afectar capacidades de recuperación. No confirma que empresas colombianas hayan sido víctimas, ni permite concluir que todas las intrusiones de nube sigan el mismo patrón. Para equipos en Colombia, el aprendizaje práctico es revisar identidades de aplicación, permisos, registros y protección de respaldos antes de que una credencial técnica permita acciones irreversibles.
Qué observó Microsoft
La investigación de Microsoft Security presenta actividad de Storm-3168 basada en principales de servicio comprometidos. Estas identidades representan aplicaciones o automatizaciones que interactúan con recursos de Azure. En los casos descritos, los operadores intentaron acciones destructivas sobre infraestructura y recursos vinculados a la recuperación. Microsoft caracteriza el comportamiento como ataques a la nube dirigidos por agentes, con herramientas que agilizan tareas. Esa descripción no demuestra que cada paso fuese autónomo ni que una tecnología por sí sola produzca el incidente.
La fuente distingue observación de interpretación. No documenta una nota de rescate observada en esta actividad ni exfiltración confirmada en los casos expuestos. Por eso conviene hablar de intentos destructivos y riesgo de indisponibilidad, no de un ransomware consumado en todas las víctimas. Tampoco ofrece un listado de organizaciones colombianas afectadas. Una empresa local debe traducir la investigación a controles verificables de su propio tenant.
Por qué una identidad de aplicación cambia el riesgo
Un principal de servicio permite que un programa se autentique sin una persona interactuando en cada ejecución. Esto es útil para despliegues, integraciones y administración, pero los secretos, certificados o permisos pueden convertirse en una vía de abuso. Una cuenta de aplicación con capacidad de borrar máquinas, cambiar políticas o tocar copias de seguridad ofrece un radio de acción mayor que el necesario para una tarea sencilla. El riesgo depende de los roles asignados y del alcance en suscripciones y grupos de recursos.
Las revisiones suelen centrarse en usuarios humanos, inicio de sesión multifactor y contraseñas. Esas medidas no resuelven por sí mismas una credencial de aplicación comprometida. Identifique quién creó cada principal, para qué se usa, qué credencial posee, cuándo vence y qué recursos puede modificar. Los objetos huérfanos después de un proyecto son especialmente difíciles de explicar durante una emergencia.
Un mapa de privilegios antes de tocar producción
Enumere aplicaciones registradas, principales de servicio, identidades administradas y sus asignaciones de roles. Relacione cada identidad con una persona responsable, proceso de negocio, repositorio de código y mecanismo de despliegue. Busque permisos de propietario, colaborador y administradores de copia de seguridad otorgados en ámbitos amplios. Documente dependencias: retirar un rol sin conocer su uso puede detener una aplicación, pero mantenerlo sin justificación prolonga exposición.
Revise secretos que puedan residir en pipelines, repositorios, archivos de configuración o equipos de proveedores. Prefiera identidades administradas cuando la arquitectura lo permita y adopte credenciales de vida limitada con rotación ensayada. La meta no es una sustitución apresurada de todos los secretos; es reducir privilegios excesivos y asegurar que una identidad comprometida pueda revocarse sin perder la continuidad del servicio.
Proteja el camino de recuperación
Una copia de seguridad solo sirve si el atacante no puede borrarla o inutilizarla con la misma identidad que controla producción. Separe funciones administrativas, revise políticas de inmutabilidad y protección contra eliminación donde estén disponibles, y pruebe restauraciones. Registre quién puede alterar retención, deshabilitar protección y borrar bóvedas o instantáneas. La protección debe cubrir tanto el dato como la configuración necesaria para volver a operar.
Realice un ejercicio de mesa con un escenario concreto: una aplicación de despliegue pierde su credencial y alguien intenta eliminar recursos. El equipo debe poder identificar credencial, revocarla, bloquear permisos, preservar logs y restaurar un servicio. Cronometre detección, contención y recuperación. El ensayo revela si el respaldo es realmente independiente o si depende de la cuenta cuya seguridad se puso en duda.
Detección y cronología
Correlacione inicios de sesión de principales de servicio con registros de actividad de Azure y cambios en roles, bóvedas, máquinas, redes y políticas de respaldo. Preste atención a una identidad que ejecuta operaciones fuera de su patrón habitual, desde una ubicación o herramienta inesperada, o en muchos recursos en poco tiempo. No use una sola dirección IP como prueba definitiva: integraciones legítimas pueden cambiar de origen y un actor puede usar infraestructura compartida.
Si hay señales de abuso, preserve los registros antes de modificar la cuenta. Construya la secuencia de autenticación, cambios de permisos, solicitudes de eliminación y efectos reales. Diferencie un intento denegado de un recurso efectivamente borrado; ambos importan, pero conducen a decisiones distintas. Revocar secretos y sesiones debe coordinarse con el dueño de la aplicación. El Análisis Forense Digital puede delimitar acciones y evidencia en un incidente confirmado.
Plan de contención si aparece actividad anómala
Designe un responsable de incidente, proteja los logs y suspenda las credenciales sospechosas según el impacto del servicio. Revise asignaciones de roles y otras credenciales de la misma aplicación; un secreto nuevo podría mantener acceso. Compruebe cambios en automatizaciones, pipelines y conexiones federadas. La contención no concluye al deshabilitar una cuenta si persisten permisos alternativos o una modificación maliciosa en el flujo de despliegue.
Después identifique recursos afectados, valide respaldos y restaure en un entorno controlado. Comunique hechos comprobados a dirección: qué fue intentado, qué se ejecutó, qué servicios están indisponibles, qué datos podrían estar afectados y cuándo habrá una actualización. Microsoft no confirma exfiltración en su reporte; una empresa que observe el mismo patrón debe investigar sus propios hechos antes de afirmar o descartar salida de información.
Dependencias con socios y proveedores
Los integradores suelen necesitar una identidad para desplegar y mantener infraestructura. Solicite un inventario de accesos externos, propósito, fecha de caducidad y responsable interno. Separe cuentas de producción y pruebas, limite ámbito y exija registros. Cuando termina un contrato, retire accesos y secretos como parte del cierre, no meses después de una auditoría. Pregunte quién puede recuperar una aplicación si se revoca la credencial de un proveedor.
El contrato y el procedimiento técnico deben permitir respuesta conjunta en horas. Un proveedor puede guardar el secreto en su propio sistema; la empresa necesita saber cómo se rota, qué evidencia puede proporcionar y quién autoriza su revocación. Estas preguntas son tan relevantes para un SaaS pequeño como para una organización con varias suscripciones.
Aplicación para organizaciones colombianas
La publicación de Microsoft no constituye evidencia de víctimas en Colombia. Sí expone un modo de ataque aplicable a empresas locales que usan Azure mediante integradores, aplicaciones propias o procesos automatizados. Una revisión inicial puede concentrarse en identidades con permisos sobre infraestructura crítica y respaldos, y en la capacidad real de recuperar una operación de ventas, pagos o atención.
Un Análisis de Vulnerabilidades y una revisión de configuración pueden localizar permisos y exposiciones; un ejercicio autorizado de Ethical Hacking puede validar rutas específicas sin poner en riesgo recursos productivos. La dirección debería exigir evidencia de restauración, no solo un reporte que enumere políticas habilitadas.
Una agenda de treinta días
En la primera semana, inventaríe principales de servicio privilegiados y proteja logs y copias. En la segunda, acuerde dueños, retire permisos sobrantes y rote credenciales de alto riesgo con pruebas funcionales. En la tercera, configure alertas sobre eliminación masiva y cambios de roles; en la cuarta, ensaye una restauración y cierre excepciones. Los plazos deben ajustarse a tamaño y criticidad, pero cada acción ha de producir evidencia auditable.
Revise después el proceso de creación de nuevas aplicaciones. Una plantilla de permisos mínimos, aprobación de roles amplios, fecha de expiración y revisión periódica evita volver al mismo inventario desconocido. Cada excepción debería responder quién la pidió, qué operación exige ese privilegio, por cuánto tiempo y cómo se detectaría su abuso.
Cómo comprobar que el plan de defensa funciona
El equipo puede crear una identidad de prueba con permisos muy limitados y simular una solicitud de eliminación de un recurso no crítico. La operación debe ser denegada y generar un registro visible para seguridad. Después pruebe una alerta de cambio de rol y el procedimiento de revocación de credenciales. Es un ensayo controlado de sus barreras, no una reproducción del ataque descrito por Microsoft.
Valide además una restauración en una suscripción o entorno aislado. Registre el tiempo para encontrar la copia, obtener permisos de recuperación, reconstruir configuración y poner a disposición un servicio de prueba. Compruebe si el responsable de copias puede impedir una eliminación aun cuando se comprometa la cuenta de despliegue. Un resultado parcial debe convertirse en una tarea con propietario, presupuesto y plazo.
La revisión de permisos necesita continuidad: cuando un equipo solicita rol de propietario para una migración, registre por qué, durante cuánto tiempo y qué rol menos amplio se probó. Un proceso de acceso temporal reduce acumulación de privilegios. Incluya en la siguiente revisión a las identidades de socios, porque un inventario que omite integradores ofrece una imagen incompleta de la administración real.
Preguntas frecuentes
¿La investigación prueba ransomware en Azure?
Microsoft describe operaciones destructivas y aclara que no observó una nota de rescate en los casos tratados. No conviene etiquetar todas las acciones como ransomware.
¿MFA para administradores humanos resuelve este riesgo?
Ayuda en accesos humanos, pero una identidad de aplicación utiliza otros mecanismos. Revise permisos, credenciales, federación y registros específicos.
¿Tener respaldo basta?
Es necesario probar que una identidad comprometida no pueda eliminarlo y que una restauración funcione dentro del tiempo requerido por el negocio.
Revise sus identidades de nube
Fuente y alcance
La investigación es la base de los hechos atribuidos al actor. Las medidas propuestas son una traducción operativa para entornos que deben revisar su propia evidencia.
