Microsoft sigue sin saber cómo los hackers robaron la clave MSA en el ataque a Exchange de 2023
La Junta de Revisión de Seguridad Cibernética de EE. UU. (CSRB) concluyó que Microsoft no tiene evidencia definitiva de cómo Storm-0558 obtuvo la clave de firma MSA usada en el ataque a Exchange Online de 2023. El informe también expuso que la clave era de 2016 y debió revocarse en marzo de 2021.
La CSRB, dependiente del Departamento de Seguridad Nacional de EE. UU., publicó un informe muy duro sobre el manejo que hizo Microsoft del ataque a Exchange Online de 2023. Desde mediados de mayo de ese año, el grupo de ciberespionaje Storm-0558, vinculado a China y activo por más de dos décadas, comprometió los correos de más de 500 personas en 22 organizaciones. Casi 10 meses después de iniciada la investigación, la junta dijo que no hay evidencia definitiva de cómo los atacantes consiguieron la clave de firma, a pesar de lo que Microsoft había afirmado antes: que se robó del portátil de un ingeniero comprometido previamente a través de una empresa adquirida.
Una clave que nunca se retiró
Los atacantes entraron a los buzones con tokens de autenticación falsificados, firmados con una clave de consumidor de la Cuenta de Servicios de Microsoft (MSA) creada en 2016. Esa clave debió revocarse en marzo de 2021, pero seguía activa. La explicación es operativa: en el sistema de consumidores la rotación de claves era manual, a diferencia del sistema empresarial, que la automatizaba. Tras una interrupción importante de la nube provocada por una rotación manual, Microsoft suspendió el proceso en 2021 sin dejar ningún mecanismo que avisara a los empleados de claves antiguas que debían retirarse.
El segundo problema fue de alcance. La clave estaba pensada para firmar tokens solo de cuentas de consumidor, pero una vulnerabilidad desconocida hasta entonces permitió usarla también contra correo empresarial. Microsoft explicó a la junta que el error nació al crear un endpoint de OpenID Connect (OIDC) que listaba las claves de firma activas tanto de los sistemas de identidad empresariales como de consumidores.
Detectado por un cliente, no por Microsoft
Microsoft se enteró del ataque porque el Departamento de Estado de EE. UU. le avisó el 16 de junio de 2023. Un día antes, el SOC del Departamento de Estado había visto accesos anómalos, y al día siguiente se dispararon varias alertas de una regla personalizada que llamaban internamente "Big Yellow Taxi". La regla analizaba el registro MailItemsAccessed, que registra el acceso a mensajes individuales y que estaba disponible porque el Departamento de Estado tenía una licencia Microsoft 365 Government G5 con el nivel premium de Purview Audit.
Otras organizaciones afectadas no tenían ese nivel de registro y no pudieron detectar la intrusión. Eso llevó a Microsoft a trabajar con CISA para ofrecer esos registros de forma gratuita a todos los clientes. En febrero, además, amplió la retención predeterminada de registros de 90 a 180 días para los clientes estándar de Purview Audit y comenzó a entregar más telemetría a agencias federales.
Por qué importa y qué hacer
El caso deja dos lecciones que sirven para cualquier organización, sea o no un proveedor de nube. La primera: una clave de firma que no se rota se convierte en una llave maestra, y la rotación manual tiende a abandonarse en cuanto causa un problema operativo. La segunda: sin registros detallados de acceso al correo, una intrusión basada en tokens válidos es prácticamente invisible. Para empresas que usan Microsoft 365, la diferencia entre detectar o no este ataque estuvo en qué registros tenían activos y por cuánto tiempo se guardaban.
- Verifica que la auditoría de buzones esté activa en tu tenant de Microsoft 365 y que MailItemsAccessed se esté registrando.
- Revisa el período de retención de Purview Audit y exporta los registros a tu SIEM si necesitas conservarlos más de 180 días.
- Crea reglas de detección sobre MailItemsAccessed para accesos desde IP, aplicaciones o volúmenes inusuales, como hizo el Departamento de Estado.
- Inventaría las claves de firma y certificados de tus propias aplicaciones, define una fecha de vencimiento para cada uno y automatiza su rotación.
- Valida que tus aplicaciones rechacen tokens firmados por claves de un emisor o tipo de cuenta distinto al esperado.
Relacionado:
Microsoft rompe récords con 1.415 CVE en las actualizaciones de octubre de 2026
Vulnerabilidad en Microsoft SharePoint CVE-2026-65660 explotada en ataques
Chaotic Eclipse lanza BigDiskBuster, una PoC para un zero-day en Windows Defender
Nota elaborada por Ciberseguridad en español a partir de información publicada por Bleeping Computer. Los detalles pueden cambiar: para actualizaciones, consultá la fuente original.
Comentarios
Publicar un comentario