Microsoft Storm-0558 y el fallo de la clave de firma que convirtió la identidad en la nube en un problema de responsabilidad pública

Resumen

• Storm-0558 no vulneró los controles de contraseñas de una agencia federal. Utilizó una clave de firma de consumidor de Microsoft para fabricar tokens de identidad aparentemente válidos, y luego se benefició de un defecto de validación de Microsoft que permitió que esos tokens firmados para consumidores llegaran al correo empresarial de Exchange Online.
• La vía de obtención de la clave sigue sin resolverse. La explicación basada en un volcado de memoria que Microsoft publicó en septiembre de 2023 fue posteriormente reducida a una hipótesis principal, después de que la compañía reconociera que no había encontrado un volcado que contuviera la clave ni registros que probaran la exfiltración. Los hallazgos de fallos mejor fundamentados son: la clave obsoleta, el defecto de validación entre límites, la débil detección de anomalías en los tokens y la limitada retención de registros forenses.
• La responsabilidad sigue a la capacidad de control. Solo Microsoft podía rotar la clave de la plataforma, corregir el validador del lado del servicio, detectar combinaciones imposibles de tokens en su nube, preservar la evidencia interna relevante y cerrar el vector de ataque. Los clientes podían mejorar la supervisión y la respuesta, pero en 2023 la telemetría decisiva de MailItemsAccessed estaba vinculada a las licencias E5/G5 de mayor costo.

Una falla de control de identidad, no una violación convencional de buzones

La intrusión de Storm-0558 es fácil de resumir en una frase conocida: piratas informáticos chinos robaron una clave de Microsoft y leyeron el correo del gobierno. Esa frase es aproximadamente correcta pero analíticamente insuficiente. Fusiona el acto del atacante, la pérdida no resuelta de material criptográfico por parte de Microsoft, un fallo de software separado, una decisión de ciclo de vida de una clave obsoleta, un éxito de detección por parte del cliente y la respuesta del proveedor de servicios en un solo evento. Una vez que esos mecanismos se separan, la asignación de responsabilidad se vuelve mucho más clara.

La intrusión no fue principalmente un caso de un empleado gubernamental que entregó su contraseña, una agencia que no implementó la autenticación multifactor o un servidor sin parches dentro de un ministerio. Storm-0558 poseía la mitad privada de una clave de firma de consumidor de Microsoft Account (MSA) creada en 2016. Una clave de firma privada permite a su titular producir tokens cuyas firmas pueden verificarse con la clave pública correspondiente. Por lo tanto, el actor podía afirmar identidades sin obtener las contraseñas de las víctimas. Un segundo defecto de Microsoft permitió que una clave destinada a cuentas de consumidor autenticara solicitudes contra el Exchange Online empresarial. El resultado fue una capacidad de suplantación a nivel de plataforma que cruzó el límite entre los sistemas de identidad de consumidor y organizacional de Microsoft.

Elanálisis técnico de julio de 2023 de Microsoftexplica el mecanismo básico: el actor falsificó tokens de Azure Active Directory con la clave de consumidor adquirida, utilizó un flujo legítimo de Outlook Web Access, obtuvo tokens de Exchange Online a través de la interfaz GetAccessTokenForResource y recuperó correo a través de la API de OWA. Microsoft dijo que un defecto de diseño también permitió al actor obtener nuevos tokens de acceso presentando uno previamente emitido por esa interfaz. Esto no fue simplemente una reproducción de credenciales robadas. Fue la fabricación y renovación no autorizada de credenciales que los servicios de Microsoft consideraban válidas.

La distinción es importante para la responsabilidad en la nube. Los clientes suelen seguir siendo responsables de sus identidades, higiene de dispositivos, permisos, configuración de aplicaciones y respuesta a incidentes. Pero un cliente no puede inspeccionar ni rotar el material de firma raíz de un proveedor de nube, aplicar parches al validador de tokens de producción del proveedor o implementar un detector dentro del plano de emisión de identidad del proveedor. Cuando la falla se origina en controles disponibles solo para el proveedor, describir el evento como un problema de responsabilidad compartida sin especificar quién controlaba cada protección oscurece más de lo que explica.

También es importante no clasificar erróneamente el evento como una interrupción del servicio. El registro público no muestra que Exchange Online dejara de estar disponible para las agencias afectadas. El daño fue la pérdida de confidencialidad y de comunicaciones de confianza, seguida de una carga de investigación sustancial. La continuidad del sector público incluye más que mantener un servicio accesible. El trabajo diplomático, económico, legislativo y de seguridad nacional depende de que los funcionarios puedan usar un sistema de comunicaciones sin que un adversario lo lea silenciosamente. Una nube puede permanecer técnicamente "activa" mientras la función pública que soporta se vuelve menos confiable.

Lo que está establecido, lo que se infiere y lo que sigue sin conocerse

Deben mantenerse separadas tres categorías probatorias.

Primero, el registro público establece firmemente que Storm-0558 utilizó una clave de firma de consumidor MSA creada por Microsoft en 2016 para falsificar tokens; que un defecto de validación de Microsoft permitió que esos tokens accedieran a cuentas empresariales de Exchange Online; que el Departamento de Estado detectó actividad sospechosa mediante registros mejorados de acceso a buzones; y que Microsoft mitigó la técnica conocida a través de una serie de cambios del lado del servicio. Las divulgaciones de Microsoft, el aviso de respuesta de CISA, las declaraciones de las agencias afectadas y la reconstrucción de la Junta de Revisión de Seguridad Cibernética (CSRB) convergen en esos puntos.

Segundo, la CSRB realizó hallazgos sobre la prevenibilidad, el diseño de controles, la cultura de seguridad, la divulgación y las prácticas de la industria. Surevisión completa de la intrusión del verano de 2023concluyó que el incidente era prevenible y nunca debió haber ocurrido. La Junta entrevistó a 20 organizaciones, recibió la cooperación de Microsoft, comparó controles en otros grandes proveedores de servicios en la nube y encontró una cascada de fallas evitables. Estos son hallazgos de una revisión independiente, no judiciales, pero son sustancialmente más sólidos que los comentarios basados únicamente en los primeros blogs de Microsoft.

Tercero, la ruta real por la cual Storm-0558 obtuvo la clave privada de 2016 sigue sin conocerse en el registro público. Esa incertidumbre es central. Microsoft publicó una historia detallada de volcado de memoria en septiembre de 2023, y luego agregó una corrección en marzo de 2024 indicando que no había encontrado un volcado que contuviera el material de la clave afectada. La CSRB informó que Microsoft exploró 46 hipótesis de robo de la clave y aún no sabía cómo o cuándo la obtuvo el actor. Cualquier relato que presente el volcado de memoria como la causa raíz probada exagera la evidencia.

El registro tampoco establece una asignación legal definitiva de pérdidas. El escrutinio del Congreso, las solicitudes de investigación y la aceptación de Microsoft de los hallazgos de la CSRB son relevantes para la rendición de cuentas. No sustituyen un fallo judicial, una decisión de ejecución de una agencia, una interpretación contractual o un análisis cuantificado de daños. La conclusión apropiada es más limitada: Microsoft controló varias salvaguardas fallidas y aceptó la responsabilidad por los problemas citados por la CSRB; las fuentes disponibles no establecen una responsabilidad civil, penal o regulatoria definitiva.

Cronología forense

2016-2021: una clave de larga duración y una migración aplazada

Microsoft creó la clave de firma de consumidor en 2016. La antigüedad de una clave no es por sí misma prueba de inseguridad, pero se vuelve relevante cuando una organización no puede demostrar con confianza su custodia continua y cuando la rotación limita la vida útil del material robado. La CSRB encontró que el sistema MSA de consumidor de Microsoft dependía de la rotación manual, mientras que su sistema de identidad empresarial había avanzado hacia la automatización. La compañía tenía la intención de migrar el sistema de consumidor a la tecnología automatizada, pero no había completado ese trabajo antes de la intrusión.

Según la CSRB, Microsoft detuvo la rotación manual de claves de firma de consumidor en 2021 después de una gran interrupción en la nube asociada con el proceso manual. No implementó entonces un reemplazo de rotación automatizada ni una alerta que notificara a los equipos responsables sobre las claves activas antiguas. Por lo tanto, la clave de 2016 siguió siendo aceptada en 2023. Esta es una clásica decisión de disponibilidad versus seguridad con un costo diferido oculto: pausar un procedimiento manual riesgoso puede reducir el riesgo inmediato de interrupción, pero dejar la automatización compensatoria sin terminar preserva la exposición de seguridad indefinidamente.

El hallazgo de la Junta es más útil que decir simplemente que una clave "caducada" funcionó. Una clave es aceptada o rechazada según la configuración de confianza activa del servicio. La falla crucial fue que una clave destinada a ser retirada permaneció dentro del conjunto de confianza. La propiaguía actual de rotación de claves de firmade Microsoft dice que las aplicaciones deben manejar la rotación periódica y de emergencia de manera programática y recomienda bibliotecas estándar para evitar defectos sutiles. Esa guía describe el comportamiento de validación orientado al cliente, pero el principio subyacente es más amplio: el reemplazo de claves debe ser una capacidad diseñada, no una ceremonia frágil que se vuelve demasiado riesgosa de realizar.

En septiembre de 2018, Microsoft introdujo un endpoint común de publicación de metadatos de claves en respuesta a la demanda de aplicaciones que sirvieran tanto a usuarios consumidores como empresariales. El relato posterior de Microsoft dijo que la documentación se actualizó para explicar la validación del alcance de la clave, pero las bibliotecas auxiliares no se actualizaron para hacer cumplir ese alcance automáticamente. Los sistemas de correo de Exchange comenzaron a usar el endpoint común de metadatos en 2022. Los desarrolladores asumieron que la biblioteca realizaba una validación completa y no agregaron la verificación requerida de emisor o alcance. Por lo tanto, el endpoint común aumentó la interoperabilidad al mismo tiempo que creaba un peligro de límite de confianza: la validez criptográfica se confundió con la autorización dentro del dominio de identidad correcto.

La reconstrucción de la CSRB sitúa otro evento relevante en 2021. Storm-0558 comprometió la red corporativa de Microsoft a través de la cuenta de un ingeniero entre abril y agosto. El ingeniero trabajaba para Affirmed Networks, que Microsoft había adquirido en 2020; Microsoft creía que el dispositivo había sido comprometido antes de la adquisición y luego se conectó al entorno de Microsoft con credenciales corporativas. El actor capturó y reprodujo un token de autenticación y accedió a material en SharePoint, incluida información relacionada con la gestión y la identidad de servicios de Azure. La Junta criticó a Microsoft por no detectar el dispositivo comprometido de la compañía adquirida antes de permitirle ingresar a la red corporativa.

Este compromiso de 2021 es evidencia de acceso e interés del atacante. No es prueba de que el actor obtuviera la clave MSA de 2016 en ese momento. Microsoft dijo a la Junta que la intrusión de 2021 probablemente estaba conectada porque era la única otra intrusión conocida de Storm-0558 en la red de Microsoft en la memoria registrada, pero la compañía no presentó evidencia específica que la vinculara con el robo de la clave. Un relato disciplinado debe preservar esa brecha.

Mayo-junio de 2023: el acceso comienza antes de que el proveedor lo detecte

Storm-0558 estableció infraestructura externa identificada y comenzó a acceder a cuentas de Exchange Online seleccionadas a más tardar el 15 de mayo de 2023. La CSRB advirtió que la ventana de compromiso podría haber comenzado antes porque la retención estándar de registros de 30 días de Microsoft limitó la vista retrospectiva disponible una vez iniciada la investigación. "Visto por primera vez" es, por lo tanto, un límite probatorio, no necesariamente el verdadero comienzo del ataque.

Los objetivos reflejaron prioridades de espionaje. El recuento final de la CSRB identificó 22 organizaciones y más de 500 individuos en todo el mundo, incluidas víctimas en los Estados Unidos, el Reino Unido y otros lugares. Las cuentas incluían las de la Secretaria de Comercio Gina Raimondo, el Embajador de Estados Unidos en China R. Nicholas Burns, el Subsecretario de Estado para Asuntos de Asia Oriental y el Pacífico Daniel Kritenbrink y el congresista Don Bacon. Elaviso inicial de incidente del 11 de juliode Microsoft se refirió a aproximadamente 25 organizaciones y cuentas de consumidor relacionadas. La diferencia es mejor tratarla como un cambio en la contabilidad del incidente entre un primer aviso de la compañía y la posterior reconstrucción independiente, no como evidencia de una nueva intrusión.

El Departamento de Estado, no Microsoft, detectó la campaña. El 15 de junio, el centro de operaciones de seguridad del Departamento observó anomalías. El 16 de junio, una regla personalizada conocida internamente como Big Yellow Taxi generó alertas a partir del evento de auditoría MailItemsAccessed, que registra el acceso a elementos del buzón de Exchange Online. El Departamento investigó a pesar de la posibilidad de falsos positivos y contactó a Microsoft ese día. Para el 19 de junio, el Departamento había determinado que seis cuentas habían sido accedidas, incluidas cuentas asociadas con los preparativos para el viaje del Secretario de Estado a Pekín. Identificó seis cuentas adicionales accedidas entre el 21 y el 24 de junio, y otra mediante el análisis de un servidor privado virtual incautado.

Las fechas muestran que el descubrimiento y la contención se superpusieron con el acceso continuo. La alerta del Departamento de Estado fue un éxito de detección, pero no reveló instantáneamente una credencial de plataforma falsificada. Microsoft examinó inicialmente explicaciones familiares como dispositivos comprometidos y tokens robados emitidos correctamente. Sus analistas vieron luego que los artefactos de autenticación de Exchange Online no se correspondían con los tokens de Azure AD en los registros esperados. Aproximadamente el 26 de junio, Microsoft determinó que el actor estaba usando la clave de consumidor de 2016 para crear tokens que funcionaban contra el correo de consumidor y empresarial.

Elaviso CISA-FBI AA23-193Aes inusualmente directo sobre la asignación de la capacidad de mitigación. Dice que todas las acciones de mitigación para esta actividad eran responsabilidad de Microsoft porque la infraestructura afectada estaba basada en la nube. También dice que las agencias no tenían conocimiento de otros registros de auditoría o eventos que hubieran detectado la actividad. El cliente detectó el incidente, pero solo el proveedor podía cerrar la técnica.

26 de junio al 3 de julio: mitigación por etapas en lugar de un solo interruptor

La cronología detallada de Microsoft registra varias acciones distintas:

• El 26 de junio, OWA dejó de aceptar tokens emitidos por GetAccessTokenForResource para su renovación, cerrando el comportamiento de renovación del que el actor había abusado.
• El 27 de junio, Microsoft bloqueó el uso en OWA de tokens firmados con la clave MSA adquirida, impidiendo el acceso adicional al correo empresarial a través de la ruta observada.
• El 29 de junio, Microsoft completó el reemplazo de la clave, revocó todas las claves de firma MSA que habían sido válidas durante el incidente y emitió nuevas claves desde sistemas reforzados.
• El 3 de julio, Microsoft bloqueó el uso de la clave para los clientes consumidores afectados a fin de evitar el uso de tokens emitidos previamente.

Esa secuencia demuestra por qué "la clave fue revocada" no es una descripción suficiente de la contención. Una campaña de falsificación de tokens puede involucrar metadatos de validación en caché, artefactos de acceso posteriores, interfaces de renovación, servicios de consumidor y empresariales, y tokens ya emitidos. La contención duradera requiere mapear cada lugar donde la antigua decisión de confianza sobrevive.

Microsoft dijo que observó a Storm-0558 pivotar hacia phishing y otras técnicas después de que se bloqueara la ruta conocida de falsificación de tokens, y que no había visto más actividad relacionada con la clave. Esto respalda la eficacia de las mitigaciones inmediatas contra el método observado. No prueba que se identificara la ruta de adquisición original o que el actor nunca obtuviera otro material sensible. La CSRB dijo explícitamente que la posibilidad de acceso a otras claves y datos seguía sin resolverse.

Julio de 2023 a marzo de 2024: divulgación, reforma de registros y una afirmación de causa raíz corregida

Microsoft divulgó públicamente la campaña el 11 de julio y publicó un análisis técnico más profundo el 14 de julio. Sus primeras publicaciones describieron correctamente el abuso de la clave y el error de validación, al tiempo que afirmaban que la adquisición de la clave seguía bajo investigación. El 19 de julio, después de coordinarse con CISA, Microsoft anunció que los registros detallados de acceso al correo electrónico y más de otros 30 tipos de eventos de auditoría estarían disponibles para los clientes del nivel estándar sin costo adicional. La compañía también dijo que el período de retención predeterminado para Audit Standard aumentaría de 90 a 180 días. Elanuncio de registro de Microsoftes una respuesta relevante porque cambia quién puede ver la evidencia necesaria para detectar abusos originados en el proveedor.

El 6 de septiembre, Microsoft publicó lo que llamó los resultados de sus principales investigaciones técnicas. El relato original afirmaba que un bloqueo del sistema de firma de consumidor en abril de 2021 produjo un volcado de memoria; que una condición de carrera permitió que la clave llegara al volcado; que el volcado se movió de un entorno de producción aislado a un entorno de depuración corporativo conectado a Internet; que los escáneres de credenciales no lo detectaron; y que Storm-0558 comprometió más tarde una cuenta de ingeniero con acceso a ese entorno. Debido a que los registros relevantes habían caducado, Microsoft calificó esto como el mecanismo de adquisición más probable.

Esa narrativa proporcionaba una cadena coherente, pero la cadena no estaba respaldada por evidencia directa. Elinforme de septiembre versionadode Microsoft ahora comienza con una actualización del 12 de marzo de 2024. La compañía dice que su hipótesis principal sigue siendo que errores operativos causaron que el material de la clave saliera del entorno de firma seguro y que se accedió al material a través de una cuenta de ingeniero comprometida. También dice que no encontró un volcado de memoria que contuviera la clave afectada, que la condición de carrera citada afectaba si un volcado podía salir del entorno de firma en lugar de si el material de la clave podía estar presente, y que eliminar dicho material no era un proceso estándar pero no había sido prohibido en ese momento.

La corrección cambia el estado epistémico del relato. Una hipótesis plausible no es un hallazgo de causa raíz. La CSRB informó que Microsoft dijo a la Junta en noviembre de 2023 que se había dado cuenta poco después de la publicación de que las declaraciones de septiembre eran inexactas, pero no publicó la corrección hasta marzo de 2024 después de repetidas preguntas de la Junta. Esta demora se convirtió en parte del hallazgo de cultura de seguridad de la Junta porque los clientes utilizan las divulgaciones de causa raíz para juzgar si la ruta de adquisición real ha sido cerrada.

Causa raíz, desencadenante y fallos de detección

El análisis de incidentes es más preciso cuando separa el desencadenante de las causas raíz y de los fallos de detección y respuesta.

Desencadenante

El desencadenante operativo fue el uso por parte de Storm-0558 de la clave privada de firma MSA de 2016 robada para crear tokens y presentarlos a través de las rutas de acceso de Exchange Online. El actor seleccionó objetivos, operó infraestructura, acuñó afirmaciones, accedió al correo y exfiltró mensajes. El actor es responsable de la intrusión maliciosa. La atribución a un actor de espionaje asociado con la República Popular China es una evaluación de inteligencia informada por Microsoft y la CSRB; este artículo no atribuye de forma independiente el mando estatal.

Causas raíz técnicas y condiciones facilitadoras

La primera pregunta de causa raíz, cómo escapó la clave privada del control de Microsoft, no está resuelta. Debe registrarse como un hecho material abierto, no llenarse con la hipótesis del volcado de memoria.

La segunda causa está mucho mejor establecida: la clave antigua siguió siendo de confianza. La rotación manual de claves de consumidor se detuvo en 2021 después de una interrupción, el reemplazo automatizado no estaba listo y ninguna alerta efectiva de antigüedad forzó una resolución. El robo de una clave de corta duración o retirada rápidamente habría producido una oportunidad menor. El robo de una clave que permaneció aceptada durante años produjo un poder de firma duradero.

La tercera causa fue la falla de alcance en la validación de tokens. El servicio verificaba una firma contra el material de clave disponible a través de metadatos comunes, pero no demostraba adecuadamente que el dominio de identidad de la clave estuviera autorizado para autorizar el recurso empresarial solicitado. Ladocumentación actual de validación de tokens de accesode Microsoft indica a los servidores de recursos que validen la firma del token, la audiencia, el emisor, el inquilino y el emisor de la clave de firma. El caso Storm-0558 muestra por qué esas comprobaciones no son redundantes. Una firma matemáticamente válida responde quién poseía una clave privada; no responde, por sí misma, si esa clave estaba autorizada para este inquilino, clase de cuenta, servicio o recurso.

La cuarta causa fue el defecto de diseño de renovación de tokens de OWA. Una vez que la identidad falsificada fue aceptada a través de un flujo legítimo, GetAccessTokenForResource permitió que un token obtuviera otro de una manera que Microsoft cambió más tarde para distinguir la emisión de Azure AD y MSA. Esto no creó la capacidad de firma original, pero hizo que la ruta de acceso fuera más útil y duradera.

La quinta condición facilitadora fue la inadecuada detección de anomalías del lado del proveedor. Microsoft dijo que el patrón de tokens del actor era obvio en retrospectiva porque ningún sistema legítimo de Microsoft firmaba tokens en esa combinación. Sin embargo, el proveedor no alertó sobre ese estado imposible o altamente anómalo antes de que un cliente informara sobre el comportamiento del buzón. La CSRB encontró que otros proveedores de nube tenían controles que Microsoft carecía y recomendó que los proveedores utilicen datos propietarios en los algoritmos de generación de tokens y señales de validación para detectar afirmaciones falsificadas incluso cuando una firma se verifica.

Fallos de detección y respuesta

La detección dependió de un cliente con una licencia premium, un análisis personalizado, operadores capacitados y la disposición a perseguir una alerta moderada que había generado falsos positivos antes. Ese es un control impresionante del Departamento de Estado. También es un modelo de seguridad sistémico inestable. No se puede esperar que miles de clientes reconstruyan el compromiso criptográfico de un proveedor a partir de eventos de buzón opcionales, especialmente cuando el evento necesario para esta campaña no estaba disponible para los usuarios de licencia estándar.

En ese momento, MailItemsAccessed estaba disponible a través de Microsoft Purview Audit Premium y requería licencias E5 o G5. El Departamento de Estado tenía G5 y pudo crear Big Yellow Taxi. Otras víctimas sin registro premium carecían de la misma visibilidad histórica. Por lo tanto, el aviso de CISA y el FBI instó a las organizaciones a habilitar el registro premium, al tiempo que señalaba explícitamente el requisito de licencia. Siete días después, Microsoft se comprometió a eliminar la barrera de nivel para los tipos de eventos clave. La directora de CISA, Jen Easterly, describió el cambio como un paso hacia la práctica de seguridad por diseño en ladeclaración de CISA del 19 de julio.

La respuesta también se vio limitada por la retención de evidencia del proveedor. Microsoft no tenía los registros necesarios para determinar cómo o cuándo se había robado la clave. Los períodos de treinta días limitaron la actividad más temprana observable del cliente, mientras que los eventos corporativos y de producción más antiguos necesarios para la hipótesis de 2021 no estaban disponibles. La retención de registros siempre conlleva obligaciones de costo, privacidad y control de acceso, pero un proveedor no puede afirmar de manera creíble que protege las joyas criptográficas de la corona si su horizonte de evidencia es más corto que el tiempo que los actores sofisticados pueden permanecer inactivos.

Finalmente, la corrección demorada del relato causal de septiembre fue una falla de respuesta. No permitió la intrusión original, pero perjudicó la garantía pública. Un informe posterior al incidente debe separar los hechos, las hipótesis evaluadas, la confianza, la evidencia contradictoria y las preguntas no resueltas. Publicar un mecanismo que sonaba completo y corregirlo solo seis meses después hizo más difícil para los clientes y supervisores determinar si la remediación abordó la ruta real.

El problema del registro y las licencias

A veces se trata el registro como una característica accesoria del producto. En este incidente fue un control de seguridad y una fuente de asimetría de información.

Microsoft poseía telemetría de todo el servicio y visibilidad interna del sistema de identidad no disponible para ningún cliente. Cada cliente solo podía observar su inquilino y solo los tipos de eventos incluidos en su suscripción y configuración. La alerta decisiva provino de MailItemsAccessed, un evento diseñado para mostrar cuándo se accedía a los elementos del buzón. CISA y el FBI declararon que no conocían ningún otro evento de auditoría que hubiera detectado esta actividad. Un cliente sin el evento aún podría notar señales contextuales, pero carecía de la misma superficie probatoria directa.

Esto crea un límite comercial problemático. Es razonable que los productos de seguridad premium cobren por análisis avanzados, automatización, retención prolongada e investigación gestionada. La evidencia mínima necesaria para saber si un servicio operado por el proveedor ha accedido a los datos del cliente es diferente. Cuando un proveedor controla por sí solo el sistema y un cliente debe pagar un extra para observar el acceso resultante del propio fallo de identidad del proveedor, se le pide al cliente que compre visibilidad sobre un riesgo que no puede remediar directamente.

El cambio posterior al incidente reconoce esa distinción. Microsoft se comprometió a poner a disposición registros de seguridad en la nube más amplios en todo el mundo sin costo adicional, agregar eventos detallados de acceso al correo electrónico a Audit Standard y duplicar la retención estándar predeterminada a 180 días. En febrero de 2024, CISA, la Oficina de Administración y Presupuesto, la Oficina del Director Nacional de Ciberseguridad y Microsoft anunciaron que el registro ampliado se estaba poniendo a disposición de todas las agencias federales que utilizan Purview Audit, independientemente del nivel, con habilitación automática y la retención predeterminada más larga. Elanuncio de implementación conjuntaenmarcó los registros de auditoría de alta calidad sin cargo ni configuración adicional como una expectativa de seguridad por diseño.

La reforma no elimina la responsabilidad del cliente. Los registros deben enrutarse a sistemas de búsqueda, retenerse según los requisitos legales y de riesgo, establecer líneas base, consultarse y conectarse a procedimientos de respuesta. El aviso de CISA recomienda exactamente esas medidas. Pero la disciplina operativa del cliente se vuelve significativa solo después de que el proveedor emite el evento relevante y lo hace accesible. La disponibilidad de telemetría y el uso de telemetría son dos controles separados propiedad de diferentes partes.

Las licencias también afectaron la igualdad forense entre las víctimas. El entorno G5 del Departamento de Estado tenía un registro histórico más sólido que los entornos de nivel estándar. Habilitar un evento después de un incidente no reconstruye lo que nunca se registró. Esto significa que la misma falla del proveedor puede producir diferentes niveles de confianza sobre el impacto según la suscripción del cliente, aunque ninguno de los clientes controlara la clave de firma subyacente. Por lo tanto, la evidencia forense mínima debe tratarse como parte de la línea base de seguridad del servicio, no simplemente como una venta adicional.

Impacto en los clientes federales y continuidad del sector público

El compromiso afectó al correo electrónico no clasificado, pero "no clasificado" no significa operativamente trivial. Los buzones de altos funcionarios contienen calendarios, deliberaciones políticas, redes de contactos, posiciones de negociación, borradores de lenguaje y el tejido conectivo ordinario del gobierno. Un servicio de inteligencia puede obtener valor de la agregación, el momento, las relaciones y el contexto sin obtener documentos formalmente clasificados.

El Departamento de Estado dijo más tarde que se descargaron aproximadamente 60,000 correos electrónicos de 10 cuentas. En suconferencia de prensa del 28 de septiembre de 2023, el Departamento describió el material afectado como no clasificado y dijo que ningún sistema de correo electrónico clasificado fue pirateado. La reconstrucción más amplia de la CSRB identificó más cuentas del Departamento de Estado accedidas, lo que refleja diferentes formas de contar el acceso a cuentas y el subconjunto desde el cual se descargaron mensajes. El artículo no infiere el contenido de los mensajes más allá de lo que las agencias divulgaron.

Los buzones oficiales y personales de la Secretaria de Comercio estuvieron entre los afectados, según la CSRB. La Cámara de Representantes de Estados Unidos también estuvo dentro del conjunto afectado, incluido el congresista Don Bacon. Unainvestigación del Comité de Supervisión de la Cámara de agosto de 2023solicitó informes al Departamento de Estado y al Departamento de Comercio sobre el descubrimiento, el impacto, la respuesta y la seguridad futura. Estos hechos establecen una exposición sensible del sector público y una preocupación de supervisión; no establecen que decisiones políticas específicas cambiaran debido a la intrusión.

La continuidad en este contexto tiene al menos cinco dimensiones.

Primero está la continuidad de la confidencialidad: los funcionarios necesitan una expectativa duradera de que las comunicaciones rutinarias en la nube no sean copiadas silenciosamente por un actor de inteligencia extranjero.

Segundo está la continuidad de las decisiones: los equipos que preparan viajes diplomáticos o políticas económicas deben poder deliberar sin asumir que el adversario tiene acceso contemporáneo a su correo.

Tercero está la continuidad probatoria: las agencias necesitan suficientes datos retenidos para reconstruir quién accedió a qué y cuándo. Sin ellos, los líderes no pueden delimitar con confianza el incidente o decidir qué relaciones y decisiones requieren revalidación.

Cuarto está la continuidad de la respuesta: un compromiso del proveedor obliga a las agencias a desviar capacidad de seguridad, legal, diplomática, de registros y de liderazgo. Incluso cuando el correo electrónico permanece disponible, el trabajo de misión absorbe un impuesto oculto de respuesta a incidentes.

Quinto está la continuidad de la confianza: la adopción federal de servicios en la nube compartidos depende de la garantía de que el proveedor detectará fallas en su propio plano de control, las divulgará con precisión y proporcionará a los clientes evidencia utilizable. Un servicio puede cumplir un objetivo de tiempo de actividad mientras falla esta prueba de continuidad más amplia.

El incidente también expuso el riesgo de concentración. Microsoft proporciona servicios de identidad, correo electrónico, productividad, sistema operativo, seguridad y nube en gran parte del gobierno y el sector privado. La integración puede mejorar la gestión y la detección, pero también puede permitir que un solo defecto de identidad del lado del proveedor cruce los límites organizacionales a escala global. La CSRB describió la centralidad de Microsoft como una razón para exigir los más altos estándares de seguridad, responsabilidad y transparencia.

La concentración no lleva automáticamente a la conclusión de que cada agencia deba abandonar Microsoft o mantener sistemas de correo electrónico duplicados. La migración en sí misma crea costo y riesgo, y múltiples proveedores pueden reproducir debilidades de identidad similares. La conclusión más sólida es que las adquisiciones y la supervisión deben valorar explícitamente el fallo de identidad de modo común: la segmentación de claves, la detección de anomalías del lado del proveedor, el acceso a auditorías, la retención de evidencia, la notificación de incidentes, las pruebas independientes y los arreglos de salida o continuidad deben tratarse como requisitos del servicio.

Los hallazgos de la CSRB y por qué importan

Lapágina de publicación de la CSRBdescribe el informe como una revisión independiente de decisiones operativas y estratégicas y dice que recomienda prácticas para la industria y el gobierno. Sus hallazgos centrales son severos pero específicos.

La Junta concluyó que la cultura de seguridad de Microsoft era inadecuada y requería una revisión. Basó esa conclusión en la cascada evitable, la falla en detectar el compromiso de una clave de firma crítica, la dependencia de un cliente para el descubrimiento, la comparación con los controles de otros proveedores, el compromiso del dispositivo adquirido en 2021, la corrección demorada de declaraciones públicas inexactas y un compromiso separado de estado-nación en 2024 que estaba fuera del alcance de esta revisión. El hallazgo es organizacional porque ningún error de codificación único explica por qué la clave siguió siendo aceptada, por qué falló la separación de dominios, por qué los patrones de tokens imposibles no alertaron, por qué la evidencia no estaba disponible y por qué una afirmación causal superó a la prueba.

La Junta también proporcionó contrafactuales concretos. Si la rotación manual no se hubiera detenido sin un reemplazo automatizado completado, o si una alerta de clave antigua hubiera forzado la acción, la clave de 2016 no habría seguido siendo válida en 2023. Si la validación de consumidor y empresarial se hubiera separado correctamente, el alcance del actor habría sido mucho más limitado y no habría incluido a los clientes empresariales. Si Microsoft hubiera detectado tokens que no se ajustaban a su propio algoritmo de generación, la campaña podría haber sido bloqueada o detectada del lado del proveedor. Si hubiera existido una retención forense más sólida, Microsoft podría haber respondido a la pregunta de la adquisición de la clave.

Esos contrafactuales demuestran un principio de seguridad en capas. La intrusión no requirió que todos los controles fallaran de la misma manera. Cualquiera de varios controles independientes podría haber evitado el compromiso empresarial o acortarlo materialmente:

• La custodia segura podría haber evitado la pérdida de la clave.
• La rotación automática frecuente podría haber hecho que la clave robada fuera inutilizable antes de 2023.
• La validación consciente del alcance podría haber confinado una clave de consumidor a los servicios de consumidor.
• Las comprobaciones de tokens con estado o propietarias podrían haber detectado un token que Microsoft mismo nunca emitiría.
• La supervisión de todo el proveedor podría haber sacado a la superficie la combinación imposible de firma-dominio.
• Los registros de cliente de referencia podrían haber permitido a más víctimas detectar y delimitar el acceso.
• Una retención más prolongada del proveedor podría haber mejorado la confianza en la causa raíz.

Por eso la ruta de robo no resuelta no impide el análisis de responsabilidad. Lo desconocido es importante, pero varios fallos independientemente suficientes o limitadores del impacto están documentados. Un proveedor no puede responder a un eslabón de causa raíz faltante tratando toda la cadena como incognoscible.

Las recomendaciones de la Junta se extendieron más allá de Microsoft. Pidieron prácticas modernas de gestión de claves, rotación automatizada y frecuente, claves protegidas por hardware, bibliotecas de autenticación comunes, estándares de identidad digital más sólidos, registro mínimo para clientes sin tarifas adicionales, al menos seis meses de registros accesibles para el cliente apropiados, mejor notificación a las víctimas y divulgación más transparente de vulnerabilidades en la nube. Estas medidas abordan una estructura de la industria en la que los proveedores tienen tanto el control privilegiado como la mejor evidencia.

Respuesta de Microsoft

La respuesta inmediata de Microsoft corrigió los defectos conocidos del validador y de renovación, bloqueó la clave robada, revocó las claves de firma MSA activas en ese momento, trasladó las claves de consumidor hacia el almacén de claves empresarial reforzado, aumentó el aislamiento y refinó la supervisión del sistema de claves. Esas acciones abordaron directamente la campaña observada. Microsoft también notificó a las organizaciones afectadas y publicó indicadores de infraestructura para los defensores.

Luego, la compañía realizó un cambio de control comercial al ampliar el acceso a la auditoría. Esa acción es observable de forma independiente en el compromiso del producto y el despliegue federal, aunque la integridad práctica de la cobertura de eventos todavía depende del servicio, la configuración, la retención y las operaciones del cliente.

En noviembre de 2023, Microsoft lanzó la Iniciativa de Futuro Seguro (Secure Future Initiative). Suanuncio inicial de SFIse comprometió a un sistema unificado y completamente automatizado de gestión de claves de consumidor y empresarial utilizando computación confidencial y módulos de seguridad de hardware, con una arquitectura diseñada para mantener las claves inaccesibles incluso cuando los procesos subyacentes estén comprometidos. Una publicación de ingeniería complementaria se comprometió a la rotación automatizada de alta frecuencia sin acceso humano.

Después del informe de la CSRB y una intrusión separada de un estado ruso en el correo electrónico corporativo de Microsoft, la compañía amplió la SFI en mayo de 2024. Elprograma ampliadoestableció objetivos que incluyen la rotación automática rápida y la protección de hardware para las claves de firma, SDK de identidad estándar en todas las aplicaciones, validación con estado y duradera para tokens de identidad, partición más fina de claves, eliminación de pivotes laterales de identidad, retención de dos años para registros de seguridad y seis meses de registros apropiados para los clientes. También dijo que parte de la compensación del liderazgo sénior dependería de los hitos de seguridad.

En junio de 2024, el Vicepresidente y Presidente de Microsoft, Brad Smith, dijo al Comité de Seguridad Nacional de la Cámara que la compañía aceptaba la responsabilidad por cada problema citado en el informe de la CSRB. Sutestimonio escritodijo que Microsoft estaba actuando sobre las 16 recomendaciones de la Junta aplicables a la compañía, había dedicado el equivalente a 34,000 ingenieros a tiempo completo a la SFI, estaba haciendo la transición de los sistemas de identidad de consumidor y empresarial a un sistema de gestión de claves respaldado por hardware, y había progresado en la rotación automatizada, las bibliotecas de autenticación comunes y las señales de validación de tokens. Elregistro de la audiencia del Congresoproporciona el contexto de supervisión pública y el interrogatorio.

Para septiembre de 2024, Microsoft informó sobre un Consejo de Gobernanza de Ciberseguridad, directores adjuntos de seguridad de la información para las divisiones de ingeniería, la seguridad en las evaluaciones de desempeño de los empleados y revisiones periódicas ejecutivas y de la junta. Laactualización de progreso de SFIde la compañía es evidencia de cambios de gobernanza y del progreso de implementación declarado.

Estas respuestas son compromisos sustanciales. Aun así, deben describirse como compromisos y progreso informado por la compañía donde la verificación independiente no es pública. La CSRB recomendó arquitecturas y controles específicos, pero no certificó su finalización posterior. Un estándar de cierre creíble requeriría una cobertura medible de rotación de claves, evidencia de que los validadores heredados han sido retirados, pruebas que muestren que los límites de consumidor y empresarial fallan de manera cerrada, telemetría retenida suficiente para investigar eventos clave y garantía externa de que las excepciones no pueden persistir silenciosamente.

Responsabilidad por capacidad de control

Un mapa de responsabilidad útil comienza con quién podía prevenir, detectar, limitar o acortar cada falla.

Microsoft controlaba la generación, el almacenamiento, la rotación, la retirada y el conjunto de confianza de producción de las claves. Controlaba la arquitectura de metadatos comunes, las bibliotecas auxiliares, el validador de Exchange Online, la interfaz de renovación de tokens de OWA y la lógica de detección en todo el servicio. Controlaba la retención de evidencia interna de producción y corporativa. También controlaba la precisión y el momento de las divulgaciones técnicas públicas. La responsabilidad por esas superficies recae principalmente en Microsoft.

El Departamento de Estado controlaba su supervisión de inquilinos, la lógica de alerta personalizada, el triaje, la escalada y la coordinación con CISA y el FBI. Realizó esas tareas de manera lo suficientemente efectiva como para descubrir una intrusión a nivel de proveedor. Otros clientes controlaban su propia supervisión y respuesta dentro de la telemetría disponible para ellos. La responsabilidad del cliente sigue siendo real, pero no puede sustituir los controles del proveedor que los clientes no pueden ver ni cambiar.

CISA, OMB y los funcionarios de adquisiciones de agencias controlaban partes de la línea base federal: requisitos de registro, orientación de configuración, expectativas contractuales, coordinación entre agencias y la influencia para exigir valores predeterminados más seguros. Su trabajo de registro posterior al incidente redujo una inequidad. Un régimen de adquisiciones maduro no debería depender de una crisis para establecer que los clientes necesitan acceso a la evidencia de acceso a buzones.

Storm-0558 controló la operación hostil y tiene la responsabilidad de la intrusión. Ese hecho obvio no borra la prevenibilidad. Las investigaciones de seguridad examinan rutinariamente por qué una entrada maliciosa o peligrosa alcanzó los sistemas protegidos a pesar de la culpabilidad del actor. La atribución y la responsabilidad defensiva responden preguntas diferentes.

Las juntas corporativas y los ejecutivos controlan la asignación de recursos, la aceptación de riesgos, los incentivos y los plazos. La pausa en la rotación manual de claves después de una interrupción no fue meramente un error de ingeniería aislado; la consecuencia de seguridad persistió porque la automatización y las alertas no recibieron o mantuvieron suficiente prioridad. La posterior decisión de Microsoft de vincular la compensación del liderazgo a los hitos de seguridad reconoce implícitamente que el nivel de control relevante se extiende por encima del equipo que escribió el validador.

La asignación no debe convertirse mecánicamente en un porcentaje de responsabilidad legal. Los contratos, la inmunidad soberana, los daños, la causalidad, los deberes de divulgación y la jurisdicción regulatoria varían. Lasolicitud de julio de 2023del senador Ron Wyden pidió al Departamento de Justicia, a la Comisión Federal de Comercio y a la CSRB que investigaran las prácticas de Microsoft. Esa solicitud es evidencia de preocupación regulatoria, no evidencia de que las agencias requeridas hayan llegado a un hallazgo de ejecución. Ningún registro público utilizado aquí establece un juicio legal definitivo para Storm-0558.

Lo que la remediación duradera debe demostrar

El incidente debe considerarse operativamente cerrado solo en relación con la técnica observada de la clave de 2016. El problema de garantía más amplio permanece abierto hasta que la remediación pueda demostrarse en varias dimensiones.

Custodia y ciclo de vida de las claves

Microsoft debe poder demostrar que las claves de firma de consumidor y empresarial se generan y utilizan dentro de sistemas protegidos por hardware, no pueden exportarse a entornos de depuración o corporativos generales, rotan automáticamente a una frecuencia proporcional a su poder y generan alertas accionables cuando la antigüedad o las excepciones de política exceden los límites. La rotación de emergencia debe ejercerse sin causar el tipo de interrupción que llevó a la pausa de 2021. La segmentación de claves debe reducir el número de inquilinos, servicios y clases de cuentas expuestos por cualquier clave única.

Corrección de la validación

Cada servicio de confianza debe usar bibliotecas aprobadas que validen la firma, el emisor, la audiencia, el inquilino, la clase de cuenta, el emisor de la clave, la vida útil y la autorización específica del servicio. Ladocumentación de OpenID Connectde Microsoft explica que los metadatos de descubrimiento exponen los puntos finales del proveedor y las claves de firma públicas; no hace que cada clave listada sea intercambiable para cada recurso. Las pruebas de conformidad deben presentar intencionalmente tokens correctamente firmados pero con alcance incorrecto y verificar el rechazo.

Resistencia a la falsificación más allá de las firmas sin estado

Un token de portador basado solo en firma puede seguir siendo convincente después de que la clave de firma es robada. La validación con estado, los enfoques de prueba de posesión, los marcadores de emisión propietarios, las vidas útiles limitadas y la revocación rápida pueden reducir ese riesgo. El objetivo no es abandonar los estándares, sino garantizar que la posesión de una clave no cree una autoridad global no observable.

Telemetría del proveedor y del cliente

El proveedor debe detectar combinaciones de tokens imposibles en todo el servicio y preservar la evidencia interna el tiempo suficiente para campañas sofisticadas. Los clientes deben recibir eventos de acceso a buzones e identidad de forma predeterminada, sin una barrera premium, en un esquema documentado que pueda exportarse a herramientas de análisis independientes. Seis meses de registros accesibles para el cliente, como lo recomienda la CSRB y se adoptó como objetivo de SFI, deben ser un piso para la actividad de identidad en la nube de alto valor, en lugar de un techo aspiracional.

Comunicación de incidentes

Las divulgaciones técnicas deben llevar historial de versiones, niveles de confianza y preguntas explícitas no resueltas. Cuando una hipótesis publicada pierde apoyo probatorio, la corrección debe ser rápida y prominente. Un proveedor no debe requerir que un organismo de supervisión pregunte repetidamente si se modificará un relato de causa raíz inexacto.

Garantía independiente

Los informes de progreso de la compañía son útiles pero insuficientes para un plano de control con dependencia del sector público. Los clientes federales necesitan mecanismos de garantía que puedan probar la rotación, el aislamiento de claves, la cobertura del validador, el rendimiento de las alertas y la retención forense sin exponer secretos. El punto no es la publicación de arquitectura sensible. Es la evidencia de que los controles declarados operan en producción, incluidos los sistemas heredados y los entornos adquiridos.

Lecciones prácticas para clientes de la nube y compradores públicos

Los clientes no pueden reparar el sistema de firma de un proveedor, pero pueden hacer que la dependencia sea más gobernable.

Primero, adquirir evidencia, no solo características. Los contratos y las líneas base de servicio deben identificar qué eventos de acceso, identidad, administración, tokens y buzones están disponibles; qué tan rápido llegan; cuánto tiempo permanecen buscables; y si los clientes pueden exportarlos. El registro debe probarse con eventos simulados antes de un incidente.

Segundo, construir análisis en torno al acceso a datos, así como al inicio de sesión. Un token falsificado puede eludir las anomalías que los defensores esperan del robo de contraseñas. MailItemsAccessed importó porque observó la acción protegida, no simplemente la ceremonia de autenticación. Los entornos de alto valor deben establecer líneas base de acceso inusual a buzones, identificadores de aplicación, geografía, comportamiento del cliente y volumen de acceso.

Tercero, mantener una ruta de escalada que asuma que el proveedor puede ser parte del incidente. Un equipo de inquilino debe saber cómo comunicarse con la organización de respuesta de seguridad del proveedor, CISA o la autoridad nacional relevante, las fuerzas del orden y el liderazgo ejecutivo sin depender del canal de correo potencialmente comprometido.

Cuarto, tratar la concentración de identidad como un riesgo de continuidad. Los compradores deben saber qué servicios críticos comparten una raíz de identidad, qué podría alcanzar un compromiso de clave de todo el proveedor y qué funciones pueden continuar mientras se restablece la confianza en la nube. Esto puede justificar la segmentación, identidades administrativas separadas, almacenamiento de registros independiente o diversidad selectiva para los flujos de trabajo más sensibles.

Quinto, probar los compromisos de notificación y evidencia del proveedor. Una promesa de notificar a los "clientes afectados" es tan útil como la capacidad del proveedor para identificarlos. En Storm-0558, solo Microsoft podía identificar a la mayoría de las víctimas porque los tokens falsificados operaban dentro de su servicio. Eso hace que la telemetría de todo el proveedor y el alcance oportuno sean parte de la arquitectura de detección del cliente.

Finalmente, no confundir la responsabilidad compartida con la capacidad igual. Los clientes deben asegurar lo que controlan. Los proveedores deben ser responsables de los controles exclusivos del proveedor. Los reguladores y compradores deben centrarse en el límite entre ellos, porque es donde los requisitos de seguridad tienen más probabilidades de volverse ambiguos, opcionales o monetizados.

Evaluación

La intrusión de Storm-0558 en Exchange Online fue un fallo de identidad en la nube prevenible con una ruta inicial de adquisición de clave no resuelta. La evidencia pública respalda un hallazgo de alta confianza de que Microsoft permitió que una antigua clave de firma de consumidor siguiera siendo de confianza, no hizo cumplir el límite entre la validación de tokens de consumidor y empresarial, carecía de suficiente detección del lado del proveedor para combinaciones de tokens que sus propios sistemas no emitirían y retuvo muy poca evidencia para reconstruir la fuga de la clave. También respalda un hallazgo de que el registro de clientes con barrera premium moldeó materialmente quién podía detectar e investigar la campaña.

La respuesta de Microsoft abordó la ruta de acceso observada y luego se expandió a reformas de gestión de claves, validación, registro, gobernanza e incentivos. La aceptación de Brad Smith de los hallazgos de la CSRB es significativa. También lo son la eliminación del muro de pago de registro para eventos centrales y el movimiento hacia la rotación automatizada respaldada por hardware. La pregunta de responsabilidad restante es si estos cambios son completos, duraderos y verificables de forma independiente en toda la infraestructura de identidad actual y heredada de Microsoft.

La lección más amplia del incidente no es que los servicios en la nube sean inherentemente menos seguros que los sistemas operados por el cliente. Los grandes proveedores pueden implementar controles, inteligencia y remediación a una escala que la mayoría de los clientes no pueden. La lección es que la escala también concentra autoridad oculta. Cuando una sola clave de firma y un solo error de validación pueden llegar a organizaciones de todo el mundo, la seguridad depende de la disciplina interna de claves del proveedor y de una evidencia que los clientes no pueden generar por sí mismos.

Por lo tanto, la continuidad del sector público requiere una definición más amplia de confiabilidad del servicio. La disponibilidad es necesaria, pero también lo son la confidencialidad, la identidad confiable, la evidencia reconstruible, la divulgación rápida y una ruta creíble para restaurar la confianza después de un compromiso del lado del proveedor. Storm-0558 dejó Exchange Online en funcionamiento. Aun así, interrumpió la premisa sobre la cual los gobiernos lo usaban. Es por eso que el incidente pertenece al registro como un fallo de responsabilidad en la nube en lugar de simplemente otra operación de espionaje exitosa.