Microsoft Storm-0558 e a falha de chave de assinatura que tornou a identidade na nuvem um problema de responsabilidade pública

Resumo

• O Storm-0558 não derrotou os controles de senha de uma agência federal. Ele usou uma chave de assinatura de consumidor da Microsoft para fabricar tokens de identidade aparentemente válidos e depois se beneficiou de um defeito de validação da Microsoft que permitiu que esses tokens assinados por consumidor alcançassem o Exchange Online corporativo.
• O caminho de aquisição da chave permanece não resolvido. A explicação do dump de falha de setembro de 2023 da Microsoft foi posteriormente reduzida a uma hipótese principal depois que a empresa reconheceu que não havia encontrado um dump de falha contendo a chave ou logs que comprovassem a exfiltração. A chave desatualizada, o defeito de validação entre fronteiras, a detecção fraca de anomalias de token e a retenção forense limitada são achados de falha mais bem suportados.
• A responsabilidade segue a capacidade de controle. Somente a Microsoft poderia rotacionar a chave da plataforma, corrigir o validador do lado do serviço, detectar combinações impossíveis de tokens em sua nuvem, preservar as evidências internas relevantes e fechar o vetor de ataque. Os clientes poderiam melhorar o monitoramento e a resposta, mas em 2023 a telemetria decisiva do MailItemsAccessed estava vinculada a licenças E5/G5 de preço mais alto.

Uma falha de controle de identidade, não uma violação convencional de caixa de correio

A intrusão do Storm-0558 é fácil de comprimir em uma frase familiar: hackers chineses roubaram uma chave da Microsoft e leram e-mails governamentais. Essa frase é direcionalmente verdadeira e analiticamente inadequada. Ela mescla o ato do atacante, a perda não resolvida de material criptográfico pela Microsoft, uma falha separada de validação de software, uma decisão de ciclo de vida de chave desatualizada, um sucesso de detecção do lado do cliente e uma resposta do provedor de serviços em um único evento. Uma vez que esses mecanismos são separados, a alocação de responsabilidade se torna muito mais clara.

A intrusão não foi principalmente um caso de um funcionário público entregar uma senha, uma agência falhar em implantar autenticação multifatorial ou um servidor sem patch dentro de um ministério. O Storm-0558 possuía a metade privada de uma chave de assinatura de consumidor da Microsoft Account, ou MSA, criada em 2016. Uma chave de assinatura privada permite que seu titular produza tokens cujas assinaturas podem ser verificadas contra a chave pública correspondente. O ator poderia, portanto, afirmar identidades sem obter as senhas das vítimas.

Um segundo defeito da Microsoft permitiu que uma chave destinada a contas de consumidor autenticasse solicitações contra o Exchange Online corporativo. O resultado foi uma capacidade de personificação em nível de plataforma que cruzou a fronteira entre os sistemas de identidade de consumidor e organizacional da Microsoft.

Aanálise técnica de julho de 2023da Microsoft explica o mecanismo básico: o ator forjou tokens do Azure Active Directory com a chave de consumidor adquirida, usou um fluxo legítimo do Outlook Web Access, obteve tokens do Exchange Online através da interface GetAccessTokenForResource e recuperou e-mails através da API do OWA. A Microsoft disse que uma falha de design também permitiu que o ator obtivesse novos tokens de acesso apresentando um já emitido por essa interface. Isso não foi simplesmente uma repetição de credencial roubada. Foi a fabricação e renovação não autorizada de credenciais que os serviços da Microsoft trataram como válidas.

A distinção importa para a responsabilidade na nuvem. Os clientes geralmente permanecem responsáveis por suas identidades, higiene de dispositivos, permissões, configuração de aplicativos e resposta a incidentes. Mas um cliente não pode inspecionar ou rotacionar o material de assinatura raiz de um provedor de nuvem, corrigir o validador de token de produção do provedor ou implantar um detector dentro do plano de emissão de identidade do provedor.

Quando a falha se origina em controles disponíveis apenas para o provedor, descrever o evento como um problema de responsabilidade compartilhada sem especificar quem controlava qual salvaguarda obscurece mais do que explica.

Também é importante não classificar erroneamente o evento como uma interrupção de serviço. O registro público não mostra que o Exchange Online ficou indisponível para as agências afetadas. O dano foi a perda de confidencialidade e comunicações confiáveis, seguida por um ônus investigativo substancial. A continuidade do setor público inclui mais do que manter um serviço acessível. O trabalho diplomático, econômico, legislativo e de segurança nacional depende de os funcionários poderem usar um sistema de comunicação sem que um adversário o leia silenciosamente.

Uma nuvem pode permanecer tecnicamente "ativa" enquanto a função pública que suporta se torna menos confiável.

O que está estabelecido, o que é inferido e o que permanece desconhecido

Três categorias de evidências devem permanecer separadas.

Primeiro, o registro público estabelece firmemente que o Storm-0558 usou uma chave de assinatura de consumidor MSA de 2016 criada pela Microsoft para forjar tokens; que uma falha de validação da Microsoft permitiu que esses tokens acessassem contas corporativas do Exchange Online; que o Departamento de Estado descobriu atividade suspeita através de logs de acesso a caixas de correio aprimorados; e que a Microsoft mitigou a técnica conhecida através de uma sequência de mudanças no lado do serviço.

As divulgações da Microsoft, o aviso de resposta da CISA, as declarações das agências afetadas e a reconstrução do Cyber Safety Review Board convergem nesses pontos.

Segundo, o Cyber Safety Review Board, ou CSRB, fez constatações sobre evitabilidade, design de controle, cultura de segurança, divulgação e prática da indústria. Suarevisão completa da intrusão do verão de 2023concluiu que o incidente era evitável e nunca deveria ter ocorrido. O Conselho entrevistou 20 organizações, recebeu a cooperação da Microsoft, comparou controles em outros grandes provedores de serviços em nuvem e encontrou uma cascata de falhas evitáveis. Essas são constatações de revisão independentes, não constatações judiciais, mas são substancialmente mais fortes do que comentários baseados apenas nos primeiros blogs da Microsoft.

Terceiro, a rota real pela qual o Storm-0558 obteve a chave privada de 2016 permanece desconhecida no registro público. Essa incerteza é central. A Microsoft publicou uma história detalhada de dump de falha em setembro de 2023, depois adicionou uma correção em março de 2024 afirmando que não havia encontrado um dump de falha contendo o material da chave impactada. O CSRB relatou que a Microsoft explorou 46 hipóteses de roubo de chave e ainda não sabia como ou quando o ator obteve a chave. Qualquer relato que apresente o dump de falha como a causa raiz comprovada exagera as evidências.

O registro também não estabelece uma alocação legal final de perda. O escrutínio do Congresso, os pedidos de investigação e a aceitação pela Microsoft das constatações do CSRB são relevantes para a responsabilidade. Eles não substituem um julgamento judicial, uma decisão de aplicação da agência, uma interpretação contratual ou uma análise de danos quantificada. A conclusão adequada é mais restrita: a Microsoft controlava várias salvaguardas falhas e aceitou responsabilidade pelas questões citadas pelo CSRB; as fontes disponíveis não estabelecem responsabilidade civil, criminal ou regulatória final.

Linha do tempo forense

2016-2021: chave de longa duração e migração adiada

A Microsoft criou a chave de assinatura de consumidor em 2016. A idade de uma chave não é por si só prova de insegurança, mas a idade da chave se torna material quando uma organização não pode mostrar com confiança a custódia contínua e quando a rotação limita a vida útil do material roubado. O CSRB descobriu que o sistema MSA de consumidor da Microsoft dependia de rotação manual, enquanto seu sistema de identidade corporativa havia avançado em direção à automação. A empresa pretendia migrar o sistema de consumidor para a tecnologia automatizada, mas não havia concluído esse trabalho antes da intrusão.

De acordo com o CSRB, a Microsoft interrompeu a rotação manual de chaves de assinatura de consumidor em 2021 após uma grande interrupção da nuvem associada ao processo manual. Ela não implantou então uma substituição automatizada de rotação ou um alerta que notificasse as equipes responsáveis sobre chaves ativas envelhecendo. A chave de 2016, portanto, permaneceu aceita em 2023.

Esta é uma decisão clássica de disponibilidade versus segurança com um custo adiado oculto: pausar um procedimento manual arriscado pode reduzir o risco imediato de interrupção, mas deixar a automação compensatória inacabada preserva a exposição de segurança indefinidamente.

A constatação do Conselho é mais útil do que dizer meramente que uma chave "expirada" funcionou. Uma chave é aceita ou rejeitada de acordo com a configuração de confiança ativa do serviço. A falha crucial foi que uma chave destinada a ser retirada permaneceu dentro do conjunto de confiança. A própriaorientação atual de rotação de chave de assinaturada Microsoft diz que os aplicativos devem lidar com a rotação periódica e de emergência programaticamente e recomenda bibliotecas padrão para evitar defeitos sutis. Essa orientação descreve o comportamento de validação voltado para o cliente, mas o princípio subjacente se aplica mais amplamente: a substituição de chaves deve ser uma capacidade projetada, não uma cerimônia frágil que se torna arriscada demais para ser executada.

Em setembro de 2018, a Microsoft introduziu um endpoint comum de publicação de metadados de chave em resposta à demanda por aplicativos que atendiam tanto usuários consumidores quanto corporativos. O relato posterior da Microsoft disse que a documentação foi atualizada para explicar a validação de escopo da chave, mas as bibliotecas auxiliares não foram atualizadas para aplicar esse escopo automaticamente. Os sistemas de correio do Exchange começaram a usar o endpoint de metadados comum em 2022. Os desenvolvedores presumiram que a biblioteca realizava validação completa e não adicionaram a verificação necessária de emissor ou escopo.

O endpoint comum, portanto, aumentou a interoperabilidade enquanto também criava um risco de fronteira de confiança: a validade criptográfica foi confundida com autorização dentro do domínio de identidade correto.

A reconstrução do CSRB coloca outro evento relevante em 2021. O Storm-0558 comprometeu a rede corporativa da Microsoft através da conta de um engenheiro entre abril e agosto. O engenheiro trabalhava para a Affirmed Networks, que a Microsoft havia adquirido em 2020; a Microsoft acreditava que o dispositivo havia sido comprometido antes da aquisição e depois se conectou ao ambiente da Microsoft com credenciais corporativas. O ator capturou e repetiu um token de autenticação e acessou material no SharePoint, incluindo informações relacionadas ao gerenciamento de serviços do Azure e identidade.

O Conselho criticou a Microsoft por não detectar o dispositivo comprometido da empresa adquirida antes de permiti-lo na rede corporativa.

Este compromisso de 2021 é evidência de acesso e interesse do atacante. Não é prova de que o ator obteve a chave MSA de 2016 naquela época. A Microsoft disse ao Conselho que a intrusão de 2021 provavelmente estava conectada porque era a única outra intrusão conhecida do Storm-0558 na rede da Microsoft na memória registrada, mas a empresa não produziu evidências específicas ligando-a ao roubo da chave. Um relato disciplinado deve preservar essa lacuna.

Maio-Junho de 2023: acesso começa antes de o provedor detectá-lo

O Storm-0558 estabeleceu infraestrutura externa identificada e começou a acessar contas do Exchange Online visadas até 15 de maio de 2023. O CSRB alertou que a janela de compromisso poderia ter começado mais cedo porque a retenção padrão de logs de 30 dias da Microsoft restringia a visão retrospectiva disponível uma vez que a investigação começasse. "Visto pela primeira vez" é, portanto, um limite probatório, não necessariamente o verdadeiro início do ataque.

Os alvos refletiam prioridades de espionagem. O balanço final do CSRB identificou 22 organizações e mais de 500 indivíduos em todo o mundo, incluindo vítimas nos Estados Unidos, Reino Unido e outros lugares. As contas incluíam as da Secretária de Comércio Gina Raimondo, do Embaixador dos EUA na China R. Nicholas Burns, do Secretário Assistente de Estado para Assuntos do Leste Asiático e Pacífico Daniel Kritenbrink e do Congressista Don Bacon. Oaviso de incidente inicial de 11 de julhoda Microsoft referia-se a aproximadamente 25 organizações e contas de consumidor relacionadas. A diferença é melhor tratada como uma mudança na contabilidade do incidente entre um aviso inicial da empresa e a reconstrução independente posterior, não como evidência de uma nova intrusão.

O Departamento de Estado, não a Microsoft, detectou a campanha. Em 15 de junho, o centro de operações de segurança do Estado observou anomalias. Em 16 de junho, uma regra personalizada conhecida internamente como Big Yellow Taxi gerou alertas a partir do evento de auditoria MailItemsAccessed, que registra acesso a itens de caixa de correio do Exchange Online. O Estado investigou apesar da possibilidade de falsos positivos e contatou a Microsoft naquele dia. Em 19 de junho, o Estado determinou que seis contas haviam sido acessadas, incluindo contas associadas aos preparativos para a viagem do Secretário de Estado a Pequim.

Identificou seis contas adicionais acessadas entre 21 e 24 de junho e outra através da análise de um servidor privado virtual apreendido.

As datas mostram que a descoberta e a contenção se sobrepuseram ao acesso contínuo. O alerta do Estado foi um sucesso de detecção, mas não revelou instantaneamente uma credencial de plataforma forjada. A Microsoft inicialmente examinou explicações familiares, como dispositivos comprometidos e tokens emitidos corretamente roubados. Seus analistas então viram que os artefatos de autenticação do Exchange Online não correspondiam aos tokens do Azure AD nos logs esperados.

Por volta de 26 de junho, a Microsoft determinou que o ator estava usando a chave de consumidor de 2016 para criar tokens que funcionavam contra e-mails de consumidor e corporativos.

Oaviso conjunto CISA-FBI AA23-193Aé excepcionalmente direto sobre a alocação de capacidade de mitigação. Diz que todas as ações de mitigação para esta atividade eram responsabilidade da Microsoft porque a infraestrutura afetada era baseada em nuvem. Também diz que as agências não estavam cientes de outros logs de auditoria ou eventos que teriam detectado a atividade. O cliente detectou o incidente, mas apenas o provedor pôde fechar a técnica.

26 de junho a 3 de julho: mitigação em etapas, não um único interruptor

A cronologia detalhada da Microsoft registra várias ações distintas:

• Em 26 de junho, o OWA parou de aceitar tokens emitidos pelo GetAccessTokenForResource para renovação, fechando o comportamento de renovação que o ator havia abusado.
• Em 27 de junho, a Microsoft bloqueou o uso pelo OWA de tokens assinados pela chave MSA adquirida, impedindo mais acesso a e-mails corporativos através do caminho observado.
• Em 29 de junho, a Microsoft concluiu a substituição da chave, revogou todas as chaves de assinatura MSA que haviam sido válidas durante o incidente e emitiu novas chaves de sistemas protegidos.
• Em 3 de julho, a Microsoft bloqueou o uso da chave para clientes consumidores afetados para evitar o uso de tokens emitidos anteriormente.

Essa sequência demonstra por que "a chave foi revogada" não é uma descrição suficiente de contenção. Uma campanha de token forjado pode envolver metadados de validação em cache, artefatos de acesso a jusante, interfaces de renovação, serviços de consumidor e corporativos e tokens já emitidos. A contenção durável requer mapear cada lugar onde a antiga decisão de confiança sobrevive.

A Microsoft disse que observou o Storm-0558 migrar para phishing e outras técnicas depois que o caminho conhecido de falsificação de token foi bloqueado, e que não viu mais atividade relacionada à chave. Isso apoia a eficácia das mitigações imediatas contra o método observado. Não prova que o caminho original de aquisição foi identificado ou que o ator nunca obteve outro material sensível. O CSRB disse explicitamente que a possibilidade de acesso a outras chaves e dados permanecia não resolvida.

Julho de 2023 a março de 2024: divulgação, reforma de logs e correção da alegação de causa raiz

A Microsoft divulgou publicamente a campanha em 11 de julho e publicou uma análise técnica mais profunda em 14 de julho. Seus primeiros posts descreveram corretamente o abuso da chave e o erro de validação, enquanto afirmavam que a aquisição da chave permanecia sob investigação. Em 19 de julho, após coordenação com a CISA, a Microsoft anunciou que logs detalhados de acesso a e-mails e mais de 30 outros tipos de eventos de auditoria seriam disponibilizados para clientes de nível padrão sem custo adicional. A empresa também disse que o período de retenção padrão para o Audit Standard aumentaria de 90 para 180 dias. Oanúncio de logsda Microsoft é uma resposta material porque muda quem pode ver as evidências necessárias para detectar abuso originado do provedor.

Em 6 de setembro, a Microsoft publicou o que chamou de resultados de suas principais investigações técnicas. O relato original afirmava que uma falha do sistema de assinatura de consumidor em abril de 2021 produziu um dump de falha; que uma condição de corrida permitiu que a chave entrasse no dump; que o dump passou de um ambiente de produção isolado para um ambiente de depuração corporativo conectado à Internet; que os scanners de credenciais o perderam; e que o Storm-0558 posteriormente comprometeu uma conta de engenheiro com acesso a esse ambiente.

Como os logs relevantes haviam expirado, a Microsoft chamou isso de mecanismo de aquisição mais provável.

Essa narrativa forneceu uma cadeia coerente, mas a cadeia não era suportada por evidências diretas. Orelatório de setembro com versõesda Microsoft agora começa com uma atualização de 12 de março de 2024. A empresa diz que sua hipótese principal permanece sendo que erros operacionais fizeram com que o material da chave deixasse o ambiente de assinatura seguro e que o material foi acessado através de uma conta de engenharia comprometida. Também diz que não encontrou um dump de falha contendo a chave impactada, a condição de corrida citada afetava se um dump poderia deixar o ambiente de assinatura, em vez de se o material da chave poderia estar presente, e que remover tal material não era um processo padrão, mas não havia sido proibido na época.

A correção muda o status epistêmico do relato. Uma hipótese plausível não é uma constatação de causa raiz. O CSRB relatou que a Microsoft disse ao Conselho em novembro de 2023 que percebeu logo após a publicação que as declarações de setembro eram imprecisas, mas não publicou a correção até março de 2024, após repetidos questionamentos do Conselho. Esse atraso tornou-se parte da constatação de cultura de segurança do Conselho, porque os clientes usam divulgações de causa raiz para julgar se o caminho real de aquisição foi fechado.

Causa raiz, gatilho e falhas de detecção

A análise de incidentes é mais precisa quando separa o gatilho das causas raiz e das falhas de detecção e resposta.

Gatilho

O gatilho operacional foi o uso pelo Storm-0558 da chave de assinatura privada MSA de 2016 roubada para criar tokens e apresentá-los através de caminhos de acesso ao Exchange Online. O ator selecionou alvos, operou infraestrutura, cunhou declarações, acessou e-mails e exfiltrou mensagens. O ator é responsável pela intrusão maliciosa. A atribuição a um ator de espionagem associado à República Popular da China é uma avaliação de inteligência relatada pela Microsoft e pelo CSRB; este artigo não atribui comando estatal de forma independente.

Causas raiz técnicas e condições facilitadoras

A primeira questão de causa raiz, como a chave privada escapou do controle da Microsoft, não está resolvida. Deve ser registrada como um fato material em aberto, não preenchida com a hipótese do dump de falha.

A segunda causa é muito melhor estabelecida: a chave antiga permaneceu confiável. A rotação manual de chaves de consumidor parou em 2021 após uma interrupção, a substituição automatizada não estava pronta e nenhum alerta eficaz de envelhecimento forçou a resolução. O roubo de uma chave de curta duração ou prontamente retirada teria produzido uma oportunidade menor. O roubo de uma chave que permaneceu aceita por anos produziu poder de assinatura durável.

A terceira causa foi a falha de escopo na validação de tokens. O serviço verificou uma assinatura contra o material da chave disponível através de metadados comuns, mas não provou adequadamente que o domínio de identidade da chave era permitido para autorizar o recurso corporativo solicitado. Adocumentação atual de validação de token de acessoda Microsoft diz aos servidores de recurso para validar a assinatura do token, público, emissor, locatário e emissor da chave de assinatura. O caso Storm-0558 mostra por que essas verificações não são redundantes. Uma assinatura matematicamente válida responde quem detinha uma chave privada; não responde, por si só, se essa chave estava autorizada para este locatário, classe de conta, serviço ou recurso.

A quarta causa foi a falha de design de renovação de token do OWA. Uma vez que a identidade forjada foi aceita através de um fluxo legítimo, o GetAccessTokenForResource permitiu que um token obtivesse outro de uma forma que a Microsoft depois mudou para distinguir a emissão do Azure AD e do MSA. Isso não criou a capacidade de assinatura original, mas tornou o caminho de acesso mais útil e durável.

A quinta condição facilitadora foi a detecção inadequada de anomalias do lado do provedor. A Microsoft disse que o padrão de token do ator era óbvio em retrospecto, porque nenhum sistema legítimo da Microsoft assinava tokens nessa combinação. No entanto, o provedor não alertou sobre esse estado impossível ou altamente anômalo antes de um cliente relatar comportamento de caixa de correio.

O CSRB descobriu que outros provedores de nuvem tinham controles que a Microsoft não tinha e recomendou que os provedores usassem dados proprietários em algoritmos de geração de token e sinais de validação para detectar declarações forjadas mesmo quando uma assinatura verifica.

Falhas de detecção e resposta

A detecção dependia de um cliente com licença premium, uma analítica personalizada, operadores qualificados e a disposição de perseguir um alerta moderado que já havia gerado falsos positivos antes. Esse é um controle impressionante do Departamento de Estado. É também um modelo de segurança instável em todo o sistema. Milhares de clientes não podem ser esperados para reconstruir um comprometimento criptográfico de provedor a partir de eventos opcionais de caixa de correio, especialmente quando o evento necessário para esta campanha não estava disponível para usuários de licença padrão.

Na época, o MailItemsAccessed estava disponível através do Microsoft Purview Audit Premium e exigia licenciamento E5 ou G5. O Estado tinha G5 e pôde criar o Big Yellow Taxi. Outras vítimas sem logs premium não tinham a mesma visibilidade histórica. O aviso da CISA e do FBI, portanto, instou as organizações a ativar logs premium, observando explicitamente o requisito de licença. Sete dias depois, a Microsoft se comprometeu a remover a barreira de nível para tipos de eventos importantes. A diretora da CISA, Jen Easterly, descreveu a mudança como um passo em direção à prática de design seguro nadeclaração de 19 de julho da CISA.

A resposta também foi limitada pela retenção de evidências do provedor. A Microsoft não tinha os logs necessários para determinar como ou quando a chave havia sido roubada. Janelas de 30 dias restringiram a atividade mais antiga observável do cliente, enquanto eventos corporativos e de produção mais antigos necessários para a hipótese de 2021 estavam indisponíveis.

A retenção de logs sempre traz custo, privacidade e obrigações de controle de acesso, mas um provedor não pode reivindicar de forma crível proteger joias da coroa criptográficas se seu horizonte de evidências é mais curto do que o tempo que atores sofisticados podem permanecer quietos.

Finalmente, a correção atrasada do relato causal de setembro foi uma falha de resposta. Ela não permitiu a intrusão original, mas prejudicou a garantia pública. Um relatório pós-incidente deve separar fatos, hipóteses avaliadas, confiança, evidências contraditórias e questões não resolvidas. Publicar um mecanismo de som completo e corrigi-lo apenas seis meses depois tornou mais difícil para clientes e supervisores determinar se a remediação abordou o caminho real.

O problema de logs e licenciamento

Os logs são às vezes tratados como um recurso de produto auxiliar. Neste incidente, eles eram um controle de segurança e uma fonte de assimetria de informação.

A Microsoft possuía telemetria em todo o serviço e visibilidade interna do sistema de identidade indisponível para qualquer cliente. Cada cliente podia observar apenas seu locatário e apenas os tipos de evento incluídos em sua assinatura e configuração. O alerta decisivo veio do MailItemsAccessed, um evento projetado para mostrar quando itens de caixa de correio eram acessados. A CISA e o FBI afirmaram que não conheciam nenhum outro evento de auditoria que teria detectado essa atividade. Um cliente sem o evento ainda poderia notar sinais contextuais, mas não tinha a mesma superfície probatória direta.

Isso cria uma fronteira comercial problemática. Produtos de segurança premium podem razoavelmente cobrar por análises avançadas, automação, retenção longa e investigação gerenciada. A evidência mínima necessária para saber se um serviço operado por um fornecedor acessou dados do cliente é diferente. Quando um provedor sozinho controla o sistema e um cliente deve pagar extra para observar o acesso resultante da própria falha de identidade do provedor, o cliente está sendo solicitado a comprar visibilidade sobre um risco que não pode remediar diretamente.

A mudança pós-incidente reconhece essa distinção. A Microsoft se comprometeu a disponibilizar logs de segurança de nuvem mais amplos em todo o mundo sem custo adicional, adicionar eventos detalhados de acesso a e-mails ao Audit Standard e dobrar a retenção padrão para 180 dias. Em fevereiro de 2024, a CISA, o Office of Management and Budget, o Office of the National Cyber Director e a Microsoft anunciaram que logs expandidos estavam se tornando disponíveis para todas as agências federais usando o Purview Audit, independentemente do nível, com ativação automática e a retenção padrão mais longa. Oanúncio de implementação conjuntaenquadrou logs de auditoria de alta qualidade sem custo extra ou configuração como uma expectativa de design seguro.

A reforma não elimina a responsabilidade do cliente. Os logs devem ser roteados para sistemas pesquisáveis, retidos de acordo com os requisitos legais e de risco, ter linha de base, ser consultados e conectados a procedimentos de resposta. O aviso da CISA recomenda exatamente essas medidas. Mas a disciplina operacional do cliente se torna significativa apenas depois que o provedor emite o evento relevante e o torna acessível. Disponibilidade de telemetria e uso de telemetria são dois controles separados de propriedade de partes diferentes.

O licenciamento também afetou a igualdade forense entre as vítimas. O ambiente G5 do Estado tinha um registro histórico mais forte do que ambientes de nível padrão. Ativar um evento após um incidente não reconstrói o que nunca foi registrado. Isso significa que a mesma falha do provedor pode produzir diferentes níveis de confiança sobre o impacto com base na assinatura do cliente, mesmo que nenhum dos clientes controlasse a chave de assinatura subjacente. A evidência forense mínima deve, portanto, ser tratada como parte da linha de base de segurança do serviço, não meramente como um upsell.

Impacto no cliente federal e continuidade do setor público

O comprometimento afetou e-mails não classificados, mas "não classificado" não significa trivial operacionalmente. As caixas de correio de altos funcionários contêm agendas, deliberações políticas, redes de contatos, posições de negociação, linguagem de rascunho e o tecido conjuntivo comum do governo. Um serviço de inteligência pode derivar valor da agregação, tempo, relacionamentos e contexto sem obter documentos formalmente classificados.

O Departamento de Estado disse posteriormente que aproximadamente 60.000 e-mails foram baixados de 10 contas. Em seubriefing de imprensa de 28 de setembro de 2023, o Departamento descreveu o material afetado como não classificado e disse que nenhum sistema de e-mail classificado foi hackeado. A reconstrução mais ampla do CSRB identificou mais contas do Estado acessadas, refletindo diferentes maneiras de contar o acesso a contas e o subconjunto do qual as mensagens foram baixadas. O artigo não infere o conteúdo das mensagens além do que as agências divulgaram.

As caixas de correio oficial e pessoal do Secretário de Comércio estavam entre as afetadas, de acordo com o CSRB. A Câmara dos Representantes dos EUA também estava dentro do conjunto afetado, incluindo o Congressista Don Bacon. Umainvestigação da Câmara de Supervisãode agosto de 2023 buscou briefings do Estado e do Comércio sobre descoberta, impacto, resposta e segurança futura. Esses fatos estabelecem exposição sensível do setor público e preocupação de supervisão; eles não estabelecem que decisões políticas específicas mudaram por causa da intrusão.

A continuidade neste contexto tem pelo menos cinco dimensões.

Primeiro é a continuidade da confidencialidade: os funcionários precisam de uma expectativa durável de que as comunicações rotineiras na nuvem não sejam silenciosamente copiadas por um ator de inteligência estrangeiro.

Segundo é a continuidade das decisões: as equipes que preparam viagens diplomáticas ou política econômica devem poder deliberar sem assumir que o adversário tem acesso contemporâneo aos seus e-mails.

Terceiro é a continuidade probatória: as agências precisam de dados retidos suficientes para reconstruir quem acessou o quê e quando. Sem isso, os líderes não podem delimitar o incidente com confiança ou decidir quais relacionamentos e decisões requerem revalidação.

Quarto é a continuidade da resposta: um comprometimento do provedor força as agências a desviar capacidade de segurança, jurídica, diplomática, de registros e de liderança. Mesmo quando o e-mail permanece disponível, o trabalho de missão absorve um imposto oculto de resposta a incidentes.

Quinto é a continuidade da confiança: a adoção federal de serviços de nuvem compartilhados depende da garantia de que o provedor detectará falhas em seu próprio plano de controle, divulgá-las com precisão e fornecerá aos clientes evidências utilizáveis. Um serviço pode atender a uma meta de tempo de atividade enquanto falha neste teste mais amplo de continuidade.

O incidente também expôs o risco de concentração. A Microsoft fornece identidade, e-mail, produtividade, sistema operacional, segurança e serviços de nuvem em grande parte do governo e do setor privado. A integração pode melhorar o gerenciamento e a detecção, mas também pode permitir que um defeito de identidade do lado do provedor cruze fronteiras organizacionais em escala global. O CSRB descreveu a centralidade da Microsoft como uma razão para exigir os mais altos padrões de segurança, responsabilidade e transparência.

A concentração não leva automaticamente à conclusão de que toda agência deve abandonar a Microsoft ou manter sistemas de e-mail duplicados. A migração em si cria custo e risco, e vários provedores podem reproduzir fraquezas de identidade semelhantes. A conclusão mais forte é que a aquisição e a supervisão devem precificar explicitamente a falha de identidade de modo comum: segmentação de chave, detecção de anomalias do lado do provedor, acesso a auditoria, retenção de evidências, notificação de incidentes, testes independentes e acordos de saída ou continuidade devem ser tratados como requisitos de serviço.

As constatações do CSRB e por que elas importam

Apágina de publicaçãodo CSRB descreve o relatório como uma revisão independente de decisões operacionais e estratégicas e diz que recomenda práticas para a indústria e o governo. Suas constatações centrais são severas, mas específicas.

O Conselho concluiu que a cultura de segurança da Microsoft era inadequada e exigia uma reformulação. Baseou essa conclusão na cascata evitável, na falha em detectar o comprometimento de uma chave de assinatura crítica, na dependência de um cliente para descoberta, na comparação com controles em outros provedores, no comprometimento do dispositivo adquirido em 2021, na correção atrasada de declarações públicas imprecisas e em um comprometimento separado de Estado-nação em 2024 que estava fora do escopo desta revisão.

A constatação é organizacional porque nenhum único erro de codificação explica por que a chave permaneceu aceita, por que a separação de domínio falhou, por que padrões impossíveis de token não alertaram, por que as evidências estavam indisponíveis e por que uma alegação causal superou a prova.

O Conselho também forneceu contrafactuais concretos. Se a rotação manual não tivesse sido pausada sem uma substituição automatizada concluída, ou se um alerta de chave envelhecida tivesse forçado a ação, a chave de 2016 não teria permanecido válida em 2023. Se a validação de consumidor e corporativo tivesse sido corretamente separada, o alcance do ator teria sido muito mais estreito e não teria incluído clientes corporativos. Se a Microsoft tivesse detectado tokens que não estavam em conformidade com seu próprio algoritmo de geração, a campanha poderia ter sido bloqueada ou detectada pelo provedor.

Se uma retenção forense mais forte existisse, a Microsoft poderia ter respondido à questão da aquisição da chave.

Esses contrafactuais demonstram um princípio de segurança em camadas. A intrusão não exigiu que todo controle falhasse da mesma forma. Qualquer um de vários controles independentes poderia ter prevenido o comprometimento corporativo ou encurtado-o materialmente:

• A custódia segura poderia ter prevenido a perda da chave.
• A rotação automática frequente poderia ter tornado a chave roubada inutilizável antes de 2023.
• A validação com consciência de escopo poderia ter confinado uma chave de consumidor a serviços de consumidor.
• Verificações de token com estado ou proprietárias poderiam ter detectado um token que a própria Microsoft nunca emitiria.
• O monitoramento em todo o provedor poderia ter revelado a combinação impossível de domínio de assinatura.
• Os logs de linha de base do cliente poderiam ter permitido que mais vítimas detectassem e delimitassem o acesso.
• A retenção mais longa do provedor poderia ter melhorado a confiança na causa raiz.

É por isso que o caminho de roubo não resolvido não impede a análise de responsabilidade. O desconhecido é importante, mas várias falhas independentemente suficientes ou limitadoras de impacto estão documentadas. Um provedor não pode responder a um elo de causa raiz ausente tratando toda a cadeia como incognoscível.

As recomendações do Conselho se estenderam além da Microsoft. Elas pediram práticas modernas de gerenciamento de chaves, rotação automatizada e frequente, chaves protegidas por hardware, bibliotecas de autenticação comuns, padrões de identidade digital mais fortes, logs mínimos para clientes sem taxas adicionais, pelo menos seis meses de logs apropriados acessíveis ao cliente, melhor notificação de vítimas e divulgação mais transparente de vulnerabilidades na nuvem. Essas medidas abordam uma estrutura industrial na qual os provedores detêm tanto o controle privilegiado quanto a melhor evidência.

A resposta da Microsoft

A resposta imediata da Microsoft corrigiu as falhas conhecidas do validador e de renovação, bloqueou a chave roubada, revogou as chaves de assinatura MSA então ativas, moveu as chaves de consumidor para o repositório de chaves corporativo protegido, aumentou o isolamento e refinou o monitoramento do sistema de chaves. Essas ações abordaram diretamente a campanha observada. A Microsoft também notificou as organizações afetadas e divulgou indicadores de infraestrutura para defensores.

A empresa então fez uma mudança de controle comercial ao expandir o acesso à auditoria. Essa ação é observável de forma independente no compromisso com o produto e na implantação federal, embora a completude prática da cobertura de eventos ainda dependa do serviço, configuração, retenção e operações do cliente.

Em novembro de 2023, a Microsoft lançou a Secure Future Initiative. Seuanúncio inicial da SFIcomprometeu-se com um sistema unificado e totalmente automatizado de gerenciamento de chaves de consumidor e corporativo usando computação confidencial e módulos de segurança de hardware, com uma arquitetura projetada para manter as chaves inacessíveis mesmo quando os processos subjacentes são comprometidos. Um post de engenharia complementar comprometeu-se com rotação automatizada de alta frequência sem acesso humano.

Após o relatório do CSRB e uma intrusão separada de Estado russo no e-mail corporativo da Microsoft, a empresa expandiu a SFI em maio de 2024. Oprograma expandidoda Microsoft estabeleceu metas incluindo rotação automática rápida e proteção de hardware para chaves de assinatura, SDKs de identidade padrão em todos os aplicativos, validação com estado e durável para tokens de identidade, particionamento mais fino de chaves, eliminação de pivôs laterais de identidade, retenção de dois anos para logs de segurança e seis meses de logs apropriados para clientes. Também disse que parte da remuneração da alta liderança dependeria de marcos de segurança.

Em junho de 2024, o vice-presidente e presidente da Microsoft, Brad Smith, disse ao Comitê de Segurança Interna da Câmara que a empresa aceitava responsabilidade por todas as questões citadas no relatório do CSRB. Seudepoimento por escritodisse que a Microsoft estava agindo em todas as 16 recomendações do Conselho aplicáveis à empresa, havia dedicado o equivalente a 34.000 engenheiros em tempo integral à SFI, estava fazendo a transição dos sistemas de identidade de consumidor e corporativo para um sistema de gerenciamento de chaves com suporte de hardware e havia feito progresso na rotação automatizada, bibliotecas de autenticação comuns e sinais de validação de token. Oregistro da audiência congressionalfornece o contexto de supervisão pública e as perguntas.

Em setembro de 2024, a Microsoft relatou um Conselho de Governança de Cibersegurança, diretores de segurança da informação adjuntos para divisões de engenharia, segurança em avaliações de desempenho de funcionários e revisão executiva e do conselho regular. Aatualização de progresso da SFIda empresa é evidência de mudanças de governança e progresso de implementação declarado.

Essas respostas são compromissos substanciais. Eles ainda devem ser descritos como compromissos e progresso relatado pela empresa, onde a verificação independente não é pública. O CSRB recomendou arquiteturas e controles específicos, mas não certificou sua conclusão posterior. Um padrão de encerramento crível exigiria cobertura mensurável de rotação de chave, evidência de que validadores legados foram retirados, testes mostrando que as fronteiras de consumidor e corporativo falham fechadas, telemetria retida suficiente para investigar eventos de chave e garantia externa de que exceções não podem persistir silenciosamente.

Responsabilidade por capacidade de controle

Um mapa de responsabilidade útil começa com quem poderia prevenir, detectar, limitar ou encurtar cada falha.

A Microsoft controlava a geração, armazenamento, rotação, retirada e o conjunto de confiança de produção das chaves. Ela controlava a arquitetura de metadados comum, as bibliotecas auxiliares, o validador do Exchange Online, a interface de renovação de token do OWA e a lógica de detecção em todo o serviço. Ela controlava a retenção de evidências internas de produção e corporativas. Ela também controlava a precisão e o timing das divulgações técnicas públicas. A responsabilidade por essas superfícies recai principalmente sobre a Microsoft.

O Departamento de Estado controlava seu monitoramento de locatário, lógica de alerta personalizada, triagem, escalação e coordenação com a CISA e o FBI. Ele executou essas tarefas com eficácia suficiente para descobrir uma intrusão em nível de provedor. Outros clientes controlavam seu próprio monitoramento e resposta dentro da telemetria disponível para eles. A responsabilidade do cliente permanece real, mas não pode substituir os controles do provedor que os clientes não podem ver ou alterar.

A CISA, o OMB e os funcionários de aquisição de agências controlavam partes da linha de base federal: requisitos de log, orientação de configuração, expectativas contratuais, coordenação entre agências e a alavancagem para exigir padrões mais seguros. Seu trabalho de logs pós-incidente reduziu uma desigualdade. Um regime de aquisição maduro não deve depender de uma crise para estabelecer que os clientes precisam de acesso a evidências de acesso a caixas de correio.

O Storm-0558 controlou a operação hostil e é responsável pela intrusão. Esse fato óbvio não apaga a evitabilidade. As investigações de segurança examinam rotineiramente por que uma entrada maliciosa ou perigosa alcançou sistemas protegidos apesar da culpabilidade do ator. Atribuição e responsabilidade defensiva respondem a perguntas diferentes.

Os conselhos corporativos e executivos controlam a alocação de recursos, aceitação de riscos, incentivos e prazos. A pausa na rotação manual de chave após uma interrupção não foi meramente um erro de engenharia isolado; a consequência de segurança persistiu porque a automação e os alertas não receberam ou mantiveram prioridade suficiente. A decisão posterior da Microsoft de atrelar a remuneração da liderança a marcos de segurança reconhece implicitamente que o nível de controle relevante se estende acima da equipe que escreveu o validador.

A alocação não deve ser convertida mecanicamente em uma porcentagem de responsabilidade legal. Contratos, imunidade soberana, danos, causalidade, deveres de divulgação e jurisdição regulatória variam. Opedido de julho de 2023do senador Ron Wyden solicitou que o Departamento de Justiça, a Comissão Federal de Comércio e o CSRB investigassem as práticas da Microsoft. Esse pedido é evidência de preocupação regulatória, não evidência de que as agências solicitadas chegaram a uma conclusão de aplicação da lei. Nenhum registro público com fonte usada aqui estabelece um julgamento legal final para o Storm-0558.

O que a remediação durável deve provar

O incidente deve ser considerado operacionalmente encerrado apenas em relação à técnica observada de chave de 2016. O problema mais amplo de garantia permanece aberto até que a remediação possa ser demonstrada em várias dimensões.

Custódia e ciclo de vida da chave

A Microsoft deve ser capaz de mostrar que as chaves de assinatura de consumidor e corporativo são geradas e usadas dentro de sistemas protegidos por hardware, não podem ser exportadas para ambientes de depuração ou corporativos gerais, são rotacionadas automaticamente em uma frequência proporcional ao seu poder e geram alertas acionáveis quando a idade ou exceções de política excedem os limites. A rotação de emergência deve ser exercida sem causar o tipo de interrupção que levou à pausa de 2021. A segmentação de chaves deve reduzir o número de locatários, serviços e classes de conta expostos por qualquer chave.

Correção da validação

Cada serviço confiante deve usar bibliotecas aprovadas que validem assinatura, emissor, público, locatário, classe de conta, emissor da chave, tempo de vida e autorização específica do serviço. Adocumentação do OpenID Connectda Microsoft explica que os metadados de descoberta expõem endpoints do provedor e chaves públicas de assinatura; não torna cada chave listada intercambiável para cada recurso. Testes de conformidade devem intencionalmente apresentar tokens assinados corretamente, mas com escopo errado, e verificar a rejeição.

Resistência a falsificação além de assinaturas sem estado

Um token portador apenas de assinatura pode permanecer convincente depois que a chave de assinatura é roubada. Validação com estado, abordagens de prova de posse, marcadores de emissão proprietários, tempos de vida limitados e revogação rápida podem reduzir esse risco. O objetivo não é abandonar os padrões, mas garantir que a posse de uma chave não crie autoridade global não observável.

Telemetria do provedor e do cliente

O provedor deve detectar combinações impossíveis de tokens em todo o serviço e preservar evidências internas por tempo suficiente para campanhas sofisticadas. Os clientes devem receber eventos de acesso a caixas de correio e identidade por padrão, sem um portão premium, em um esquema documentado que possa ser exportado para ferramentas de análise independentes. Seis meses de logs acessíveis ao cliente, conforme recomendado pelo CSRB e adotado como meta da SFI, devem ser um piso para atividades de identidade na nuvem de alto valor, em vez de um teto aspiracional.

Comunicação de incidentes

As divulgações técnicas devem trazer histórico de versões, níveis de confiança e questões não resolvidas explícitas. Quando uma hipótese publicada perde suporte probatório, a correção deve ser rápida e proeminente. Um provedor não deve exigir que um órgão de supervisão pergunte repetidamente se um relato de causa raiz impreciso será corrigido.

Garantia independente

Os relatórios de progresso da empresa são úteis, mas insuficientes para um plano de controle com dependência do setor público. Os clientes federais precisam de mecanismos de garantia que possam testar rotação, isolamento de chave, cobertura do validador, desempenho de alertas e retenção forense sem expor segredos. O ponto não é a publicação de arquitetura sensível. É a evidência de que os controles declarados operam em produção, incluindo sistemas legados e ambientes adquiridos.

Lições práticas para clientes de nuvem e compradores públicos

Os clientes não podem reparar o sistema de assinatura de um provedor, mas podem tornar a dependência mais gerenciável.

Primeiro, adquira evidências, não apenas recursos. Contratos e linhas de base de serviço devem identificar quais eventos de acesso, identidade, administrativos, token e caixa de correio estão disponíveis; com que rapidez eles chegam; por quanto tempo permanecem pesquisáveis; e se os clientes podem exportá-los. Os logs devem ser testados com eventos simulados antes de um incidente.

Segundo, construa análises em torno do acesso a dados, bem como do login. Um token forjado pode contornar as anomalias que os defensores esperam do roubo de senha. O MailItemsAccessed importou porque observou a ação protegida, não meramente a cerimônia de autenticação. Ambientes de alto valor devem ter linha de base de acesso incomum a caixas de correio, identificadores de aplicativos, geografia, comportamento do cliente e volume de acesso.

Terceiro, mantenha um caminho de escalação que assuma que o provedor pode fazer parte do incidente. Uma equipe de locatário deve saber como entrar em contato com a organização de resposta de segurança do provedor, a CISA ou a autoridade nacional relevante, as autoridades policiais e a liderança executiva sem depender do canal de e-mail potencialmente comprometido.

Quarto, trate a concentração de identidade como um risco de continuidade. Os compradores devem saber quais serviços críticos compartilham uma raiz de identidade, o que um comprometimento de chave de todo o provedor poderia alcançar e quais funções podem continuar enquanto a confiança na nuvem está sendo restabelecida. Isso pode justificar segmentação, identidades administrativas separadas, armazenamento de log independente ou diversidade seletiva para os fluxos de trabalho mais sensíveis.

Quinto, teste os compromissos de notificação e evidência do provedor. Uma promessa de notificar "clientes afetados" é tão útil quanto a capacidade do provedor de identificá-los. No Storm-0558, apenas a Microsoft poderia identificar a maioria das vítimas porque os tokens forjados operavam dentro de seu serviço. Isso torna a telemetria em todo o provedor e o alcance oportuno parte da arquitetura de detecção do cliente.

Finalmente, não confunda responsabilidade compartilhada com capacidade igual. Os clientes devem proteger o que controlam. Os provedores devem ser responsáveis por controles exclusivos do provedor. Reguladores e compradores devem se concentrar na fronteira entre eles, porque é onde os requisitos de segurança são mais propensos a se tornar ambíguos, opcionais ou monetizados.

Avaliação

A intrusão do Exchange Online do Storm-0558 foi uma falha de identidade de nuvem evitável com um caminho de aquisição inicial de chave não resolvido. As evidências públicas apoiam uma constatação de alta confiança de que a Microsoft permitiu que uma chave de assinatura antiga de consumidor permanecesse confiável, falhou em impor a fronteira entre a validação de token de consumidor e corporativo, não teve detecção suficiente do lado do provedor para combinações de token que seus próprios sistemas não emitiriam e reteve poucas evidências para reconstruir a fuga da chave.

Também apoia uma constatação de que o registro de cliente com acesso premium moldou materialmente quem poderia detectar e investigar a campanha.

A resposta da Microsoft abordou o caminho de acesso observado e depois se expandiu para reformas de gerenciamento de chaves, validação, logs, governança e incentivos. A aceitação por Brad Smith das constatações do CSRB é significativa. Também o são a remoção do acesso pago para eventos principais e o movimento em direção à rotação automatizada com suporte de hardware. A questão de responsabilidade restante é se essas mudanças são completas, duráveis e verificáveis de forma independente em toda a infraestrutura de identidade legada e atual da Microsoft.

A lição mais ampla do incidente não é que os serviços de nuvem são inerentemente menos seguros do que sistemas operados pelo cliente. Grandes provedores podem implantar controles, inteligência e remediação em uma escala que a maioria dos clientes não pode. A lição é que a escala também concentra autoridade oculta. Quando uma chave de assinatura e um erro de validação podem alcançar organizações em todo o mundo, a segurança depende da disciplina de chave interna do provedor e de evidências que os clientes não podem gerar por si mesmos.

A continuidade do setor público, portanto, requer uma definição mais ampla de confiabilidade do serviço. A disponibilidade é necessária, mas também a confidencialidade, identidade confiável, evidências reconstruíveis, divulgação rápida e um caminho crível para restaurar a confiança após um comprometimento do lado do provedor. O Storm-0558 deixou o Exchange Online funcionando. Ainda assim, interrompeu a premissa sob a qual os governos o usavam. É por isso que o incidente pertence ao registro como uma falha de responsabilidade da nuvem, em vez de meramente outra operação de espionagem bem-sucedida.