Storm-0940 abusa de apps OAuth após ataque à ConnectWise

O ataque à ConnectWise derrubou o backup em nuvem de milhares de clientes e revelou uma operação maior: a Microsoft atribui ao grupo alinhado ao Estado chinês Storm-0940 uma campanha que uniu o framework de IA agêntica ARTEX ao comprometimento da cadeia de suprimentos do ConnectWise Cloud Backup, antigo SkyKick. O golpe atinge em cheio organizações que concederam permissões a aplicações OAuth do produto dentro do Microsoft 365, com destaque para provedores de serviços gerenciados e seus clientes finais. A ação prioritária é manter as conexões do aplicativo afetado desabilitadas, revisar as entradas de entidades de serviço nos logs do Entra e preservar evidências antes de alterar qualquer configuração.

O que aconteceu

Os primeiros sinais públicos apareceram em meados de outubro. Entre os dias 10 e 14, a telemetria da Microsoft registrou um borrifamento de senhas automatizado contra contas corporativas; em 15 de outubro, surgiram relatos públicos sobre o comprometimento do aplicativo de backup em nuvem, com indicadores que apontavam para a mesma faixa de rede observada antes. No dia seguinte, o acesso não autorizado foi confirmado em 16 de outubro pela ConnectWise, que desligou o acesso das aplicações do Cloud Backup como proteção e classificou o caso como questão de segurança. Às 07:00 UTC de 17 de outubro, a fornecedora desabilitou as sete identidades de aplicação listadas em seu guia técnico e revogou os certificados usados nas conexões afetadas.

Em 21 de outubro, a Microsoft publicou a atribuição formal: o Storm-0940, ativo desde 2021 e historicamente voltado a roubo de dados via password spray e exploração de aplicações expostas, foi o responsável pelo comprometimento da aplicação multilocatária. A campanha com o ARTEX visou centenas de organizações no mundo inteiro, incluindo setores como aeroespacial e defesa, automotivo, químico, energia, serviços financeiros, governo, jurídico, manufatura, mídia, militar, semicondutores, software e fundações de pesquisa. A Microsoft ressalva que a atividade não decorreu de comprometimento ou vulnerabilidade em sistemas, produtos ou serviços da própria Microsoft.

A novidade operacional foi a escala. Agentes autônomos do ARTEX operaram em ritmo de máquina, autenticando em ambientes de clientes por meio de aplicações que já tinham acesso concedido, sem necessidade de entrada interativa de usuário. O tempo entre a seleção de um alvo e o acesso privilegiado caiu para uma janela em que um processo humano típico de triagem de alertas já nasce atrasado.

Como o ataque funcionou

A cadeia começa fora da rede da vítima. O atacante comprometeu credenciais de aplicações do Cloud Backup, material de autenticação OAuth com privilégios amplos concedidos por milhares de tenants. Com essas credenciais, os agentes autenticaram diretamente contra o Microsoft 365 no modo somente aplicação, um fluxo legítimo que não gera entrada de usuário e costuma ter monitoramento mais fraco nas operações de segurança. É o mesmo tipo de abuso de identidade confiável visto em outros incidentes recentes de plataformas Microsoft, como a campanha que roubou e-mails via EWS.

Depois da autenticação, o tráfego seguiu para o Microsoft Graph: reconhecimento do diretório, consulta de identidades privilegiadas e, em vários ambientes, modificação de credenciais da própria aplicação comprometida para garantir persistência. A Microsoft descreve casos com menos de 3 horas entre a escolha do alvo e o acesso privilegiado. A troca de credencial feita pelo agente pode continuar válida mesmo depois da correção do aplicativo original, funcionando como porta dos fundos em outras identidades, credenciais e serviços de nuvem.

O ARTEX é um framework aberto de teste de penetração, escrito em Go com interface em Next.js, que orquestra múltiplos agentes de linguagem do reconhecimento até a exfiltração com pouca intervenção humana e acumula os ativos descobertos em um grafo. Para o defensor, o que muda não é a sofisticação de cada técnica isolada, porque borrifamento de senhas e abuso de OAuth já são velhos conhecidos, mas a velocidade e o volume simultâneo de tentativas, que comprime o tempo de reação a minutos.

Números da campanha

Os dados divulgados dimensionam as duas frentes: o borrifamento de senhas que antecedeu o incidente e o movimento sobre os tenants conectados ao produto comprometido.

Nos dias 10 a 14 de outubro, a infraestrutura do grupo rodou o password spray contra 327 contas com mais de 111.000 falhas concentradas em um único dia. Ainda assim, a Microsoft não observou nenhuma autenticação bem-sucedida nessa frente: quase 98% da atividade resultou em resposta de bloqueio de conta. O dano veio pela outra porta, a das credenciais de aplicação roubadas do fornecedor, que dispensaram senha de usuário.

Sinais a investigar no tenant

Um checklist de caça direto ao padrão descrito, executável no centro de administração do Entra:

• Entradas de entidade de serviço: abra Monitoramento, Logs de entrada e a aba de entradas de entidade de serviço; filtre pelo Application ID indicado no guia da ConnectWise, cujo indicador público inclui 506e08f9-6e9a-4da4-942b-a099a03644ae. A aba padrão de entradas de usuário não mostra essa atividade.
• Endereços de origem fora do esperado: o tráfego normal do produto sai por faixa privada do Azure; entradas de endereços como 144.172.64.128 merecem investigação imediata.
• Atividade no Graph após entrada de aplicação: reconhecimento de diretório, leitura de identidades e grupos logo após uma entrada somente aplicação.
• Mudanças de credencial ou permissão: nova credencial adicionada a uma aplicação existente, alteração de papel privilegiado ou consentimento novo formam o padrão de persistência descrito.

A presença do aplicativo afetado, ou mesmo uma autenticação bem-sucedida dele, não prova acesso ou exfiltração de dados; a própria Microsoft faz essa ressalva. A gravidade se define pela combinação da entrada com atividade posterior no Graph e no diretório. Clientes do Defender XDR contam com detecções e consultas de caça prontas para atividade suspeita no Graph e infraestrutura conhecida.

Ações prioritárias de contenção

P1, agora: mantenha as conexões do aplicativo afetado desabilitadas até instrução formal de restauração da ConnectWise; não exclua a aplicação corporativa como primeiro passo, porque a exclusão destrói evidência e pode quebrar dependências; inventarie os IDs de aplicação citados no perfil da Microsoft e registre o Object ID local de cada entidade de serviço; correlacione entradas de entidade de serviço com chamadas do Graph e mudanças de diretório, separando atividade administrativa autorizada.

P2, na sequência: revise e reduza permissões de todas as aplicações OAuth com privilégios amplos no tenant, pelo princípio do menor privilégio; acelere a revogação de tokens e sessões de aplicações suspeitas, mecanismo que a própria Microsoft reforçou no Entra e que já abordamos ao cobrir a revogação acelerada de sessão roubada; documente a linha do tempo para eventual comunicação de incidente.

Para quem usa o produto: a restauração faseada anunciada em 28 de outubro exige senha nova, configuração de MFA e reautorização de cada tenant do Microsoft 365 em um novo aplicativo endurecido, o ConnectWise Cloud Backup for M365. Reautorizar não substitui a investigação de cada tenant, e reautorização isolada não confirma que backups voltaram: verifique se snapshots novos completam com sucesso depois da reconexão. A ConnectWise afirma que os arquivos de backup existentes permanecem criptografados e isolados, sem indicação de comprometimento, e que não há indicação de impacto em outros produtos da empresa.

Fontes

• Microsoft Threat Intelligence: campanha usando ARTEX habilita comprometimento de cadeia de suprimentos (21 de outubro de 2026)
• ConnectWise Trust Center: comunicados do incidente do Cloud Backup, antigo SkyKick