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 derrotó 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 por consumidores llegaran al correo empresarial de Exchange Online.
• La ruta de adquisición de la clave sigue sin resolverse. La explicación del volcado de memoria de septiembre de 2023 de Microsoft 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. La clave obsoleta, el defecto de validación entre dominios, la detección débil de anomalías en tokens y la retención forense limitada son hallazgos de fallo mejor respaldados.
• 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 de tokens imposibles en su nube, preservar la evidencia interna relevante y cerrar el vector de ataque. Los clientes podían mejorar el monitoreo y la respuesta, pero en 2023 la telemetría decisiva MailItemsAccessed estaba ligada a licencias E5/G5 de mayor precio.

Un fallo de control de identidad, no una violación de buzón convencional

La intrusión de Storm-0558 es fácil de comprimir en una frase familiar: hackers chinos robaron una clave de Microsoft y leyeron correos gubernamentales. Esa frase es direccionalmente cierta y analíticamente inadecuada. Fusiona el acto del atacante, la pérdida no resuelta de material criptográfico por parte de Microsoft, un fallo de validación de software separado, una decisión de ciclo de vida de clave obsoleta, un éxito de detección del lado del cliente y una 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 del gobierno entregando una contraseña, una agencia que no implementó 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, o MSA, creada en 2016. Una clave de firma privada permite a su titular producir tokens cuyas firmas pueden verificarse contra 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 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 Microsoft de julio de 2023explica 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ó el correo a través de la API de OWA. Microsoft dijo que un fallo de diseño también permitió al actor obtener nuevos tokens de acceso presentando uno emitido previamente por esa interfaz. Esto no fue simplemente una reproducción de credencial robada. Fue la fabricación y renovación no autorizadas de credenciales que los servicios de Microsoft trataron como válidas.

La distinción es importante para la responsabilidad en la nube. Los clientes suelen ser responsables de sus identidades, higiene de dispositivos, permisos, configuración de aplicaciones y respuesta a incidentes. Pero un cliente no puede inspeccionar o rotar el material de firma raíz de un proveedor de nube, parchear el validador de tokens de producción del proveedor o implementar un detector dentro del plano de emisión de identidad del proveedor.

Cuando el fallo se origina en controles disponibles solo para el proveedor, describir el evento como un problema de responsabilidad compartida sin especificar quién controlaba cada salvaguarda 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 comunicaciones confiables, 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 usó una clave de firma de consumidor de MSA de 2016 creada por Microsoft para falsificar tokens; que un fallo de validación de Microsoft permitió que esos tokens accedieran a cuentas empresariales de Exchange Online; que el Departamento de Estado encontró actividad sospechosa a través de registros mejorados de acceso al buzón; y que Microsoft mitigó la técnica conocida mediante una secuencia 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 convergen en esos puntos.

Segundo, la Junta de Revisión de Seguridad Cibernética, o CSRB, hizo hallazgos sobre la prevenibilidad, el diseño de controles, la cultura de seguridad, la divulgación y la práctica de la industria. Surevisión completa de la intrusión del verano de 2023concluyó que el incidente era prevenible y nunca debería haber ocurrido. La Junta entrevistó a 20 organizaciones, recibió la cooperación de Microsoft, comparó controles en otros proveedores importantes de servicios en la nube y encontró una cascada de fallos evitables. Esos son hallazgos de revisión independiente, no hallazgos 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 que 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 del volcado de memoria en septiembre de 2023, luego añadió una corrección en marzo de 2024 indicando que no había encontrado un volcado que contuviera el material de la clave afectada. El CSRB informó que Microsoft exploró 46 hipótesis de robo de claves y aún no sabía cómo ni cuándo el actor obtuvo la clave. Cualquier relato que presente el volcado de memoria como la causa raíz probada exagera la evidencia.

Tampoco el registro establece una asignación legal final de pérdidas. El escrutinio del Congreso, las solicitudes de investigación y la aceptación por parte de Microsoft de los hallazgos del CSRB son relevantes para la responsabilidad. No sustituyen un fallo judicial, una decisión de ejecución de la agencia, una interpretación contractual o un análisis cuantificado de daños. La conclusión adecuada es más limitada: Microsoft controlaba varias salvaguardas fallidas y aceptó la responsabilidad por los problemas citados por el 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 la custodia continua y cuando la rotación limita la vida útil del material robado. El CSRB encontró que el sistema de consumidor MSA 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 el CSRB, Microsoft detuvo la rotación manual de claves de firma de consumidor en 2021 después de una importante interrupción de la nube asociada con el proceso manual. No implementó entonces un reemplazo de rotación automática ni una alerta que notificara a los equipos responsables sobre claves activas envejecidas. Por lo tanto, la clave de 2016 seguía siendo aceptada en 2023.

Esta es una decisión clásica 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 perpetúa la exposición de seguridad indefinidamente.

El hallazgo de la Junta es más útil que decir simplemente que una clave "expirada" funcionó. Una clave se acepta o rechaza según la configuración de confianza en vivo del servicio. El fallo crucial fue que una clave destinada a ser retirada permaneció dentro del conjunto de confianza. Laguía actual de rotación de claves de firma de Microsoftdice 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 se aplica de manera más amplia: el reemplazo de claves debe ser una capacidad diseñada, no una ceremonia frágil que se vuelve demasiado arriesgada de realizar.

En septiembre de 2018, Microsoft introdujo un punto final común de publicación de metadatos de clave en respuesta a la demanda de aplicaciones que sirvieran tanto a usuarios de consumidor 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 punto final de metadatos común en 2022.

Los desarrolladores asumieron que la biblioteca realizaba una validación completa y no añadieron la verificación requerida del emisor o el alcance. Por lo tanto, el punto final común aumentó la interoperabilidad al tiempo que creaba un peligro en el límite de confianza: la validez criptográfica se confundió con la autorización dentro del dominio de identidad correcto.

La reconstrucción del 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 de servicios de Azure e identidad.

La Junta criticó a Microsoft por no detectar el dispositivo comprometido de la empresa adquirida antes de permitirle entrar en la red corporativa.

Esta compromiso de 2021 es evidencia de acceso e interés del atacante. No es una 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 produjo evidencia específica que la vinculara con el robo de la clave. Un relato disciplinado debe preservar esa brecha.

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

Storm-0558 estableció infraestructura externa identificada y comenzó a acceder a cuentas específicas de Exchange Online el 15 de mayo de 2023. El 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 limitaba la vista retrospectiva disponible una vez que comenzó la investigación. "Primera vista" es, por lo tanto, un límite probatorio, no necesariamente el comienzo real del ataque.

Los objetivos reflejaban prioridades de espionaje. El recuento final del CSRB identificó a 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 los EE. UU. 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 de incidente del 11 de julio de Microsoftse refería a aproximadamente 25 organizaciones y cuentas de consumidor relacionadas. La diferencia se trata mejor como un cambio en la contabilidad del incidente entre un aviso temprano de la compañía y la reconstrucción independiente posterior, 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 de Estado 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 de Estado investigó a pesar de la posibilidad de falsos positivos y contactó a Microsoft ese mismo día.

Para el 19 de junio, el Departamento de Estado había determinado que seis cuentas habían sido accedidas, incluidas cuentas asociadas con los preparativos del viaje del Secretario de Estado a Pekín. Identificó seis cuentas adicionales accedidas entre el 21 y el 24 de junio y otra más a través del 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 emitidos correctamente robados. Sus analistas vieron entonces que los artefactos de autenticación de Exchange Online no correspondían a tokens de Azure AD en los registros esperados.

El 26 de junio aproximadamente, Microsoft determinó que el actor estaba utilizando la clave de consumidor de 2016 para crear tokens que funcionaban contra el correo de consumidor y empresarial.

Elaviso conjunto CISA-FBI AA23-193Aes inusualmente directo sobre la asignación de 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-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 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 más acceso 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 de 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 de consumidor afectados para 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 implicar 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 girar hacia el phishing y otras técnicas después de que se bloqueara la ruta de falsificación de tokens conocida, 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 la ruta de adquisición original fuera identificada o que el actor nunca obtuviera otro material sensible. El CSRB dijo explícitamente que la posibilidad de acceso a otras claves y datos seguía sin resolverse.

Julio 2023-Marzo 2024: divulgación, reforma del registro y una afirmación corregida de la causa raíz

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, tras 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 de 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 material 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 entrara en el volcado; que el volcado se trasladó 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ó posteriormente una cuenta de ingeniero con acceso a ese entorno.

Debido a que los registros relevantes habían caducado, Microsoft llamó a esto 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 versionado de Microsoftcomienza ahora con una actualización del 12 de marzo de 2024. La compañía dice que su hipótesis principal sigue siendo que errores operativos hicieron que el material de la clave saliera del entorno de firma seguro y que el material fue accedido a través de una cuenta de ingeniería comprometida. También dice que no encontró un volcado de memoria que contuviera la clave impactada, que la condición de carrera citada afectaba a si un volcado podía salir del entorno de firma en lugar de a si el material de la clave podía estar presente, y que la eliminación de dicho material no era un proceso estándar pero no estaba prohibida en ese momento.

La corrección cambia el estatus epistémico del relato. Una hipótesis plausible no es un hallazgo de causa raíz. El 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 tras repetidas preguntas de la Junta. Este retraso 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 se 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 de MSA de 2016 robada para crear tokens y presentarlos a través de 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 reportada por Microsoft y el CSRB; este artículo no atribuye de forma independiente el mando estatal.

Causas raíz técnicas y condiciones habilitantes

La primera pregunta de causa raíz, cómo la clave privada escapó del control de Microsoft, está sin resolver. 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 seguía siendo de confianza. La rotación manual de claves de consumidor se detuvo en 2021 tras una interrupción, el reemplazo automático no estaba listo y ninguna alerta efectiva de antigüedad forzó la 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 el fallo de alcance en la validación de tokens. El servicio verificó una firma contra el material de clave disponible a través de metadatos comunes, pero no probó adecuadamente que el dominio de identidad de la clave estuviera autorizado para el recurso empresarial solicitado. Ladocumentación actual de validación de tokens de acceso de Microsoftdice 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 tení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 fallo de diseño en la renovación de tokens de OWA. Una vez que la identidad falsificada fue aceptada a través de un flujo legítimo, GetAccessTokenForResource permitía que un token obtuviera otro de una manera que Microsoft cambió posteriormente 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 habilitante fue la detección inadecuada 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 del comportamiento en el buzón.

El CSRB encontró que otros proveedores de nube tenían controles de los que Microsoft carecía y recomendó que los proveedores usaran datos propietarios en algoritmos de generación de tokens y señales de validación para detectar afirmaciones falsificadas incluso cuando una firma verifica.

Fallos de detección y respuesta

La detección dependió de un cliente con una licencia premium, un análisis personalizado, operadores cualificados y la voluntad de perseguir una alerta moderada que había generado falsos positivos antes. Eso es un control impresionante del Departamento de Estado. También es un modelo de seguridad inestable para todo el sistema. 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 podía 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 desde el 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. Las ventanas de 30 días limitaban 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 si su horizonte de evidencia es más corto que el tiempo que los actores sofisticados pueden permanecer en silencio.

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

El problema del registro y las licencias

El registro a veces se trata como una característica auxiliar 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. Los productos de seguridad premium pueden cobrar razonablemente 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 un proveedor ha accedido a los datos del cliente es diferente. Cuando un proveedor controla por sí solo el sistema y un cliente debe pagar extra para observar el acceso resultante del propio fallo de identidad del proveedor, se le pide al cliente que compre visibilidad de 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, añadir 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 Gestión y Presupuesto, la Oficina del Director Cibernético Nacional y Microsoft anunciaron que el registro ampliado estaría disponible para todas las agencias federales que utilizaran 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 costo adicional ni configuración como una expectativa de seguridad desde el diseño.

La reforma no elimina la responsabilidad del cliente. Los registros deben enrutarse a sistemas con capacidad de búsqueda, retenerse según los requisitos de riesgo y legales, 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 solo se vuelve significativa 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 pertenecientes a diferentes partes.

Las licencias también afectaron a 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 el mismo fallo del proveedor puede producir diferentes niveles de confianza sobre el impacto según la suscripción del cliente, aunque ninguno de los clientes controlaba la clave de firma subyacente. Por lo tanto, la evidencia forense mínima debería tratarse como parte de la línea base de seguridad del servicio, no meramente 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 horarios, deliberaciones políticas, redes de contactos, posiciones negociadoras, borradores de lenguaje y el tejido conectivo ordinario del gobierno. Un servicio de inteligencia puede obtener valor de la agregación, la sincronización, 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 susesión informativa 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 hackeado. La reconstrucción más amplia del CSRB identificó más cuentas del Departamento de Estado accedidas, lo que refleja diferentes formas de contar el acceso a cuentas y el subconjunto del que se descargaron mensajes. El artículo no infiere el contenido de los mensajes más allá de lo que las agencias divulgaron.

Los buzones oficial y personal de la Secretaria de Comercio estuvieron entre los afectados, según el CSRB. La Cámara de Representantes de los EE. UU. también estuvo dentro del conjunto afectado, incluido el Congresista Don Bacon. Unainvestigación del Comité de Supervisión de la Cámara de Representantes de agosto de 2023solicitó sesiones informativas a los Departamentos de Estado y 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, 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, la continuidad de la decisión: 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, la continuidad probatoria: las agencias necesitan suficientes datos retenidos para reconstruir quién accedió a qué y cuándo. Sin ello, los líderes no pueden delimitar con confianza el incidente o decidir qué relaciones y decisiones requieren revalidación.

Cuarto, 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 sigue disponible, el trabajo de misión absorbe un impuesto oculto de respuesta a incidentes.

Quinto, la continuidad de la confianza: la adopción federal de servicios compartidos en la nube depende de la garantía de que el proveedor detectará fallos en su propio plano de control, los 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 más amplia de continuidad.

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. El 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 costos y riesgos, y múltiples proveedores pueden reproducir debilidades de identidad similares.

La conclusión más sólida es que la adquisición 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 la auditoría, la retención de evidencia, la notificación de incidentes, las pruebas independientes y los acuerdos de salida o continuidad deben tratarse como requisitos del servicio.

Los hallazgos del CSRB y por qué importan

Lapágina de publicación del CSRBdescribe el informe como una revisión independiente de las 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, el fallo 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 tardía de declaraciones públicas inexactas y un compromiso separado de un 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 permaneció 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 se adelantó a la prueba.

La Junta también proporcionó contrafactuales concretos. Si la rotación manual no se hubiera pausado sin un reemplazo automatizado completado, o si una alerta de clave envejecida 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 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 haberlo acortado materialmente:

• La custodia segura podría haber evitado la pérdida de la clave.
• La rotación automática frecuente podría haber dejado la clave robada 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.
• El monitoreo en todo el proveedor podría haber sacado a la superficie la combinación imposible de dominio de firma.
• Los registros de cliente de línea base podrían haber permitido a más víctimas detectar y delimitar el acceso.
• Una retención más larga por parte 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 documentados son independientemente suficientes o limitadores del impacto. Un proveedor no puede responder a un eslabón perdido de la causa raíz 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 cargos adicionales, al menos seis meses de registros apropiados accesibles para los clientes, mejor notificación a las víctimas y una divulgación más transparente de las vulnerabilidades en la nube. Estas medidas abordan una estructura industrial en la que los proveedores tienen tanto el control privilegiado como la mejor evidencia.

La respuesta de Microsoft

La respuesta inmediata de Microsoft corrigió los fallos conocidos del validador y de renovación, bloqueó la clave robada, revocó las claves de firma de MSA entonces activas, trasladó las claves de consumidor hacia el almacén de claves empresarial reforzado, aumentó el aislamiento y refinó el monitoreo 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 hizo un cambio de control comercial al ampliar el acceso a la auditoría. Esa acción es observable independientemente 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 (SFI). Suanuncio inicial de SFIse comprometió a un sistema unificado y totalmente 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 del CSRB y de una intrusión separada del estado ruso en el correo electrónico corporativo de Microsoft, la compañía amplió SFI en mayo de 2024. Elprograma ampliado de Microsoftestableció objetivos que incluyen la rotación automática rápida y la protección por 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 de claves más fina, eliminación de pivotes de identidad laterales, 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 de los altos directivos 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 de Representantes que la compañía aceptaba la responsabilidad por cada problema citado en el informe del 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 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 las preguntas.

Para septiembre de 2024, Microsoft informó de un Consejo de Gobernanza de Ciberseguridad, subdirectores de seguridad de la información para las divisiones de ingeniería, seguridad en las evaluaciones de desempeño de los empleados y revisión regular ejecutiva y del consejo. Laactualización de progreso de SFI de Microsoftes evidencia de cambios en la gobernanza y del progreso declarado en la implementación.

Estas respuestas son compromisos sustanciales. Deben describirse como compromisos y progreso reportado por la compañía donde la verificación independiente no es pública. El 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 segura, 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 fallo.

Microsoft controlaba la generación de claves, el almacenamiento, la rotación, la retirada y el conjunto de confianza de producción. Controlaba la arquitectura de metadatos común, 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 monitoreo de inquilino, la lógica de alerta personalizada, el triaje, la escalada y la coordinación con CISA y el FBI. Realizó esas tareas de manera efectiva como para descubrir una intrusión a nivel de proveedor. Otros clientes controlaban su propio monitoreo 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 o cambiar.

CISA, OMB y los funcionarios de adquisiciones de las agencias controlaban partes de la línea base federal: requisitos de registro, guías 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 al buzón.

Storm-0558 controlaba 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 llegó a los sistemas protegidos a pesar de la culpabilidad del actor. La atribución y la responsabilidad defensiva responden a preguntas diferentes.

Los consejos de administración 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 decisión posterior de Microsoft de vincular la compensación de los directivos con 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 del senador Ron Wyden en julio de 2023pidió al Departamento de Justicia, a la Comisión Federal de Comercio y al CSRB que investigaran las prácticas de Microsoft. Esa solicitud es evidencia de preocupación regulatoria, no evidencia de que las agencias solicitadas hayan llegado a una conclusión de cumplimiento. Ningún registro público utilizado aquí establece un juicio legal definitivo para Storm-0558.

Lo que la remediación duradera debería probar

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

Custodia y ciclo de vida de las claves

Microsoft debería 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 procesables 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 debería reducir el número de inquilinos, servicios y clases de cuentas expuestos por cualquier clave única.

Corrección de la validación

Cada servicio dependiente 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 Connect de Microsoftexplica 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 intencionadamente 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 portador solo con firma puede seguir siendo convincente después de que se robe la clave de firma. 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 al buzón e identidad por defecto, sin una barrera premium, en un esquema documentado que pueda exportarse a herramientas de análisis independientes. Seis meses de registros accesibles para los clientes, según lo recomendado por el CSRB y adoptado como objetivo de SFI, deberían ser un suelo 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 incluir historial de versiones, niveles de confianza y preguntas sin resolver explícitas. Cuando una hipótesis publicada pierde apoyo probatorio, la corrección debe ser rápida y prominente. Un proveedor no debería necesitar 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 toda la producción, incluidos los sistemas heredados y los entornos adquiridos.

Lecciones prácticas para los clientes de la nube y los 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, adquieran evidencia, no solo características. Los contratos y las líneas base de servicio deben identificar qué eventos de acceso, identidad, administrativos, de tokens y de buzón están disponibles; qué tan rápido llegan; cuánto tiempo permanecen consultables; y si los clientes pueden exportarlos. El registro debe probarse con eventos simulados antes de un incidente.

Segundo, construyan análisis en torno al acceso a los 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 meramente la ceremonia de autenticación. Los entornos de alto valor deben establecer líneas base de acceso inusual al buzón, identificadores de aplicación, geografía, comportamiento del cliente y volumen de acceso.

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

Cuarto, traten 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 en 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, prueben 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 en todo el proveedor y el alcance oportuno sean parte de la arquitectura de detección del cliente.

Finalmente, no confundan la responsabilidad compartida con la igualdad de capacidad. 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 allí 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 la clave sin resolver. La evidencia pública respalda un hallazgo de alta confianza de que Microsoft permitió que una clave de firma de consumidor antigua siguiera siendo de confianza, no hizo cumplir el límite entre la validación de tokens de consumidor y empresarial, careció 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 el escape de la clave.

También respalda el hallazgo de que el registro de clientes limitado por licencias 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 por parte de Brad Smith de los hallazgos del CSRB es significativa. También lo son la eliminación del muro de pago de registro para eventos centrales y el avance 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 heredada y actual 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 los clientes. 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 la autoridad oculta. Cuando una clave de firma y un 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 la 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 fiabilidad 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 funcionando. Sin embargo, interrumpió la premisa sobre la cual los gobiernos lo usaban. Por eso el incidente merece estar en el registro como un fallo de responsabilidad en la nube en lugar de meramente otra operación de espionaje exitosa.