Identidades de aplicaciones comprometidas permiten destruir recursos en Azure
Dos identidades de aplicación del mismo tenant ejecutaron más de 150 operaciones destructivas en 35 minutos y borraron la mayoría de más de 100 cuentas de almacenamiento.
Qué ha pasado
Microsoft describe cómo Storm-3168 usó dos identidades de aplicación del mismo tenant. Con ellas ejecutó más de 150 operaciones destructivas o de robo de credenciales en 35 minutos: borró la mayoría de más de 100 cuentas de almacenamiento, un Key Vault, una Function App y un plan de App Service. Los bloqueos de recursos y la protección contra eliminación salvaron parte del almacenamiento, y fallaron los intentos de quitar los bloqueos de Azure Backup y Site Recovery. Un secreto de la aplicación estaba publicado en un repositorio público de GitHub, aunque Microsoft no confirma que fuera la vía de entrada.
Por qué importa
El daño no llegó por una cuenta de persona, sino por una identidad de aplicación con permisos amplios que nadie estaba mirando: ese tipo de cuenta no tiene doble factor ni llama la atención cuando se usa. En 35 minutos se puede deshacer trabajo de años si una credencial de servicio acumula privilegios y nadie vigila lo que hace. Que los bloqueos salvasen parte del almacenamiento es la prueba de que las barreras que se ponen antes del incidente son las que de verdad cuentan.
Qué recomendamos
Limitar los privilegios de las identidades de aplicación, guardar y rotar sus secretos fuera del código y proteger los recursos y las copias con bloqueos e inmutabilidad. Un secreto en un repositorio público hay que rotarlo siempre, se confirme o no que fue la entrada. Y revisar quién puede quitar esos bloqueos, porque un permiso que los anula deja la protección en papel mojado.
Servicio relacionado: Infraestructura y Cloud · Copias y recuperación
¿Quieres saber cómo te afecta?
Revisamos tu entorno y te decimos qué hay que priorizar, sin compromiso.