La compañía publica un framework alineado con MITRE ATT&CK que organiza técnicas de compromiso que cruzan código, pipelines de CI/CD y recursos en la nube conectados.
Microsoft presentó una matriz de amenazas específica para aplicaciones web alojadas en la nube y plataformas serverless, estructurada según el framework MITRE ATT&CK. El documento organiza técnicas de ataque en 10 tácticas que abarcan desde el desarrollo de recursos hasta el impacto final, cubriendo vectores que atraviesan código de aplicación, runtimes administrados, identidades de carga de trabajo, pipelines de implementación y recursos en la nube conectados. La matriz se suma a publicaciones previas de Microsoft sobre Kubernetes y servicios de almacenamiento, completando un conjunto de referencias para entornos cloud-native que hasta ahora carecían de un mapeo sistemático de superficie de ataque.
Por qué las aplicaciones web en la nube requieren un modelo de amenazas distinto
Las aplicaciones web cloud-native y las plataformas serverless permiten desplegar lógica de aplicación con rapidez, pero generan rutas de ataque que no se ajustan a los modelos tradicionales de seguridad perimetral. A diferencia de una aplicación web convencional que corre en infraestructura controlada, estos entornos integran código de aplicación con servicios administrados del proveedor cloud, identidades efímeras, triggers automáticos y pipelines de despliegue continuo. Investigar la capa de aplicación y la plataforma cloud por separado deja brechas en la comprensión de cómo un atacante puede moverse lateralmente entre componentes que, en papel, pertenecen a dominios de responsabilidad distintos.
La matriz de Microsoft aborda este problema al organizar técnicas que explotan precisamente esas intersecciones. Por ejemplo, un atacante que compromete un repositorio de código conectado a una función serverless no necesita vulnerar la infraestructura cloud directamente: el pipeline de CI/CD legítimo despliega el código malicioso en producción. Del mismo modo, un subdomain takeover — técnica clasificada bajo Resource Development — puede convertirse en vector de Initial Access si el DNS apunta a un endpoint reutilizable del proveedor cloud que el atacante puede reclamar tras la eliminación del servicio original.
Técnicas de acceso inicial que explotan la integración automática
La matriz identifica vectores de Initial Access que aprovechan la naturaleza conectada de estos entornos. La inyección de código en repositorios conectados aparece como técnica específica: si un atacante obtiene permisos de commit en un repositorio de GitHub vinculado a Google Cloud Functions mediante triggers de Cloud Build, su código se despliega automáticamente bajo flujos de trabajo legítimos. No hay explotación de vulnerabilidad en el sentido tradicional — el mecanismo de despliegue funciona exactamente como fue diseñado, pero con código no autorizado.
Otra técnica documentada es la inyección de triggers serverless. Un usuario que puede influir directa o indirectamente en eventos que disparan funciones backend — cargas de archivos a S3, mensajes en colas, llamadas a API — puede forzar la ejecución de código con datos manipulados. Microsoft describe el caso de un archivo de imagen modificado que, al subirse mediante un formulario web legítimo y almacenarse en un bucket S3, dispara una función Lambda de AWS con un payload diseñado para ejecutar lógica no prevista o acceder a datos internos.
La exposición de interfaces administrativas también figura en la matriz. Servicios como Azure App Service incluyen interfaces de gestión (Kudu) que, si quedan expuestas a internet sin restricciones de red o con credenciales débiles, permiten a un atacante ejecutar comandos en el entorno de la aplicación. La técnica no requiere vulnerabilidad de día cero — basta con configuración inadecuada de controles de acceso.
Escalada de privilegios y movimiento lateral en entornos administrados
La matriz organiza técnicas de Privilege Escalation y Lateral Movement que reflejan la arquitectura de estos entornos. Las identidades de carga de trabajo — roles de IAM asignados a funciones serverless o aplicaciones web — suelen tener permisos sobre recursos cloud conectados (bases de datos, buckets de almacenamiento, colas de mensajes). Un atacante que logra ejecución de código en una función Lambda con permisos excesivos puede pivotar hacia esos recursos sin necesidad de credenciales adicionales. La escalada no ocurre dentro del sistema operativo, sino en el plano de control del proveedor cloud.
Microsoft también documenta técnicas de Defense Evasion y Credential Access adaptadas a estos contextos. La recolección de credenciales puede incluir extracción de variables de entorno donde se almacenan secretos, tokens de acceso efímeros generados por el runtime administrado, o claves de API embebidas en código de aplicación. La evasión de defensas puede aprovechar la naturaleza efímera de las funciones serverless — logs que se descartan tras la ejecución, contenedores que se destruyen automáticamente — para dificultar la forense post-incidente.
Impacto en América Latina: dependencia de pipelines automatizados sin revisión de seguridad
La adopción de plataformas serverless y aplicaciones web cloud-native ha crecido en América Latina impulsada por startups fintech, plataformas de e-commerce y servicios digitales gubernamentales que priorizan velocidad de despliegue sobre controles de seguridad en pipelines de CI/CD. En Brasil y México, sectores como pagos digitales y salud digital operan aplicaciones web integradas con servicios cloud de AWS, Azure y Google Cloud, frecuentemente con repositorios de código en GitHub o GitLab configurados para despliegue automático sin revisión manual de cambios.
Esta configuración amplifica el riesgo de las técnicas de inyección de código en repositorios conectados que Microsoft documenta. Un atacante que compromete credenciales de desarrollador o explota permisos excesivos en un repositorio puede insertar código malicioso que se despliega en producción sin intervención humana. La ausencia de controles de aprobación de cambios en pipelines de CI/CD — práctica común en equipos pequeños que buscan agilidad — convierte el repositorio de código en vector de acceso directo a entornos productivos.
Nuestro análisis
La matriz de Microsoft formaliza lo que equipos de seguridad cloud ya observaban de manera fragmentada: los límites entre desarrollo, operaciones y seguridad se desdibujan en entornos cloud-native, y los modelos de amenazas tradicionales no capturan rutas de ataque que atraviesan esos límites. Al organizar técnicas según tácticas de MITRE ATT&CK, el framework permite a defensores identificar brechas de visibilidad específicas — por ejemplo, si tienen telemetría de acceso a aplicaciones web pero no de cambios en repositorios conectados, o si monitorean actividad en funciones serverless pero no eventos que las disparan.
La publicación se alinea con un patrón observable en las últimas matrices de amenazas de Microsoft: cada una aborda un dominio cloud específico (Kubernetes, almacenamiento, ahora aplicaciones web) donde la superficie de ataque no se reduce a vulnerabilidades de software, sino a configuraciones de integración entre componentes administrados por el proveedor y recursos controlados por el cliente. Esto desplaza el foco de seguridad desde parcheo de sistemas operativos hacia revisión de permisos de identidades de carga de trabajo, validación de triggers de eventos y auditoría de pipelines de despliegue.
Lo que la matriz no resuelve — y Microsoft no pretende que lo haga — es la brecha de capacidad técnica en equipos que adoptan estas plataformas sin experiencia previa en seguridad cloud. Saber que existe una técnica de subdomain takeover o inyección de triggers serverless no equivale a tener herramientas de detección configuradas o procesos de respuesta definidos. La pregunta que queda abierta es si los proveedores cloud implementarán controles por defecto que mitiguen estas técnicas — validación automática de configuraciones de DNS, revisión obligatoria de cambios en repositorios conectados, restricción de permisos de identidades de carga de trabajo — o si seguirán delegando esa responsabilidad en clientes que, en muchos casos, carecen de los recursos para ejercerla.