Em 21 de outubro de 2026, a Microsoft publicou a análise de um caso que obriga qualquer gestor a reabrir a lista de aplicativos conectados ao ambiente da empresa. Segundo o relatório, um ator identificado como Storm-0940 comprometeu aplicativos multi-tenant da ConnectWise — entre eles o Cloud Backup — e usou a confiança que esses aplicativos já tinham dentro dos ambientes Microsoft 365 dos clientes para autenticar sem nenhuma entrada interativa de usuário.
Não houve senha vazada nem phishing no cliente. O acesso entrou por um aplicativo que a própria empresa havia autorizado, provavelmente meses antes, em uma tela de consentimento que ninguém guardou na memória.
Esse é o ponto que interessa a quem presta serviço profissional. Em uma consultoria, as integrações se acumulam: proposta, assinatura eletrônica, BI, CRM, gestão de horas, conector de planilhas, aplicativo do próprio fornecedor de TI. Cada conexão é uma identidade com permissão dentro do seu ambiente — e nenhuma depende de senha ou de MFA para funcionar.
O que a Microsoft descreveu no caso ConnectWise
A sequência relatada é instrutiva porque nenhuma etapa dependeu de descuido do cliente final.
Entre 10 e 14 de outubro, a infraestrutura do ator conduziu uma campanha de pulverização de senhas entre ambientes. A Microsoft contabilizou mais de 151 mil eventos de falha de autenticação, com pico próximo de 2.900 falhas por minuto em 11 de outubro, 327 contas visadas em oito organizações e tentativas de entrada em mais de 2.250 ambientes. Bloqueios de conta responderam por quase 98% da atividade e, nessa campanha de pulverização, não houve autenticação bem-sucedida.
O que funcionou foi outra coisa. Em 15 de outubro surgiram os primeiros relatos públicos do comprometimento da ConnectWise, e os indicadores coincidiam com a mesma faixa de endereços da pulverização. Com o controle das identidades de aplicativos de nuvem do fornecedor, os agentes do ator passaram a usar a confiança já concedida nos ambientes dos clientes. A partir daí, segundo o relatório: reconhecimento via Microsoft Graph, adição de credenciais aos aplicativos para manter acesso, tentativas de alterar identidades, grupos e funções privilegiadas, leitura em massa de segredos em cofres do Azure Key Vault e, em um dos casos, um aplicativo que atribuiu a si mesmo a função de administrador global. Em várias intrusões, o acesso privilegiado em nuvem foi alcançado em menos de três horas desde o início do ataque.
A ConnectWise suspendeu serviços — Cloud Backup, SaaS Security e Cloud Management — e revogou os certificados usados nas conexões dos aplicativos afetados, segundo reportagem do The Record. A empresa afirmou não ter indicação de comprometimento dos dados de backup e reconheceu não ter visibilidade dentro dos ambientes de parceiros e clientes, o que a impede de dizer se um ambiente específico foi acessado. A Huntress, citada na mesma reportagem, relatou entradas não autorizadas em 162 ambientes.
Vale registrar a ressalva da própria Microsoft: a presença de um aplicativo afetado, ou mesmo uma autenticação bem-sucedida, não prova por si só que dados foram acessados ou extraídos. A conclusão exige correlação de registros.
Por que a consultoria é um alvo de passagem
Uma consultoria raramente é o destino final de um ataque assim. Ela é o caminho. No seu ambiente há propostas, planilhas de custo, diagnósticos, atas, pareceres e, com frequência, credenciais de acesso a sistemas de clientes: um acervo concentrado, de baixo volume e alto valor.
Há um segundo efeito. Quando o incidente nasce em um fornecedor de software, o cliente não distingue camadas: ele pergunta se os dados dele estavam ali. Responder com precisão depende de ter, antes do incidente, um inventário do que está conectado e com qual permissão. A TI para consultorias existe em boa medida para sustentar essa resposta.
Esse risco não substitui os anteriores, ele se soma. Já tratamos aqui do caso de instaladores falsos que abrem acesso remoto ao ambiente e do mercado que revendia acesso a ambientes Microsoft 365. A diferença agora é a origem: não é o usuário que erra, é o fornecedor que é comprometido.
O inventário que quase nenhuma empresa tem
Pergunte a um gestor quantos aplicativos corporativos estão autorizados no ambiente da empresa e a resposta costuma ser uma estimativa — e o número real, quase sempre, é maior. A lista cresce por acúmulo. Alguém testou uma ferramenta em um projeto e autorizou o acesso. O conector entrou junto com uma integração que já nem é usada. O fornecedor anterior deixou o aplicativo dele conectado. Nenhuma delas aparece em relatório de acesso de usuário, porque não são usuários.
Em TI para consultorias, o inventário mínimo tem quatro colunas: qual é o aplicativo, qual é o publicador, quais permissões foram concedidas e quem concedeu. O relatório da Microsoft reforça algo importante: o aplicativo deve ser inventariado em todos os ambientes, inclusive naqueles em que a integração não é usada — porque a permissão continua válida mesmo sem uso.
Permissão de aplicativo e permissão delegada
A documentação da Microsoft separa dois tipos de permissão, e a diferença decide o tamanho do estrago.
Permissões delegadas deixam o aplicativo agir em nome de um usuário autenticado, limitado ao que aquele usuário já pode fazer. Permissões de aplicativo deixam o software acessar dados da organização inteira, sem usuário conectado — e, no texto do consentimento, terminam em "sem um usuário conectado".
É essa segunda categoria que precisa de leitura atenta. Um aplicativo de gestão de sites do SharePoint precisa de acesso a coleções de sites — não necessariamente a todas as caixas de correio nem a personificação completa do diretório. A orientação da Microsoft para esses casos é direta: quando a permissão pedida não corresponde à função do software, não conceda, e procure o publicador antes de decidir.
Como fechar a porta do consentimento
Essas medidas são de configuração, não de investimento, e valem para qualquer empresa com Microsoft 365.
- Restrinja o consentimento de usuário a publicadores verificados e a permissões de baixo impacto, em vez de manter o padrão permissivo que aceita qualquer aplicativo. A orientação da Microsoft sobre consentimento de usuário descreve cada opção da política.
- Ative o fluxo de consentimento administrativo, para que o pedido do usuário chegue a um responsável em vez de ser negado em silêncio ou resolvido por fora.
- Exija atribuição de usuário nos aplicativos aprovados, limitando quem consegue usar cada integração.
- Aplique o menor privilégio nas permissões de aplicativos multi-tenant: revise o que já foi concedido e revogue o que não é necessário. Alterar a política de consentimento não afeta concessões antigas — elas precisam ser revogadas uma a uma.
- Monitore adições de credenciais e atividade anômala de aplicativos sem usuário conectado, com atenção aos que têm privilégio alto.
- Revogue o consentimento ou desative a entrada de aplicativos que não são mais usados ou não são mais confiáveis.
A documentação sobre avaliação de pedidos de consentimento detalha como auditar o que já está concedido e acompanhar a atividade de consentimento.
O que fazer quando o alerta vem do fornecedor
Se um fornecedor comunicar comprometimento, a ordem das ações muda o resultado. As recomendações da Microsoft no caso ConnectWise seguem esta lógica:
- Preserve evidência antes de mudar qualquer coisa. Excluir o aplicativo corporativo como primeira reação apaga o rastro de que você vai precisar.
- Mantenha desativadas as conexões afetadas até o fornecedor publicar instruções de restabelecimento.
- Levante os identificadores dos aplicativos envolvidos e os objetos de serviço correspondentes em cada ambiente, inclusive onde a integração está parada.
- Revise registros de autenticação e auditoria no período do incidente, com janela folgada para antes da data divulgada.
- Procure, na auditoria de identidade, adições de credenciais, novos proprietários, atribuições de função e concessões de consentimento. Revogue o que não deveria existir e gire credenciais onde houver atividade suspeita.
- Revise acessos a e-mail e arquivos, regras de encaminhamento e permissões delegadas.
- Confirme ao final que a rotação feita pelo fornecedor e a remediação no seu ambiente removeram todo acesso não autorizado. A rotação da credencial do fornecedor, sozinha, não encerra o caso: quem já teve acesso ao diretório pode ter criado outro caminho.
Esse roteiro só é executável se alguém tiver as credenciais administrativas, os registros preservados e o tempo para agir. É exatamente o que um serviço gerenciado de TI e um monitoramento contínuo do ambiente sustentam, e o que falta quando a TI é acionada por demanda.
O que pedir em contrato ao fornecedor de software
A consultoria é cliente de software e fornecedora de serviço ao mesmo tempo, então a mesma régua se aplica nas duas pontas. Vale ter por escrito: prazo de comunicação em caso de incidente, quem é notificado, se o fornecedor informa quais permissões o aplicativo dele mantém no seu ambiente, e como se dá a rotação de credenciais. Um SLA bem definido cobre tempo de resposta; o que estamos descrevendo aqui é obrigação de transparência, que raramente aparece em proposta comercial e precisa ser pedida.
Do lado da continuidade, o episódio traz um lembrete: quando o serviço de backup do fornecedor é suspenso como medida de contenção, a empresa fica sem aquela cópia justamente durante um incidente. É por isso que a estratégia de backup contra ransomware precisa prever mais de um caminho de restauração, com cópia imutável e teste periódico.
Onde essa rotina se encaixa
A revisão de aplicativos conectados não é um projeto, é uma rotina trimestral de meia hora: listar o que está autorizado, conferir publicador e permissão, remover o que não tem uso. Feita com regularidade, ela encurta a resposta no dia em que um fornecedor anuncia um comprometimento — e evita que a consultoria descubra, no meio do incidente, uma identidade de aplicativo com privilégio alto e sem dono definido.
A Diversa atua há mais de 20 anos com ambientes Microsoft 365, Entra ID, backup corporativo e monitoramento, hoje com mais de 2.500 dispositivos monitorados e SLA de 99,8%. Em incidentes críticos, a primeira resposta humana ocorre em menos de 30 minutos. A TI para consultorias que mantemos inclui esse inventário de identidades de aplicativos como parte da governança, não como tarefa extraordinária — na mesma linha do que já discutimos sobre identidade própria para agentes de IA, que são a próxima categoria de identidade não humana a entrar no ambiente.
Fontes
- Microsoft Security Blog, AI-driven, large-scale nation-state campaign using ARTEX enables supply chain compromise, 21/10/2026.
- The Record, ConnectWise suspends cloud backup service after supply chain attack, 19/10/2026.
- Microsoft Learn, Configure how users consent to applications.
- Microsoft Learn, Manage consent to applications and evaluate consent requests.