Um único grupo criminoso disparou mais de 81 milhões de tentativas de login contra contas do Microsoft 365 pelo Azure CLI entre 12 e 26 de junho de 2026 e conseguiu invadir 78 contas em 64 organizações, segundo a empresa de cibersegurança Huntress. O ataque usou um fluxo de autenticação depreciado chamado ROPC que burla o MFA mal configurado, transformando senhas vazadas em acesso direto a tenants corporativos. A origem rastreia à LSHIY LLC, provedor chinês, e o volume desse tipo de ataque cresceu 155 vezes em seis meses.

O ataque de escala inédita

Entre 12 e 26 de junho de 2026, um único grupo criminoso disparou mais de 81 milhões de tentativas de login contra contas do Microsoft 365 via Azure CLI e conseguiu invadir pelo menos 78 contas em 64 organizações. A revelação é da empresa de cibersegurança Huntress, publicada em 30 de junho. Para quem usa Azure ou Microsoft 365 no Brasil, a lição é dura: a campanha burlou justamente o MFA (autenticação multifator) que muita empresa acha que a protege.

Segundo a SecurityWeek, os atacantes comprometiam de 2 a 4 contas por dia durante a janela de duas semanas, com um pico em 22 de junho, quando 23 empresas foram comprometidas de uma vez. O volume de ataques de credential spray observado pela Huntress cresceu mais de 155 vezes nos últimos seis meses — um sinal claro de que essa técnica virou a moda dominante entre grupos de acesso inicial.

Como o ROPC burla o MFA

O coração técnico do ataque está num fluxo de autenticação chamado ROPC (Resource Owner Password Credentials). Nele, o cliente envia usuário e senha direto para o endpoint /token do Azure e recebe um token de acesso em troca — sem prompt interativo, sem pop-up, sem desafio de MFA. O ROPC foi depreciado em OAuth 2.1 justamente por não suportar autenticação moderna.

O problema é que o Azure CLI ainda aceita esse fluxo. Quando uma empresa ativa MFA apenas para “logins interativos” no navegador, o ROPC passa batido, porque tecnicamente não é interativo. A Huntress documentou que mesmo organizações com Conditional Access policies configuradas foram invadidas, porque as políticas não cobriam o fluxo ROPC. Em outras palavras: o MFA estava ligado, mas a porta dos fundos ficou aberta.

Os atacantes usaram listas de combos de usuário e senha vazadas — aquelas mesmas que circulam em fóruns criminosos após grandes vazamentos, como os 14 milhões de e-mails expostos recentemente. Não há engenharia social sofisticada nem zero-day: é força bruta silenciosa, milhares de tentativas por minuto, contra um fluxo que a própria Microsoft recomenda abandonar.

A origem chinesa: LSHIY LLC

Quase todas as tentativas partiram de faixas IPv6 controladas pela LSHIY LLC, um provedor de infraestrutura de internet registrado em Hong Kong, Wuhan (China) e Nova York, operando sob os sistemas autônomos AS32167 e AS955. Outros relatórios apontam que as faixas IPv6 associadas a esses ASNs têm origem chinesa.

A Huntress reportou a atividade maliciosa ao canal de abuso da LSHIY e não recebeu resposta. O silêncio é significativo: provedores que não respondem a denúncias de abuso viram refúgio padrão para operações de credential stuffing e botnets. A escalada começou no fim de maio e ganhou força em junho, indicando uma campanha deliberada e contínua, não um pico isolado.

Por que o MFA falhou

Dez empresas afetadas tinham MFA configurado — e foram invadidas mesmo assim. A Huntress identificou um padrão claro de erros de configuração que deixa buracos no escudo:

  • MFA só para alguns aplicativos na nuvem: a política cobria o portal web do Microsoft 365, mas não o fluxo ROPC usado pelo Azure CLI.
  • MFA só para certos grupos de usuários: contas de serviço, administradores legados ou contas não listadas ficaram desprotegidas.
  • MFA só para locais não confiáveis: o atacante usou ranges que algumas políticas tratavam como neutros.
  • MFA implementado mas nunca imposto: a política existia no portal, mas estava em modo de auditoria ou report-only.
  • Oito empresas simplesmente não tinham MFA nenhum — o cenário mais grave e, infelizmente, ainda comum no Brasil.

A mensagem da Huntress é direta: a conclusão não deve ser “MFA não funciona”, mas “MFA precisa cobrir todos os fluxos de autenticação, inclusive os não-interativos”. O ROPC é exatamente o fluxo que escapa das configurações preguiçosas. Não é a primeira vez que o MFA do Microsoft 365 mostra falhas: campanhas como o phishing CodeStorm já haviam demonstrado que a barreira pode ser circumventada com técnica e persistência.

O Brasil está na mira

O Microsoft 365 é a suíte corporativa dominante em empresas brasileiras, de pequenos escritórios a gigantes como bancos e varejistas. O Azure CLI é ferramenta padrão para times de DevOps, desenvolvedores e administradores de nuvem — exatamente as contas com privilégios altos sobre infraestrutura. Quando uma dessas contas cai, o atacante herda acesso a repositórios, bases de dados, faturamento e identidades inteiras do tenant.

O The Hacker News destaca que a campanha afetou negócios de todos os tamanhos, com foco em pequenas e médias empresas que dependem de provedores gerenciados (MSPs). No Brasil, onde muitos PMEs terceirizam o TI e raramente revisam políticas de Conditional Access, o risco é proporcionalmente maior. Uma conta comprometida via ROPC pode virar porta de entrada para Business Email Compromise, fraude financeira e até ransomware — exatamente o encadeamento que grupos criminosos buscam, como mostrou o caso em que uma healthtech perdeu dados de 1,4 milhão de pessoas a partir de um único ponto de invasão.

Como blindar o Azure agora

A boa notícia é que a correção não exige compra de produto novo, apenas configuração cuidadosa no Microsoft Entra ID (antigo Azure AD). As ações abaixo reduzem drasticamente a superfície de ataque ROPC.

  1. Bloqueie o fluxo ROPC: no Entra ID, crie uma Conditional Access policy que negue explicitamente a autenticação legacy e o grant type password. A Microsoft já recomenda desativar o ROPC há anos.
  2. Impor MFA para todos os aplicativos e todos os usuários: sem exceção para contas de serviço, administradores e grupos “esquecidos”. Cubra tanto logins interativos quanto non-interactive sign-ins.
  3. Desative protocolos de autenticação básica: Basic Auth e POP/IMAP legados são outros vetores clássicos de bypass de MFA.
  4. Monitore sign-ins non-interactive: configure alertas no Microsoft Sentinel ou no Entra para picos de falhas de login e tokens emitidos via ROPC.
  5. Bloqueie os ranges da LSHIY (AS32167 e AS955): adicione essas faixas IPv6 à lista de locais bloqueados ou de alto risco na política de Conditional Access.
  6. Force redefinição de senhas comprometidas: cruze suas contas com bases de vazamentos (Have I Been Pwned) e force troca imediata para senhas que aparecem em listas.
  7. Considere passkeys e FIDO2: chaves de segurança físicas eliminam ataques de senha no fluxo de raiz, porque não há senha para ser testada.

O episódio do Azure CLI é um lembrete desconfortável: segurança por checkbox não protege. Ativar MFA no portal e nunca mais olhar é exatamente o hábito que os atacantes da LSHIY exploraram 81 milhões de vezes. Em cibersegurança, o diabo mora na configuração — e os criminosos já sabem onde procurar.

Referências