Ataques contra identidades em ambientes Azure crescem 155x

Entre junho e julho de 2026, pesquisadores identificaram uma onda de ataques automatizados contra identidades em ambientes Microsoft Azure e Microsoft 365, com um único episódio somando mais de 81 milhões de tentativas de login em 14 dias e comprometendo contas em pelo menos 64 organizações — mesmo em empresas que já tinham MFA habilitado. O vetor não foi uma vulnerabilidade de dia zero: foi um fluxo de autenticação legado (OAuth ROPC) explorando políticas de Acesso Condicional mal configuradas. O episódio é sintoma de uma tendência maior: o volume de ataques de credential spray contra ambientes protegidos cresceu mais de 155 vezes em seis meses, segundo a empresa de segurança que identificou a campanha.

Se sua empresa opera em Microsoft Azure ou Microsoft 365, este artigo detalha o que aconteceu, por que o MFA “ativado” não foi suficiente para barrar o ataque, e o que precisa ser revisado agora no seu Microsoft Entra ID para não ser a próxima estatística.

O que aconteceu: a campanha que driblou o MFA de dezenas de empresas

Segundo a investigação publicada pela Huntress em 30 de junho de 2026 (e atualizada nas semanas seguintes), pesquisadores identificaram uma campanha automatizada de password spray contra a interface de linha de comando do Azure (Azure CLI). Entre 12 e 26 de junho de 2026, os atacantes fizeram mais de 81 milhões de tentativas de login contra tenants protegidos pela Huntress, comprometendo 78 contas de usuário em 64 organizações.

O ritmo dos comprometimentos não foi constante: entre os dias 12 e 21 de junho, a média era de duas a quatro contas comprometidas por dia. Em 22 de junho, houve um salto brusco — 30 identidades comprometidas em um único dia, em 23 empresas diferentes. A maior parte do tráfego malicioso partiu de um provedor de infraestrutura identificado como LSHIY LLC, sob o número de sistema autônomo AS32167.

O ataque não parou aí

Depois que a Huntress reportou a atividade e o provedor suspendeu o usuário responsável, a campanha simplesmente migrou de infraestrutura. Em atualizações publicadas nas semanas seguintes, os pesquisadores documentaram a mesma técnica sendo reaplicada a partir de dois outros provedores — com 87% das contas atacadas via a nova infraestrutura sendo as mesmas que já haviam sido alvo na campanha original. Em uma dessas ondas, o volume voltou a subir para cerca de 1,5 milhão de tentativas de login por dia. Ou seja: bloquear a origem não encerrou o ataque — apenas o deslocou.

Por que o MFA “ativado” não impediu o ataque

Este é o ponto que mais deveria preocupar times de TI: 15 das 23 empresas comprometidas no pico de 22 de junho já tinham MFA implementado e reforçado via política de Acesso Condicional (CAP). O problema não foi ausência de MFA — foi configuração incompleta. A investigação identificou quatro falhas recorrentes:

• MFA aplicado a apps específicos, não a “Todos os Aplicativos de Nuvem”: algumas empresas exigiam MFA apenas para os Portais de Administração da Microsoft, deixando os logins via Azure CLI fora do escopo da política.
• MFA restrito a grupos específicos: políticas configuradas apenas para “Somente Administradores” não cobriam os usuários comuns que acabaram comprometidos.
• MFA condicionado a “localizações não confiáveis”: como os IPs dos atacantes eram geolocalizados de forma inconsistente (alguns como EUA, outros como China), parte do tráfego malicioso escapou da regra.
• MFA em modo apenas de relatório (“report-only”): configurado, mas nunca efetivamente aplicado — em duas empresas, a política existia só no papel.

Oito das empresas atingidas não tinham nenhuma política de MFA. Mas o dado mais relevante do incidente é justamente o oposto do que a maioria assume: ter MFA habilitado não é o mesmo que estar protegido se a política não cobrir o fluxo de autenticação específico que o atacante está usando.

O mecanismo técnico: OAuth ROPC

Os atacantes usaram credenciais previamente vazadas — usuário e senha válidos, nunca rotacionados após um vazamento anterior — e as validaram através do fluxo OAuth ROPC (Resource Owner Password Credentials), um método de autenticação legado, já depreciado no padrão OAuth 2.1, mas ainda suportado pelo Azure CLI. O ROPC envia usuário e senha diretamente ao endpoint de token da aplicação, sem disparar nenhum prompt interativo de MFA — é assim que o atacante consegue autenticar com sucesso mesmo em ambientes onde o MFA está, teoricamente, ativo.

Para quem já lida com contramedidas contra sequestro de sessão pós-MFA, esse padrão é familiar: no artigo Como proteger o Microsoft 365 contra phishing e malware, já havíamos detalhado como ataques do tipo AiTM (Adversary-in-the-Middle) capturam o cookie de sessão depois de um MFA bem-sucedido. O caso do Azure CLI é uma variação do mesmo princípio: contornar o MFA não pela força bruta contra o segundo fator, mas explorando um caminho de autenticação que nunca o solicita.

A escala do problema: não é um incidente isolado

A campanha específica contra o Azure CLI é apenas o episódio mais visível de uma tendência mais ampla. Segundo a Huntress, o volume de ataques de credential spray contra sua base de clientes cresceu mais de 155 vezes nos últimos seis meses, com um valor médio atual de aproximadamente 1.964 tentativas de login malsucedidas por mês, por tenant protegido — e uma mediana de 804. O direcionamento dos ataques não é seletivo por setor: a escolha dos alvos parece se basear inteiramente na prevalência das credenciais em listas de senhas vazadas já em circulação.

Esse crescimento acompanha uma tendência que a própria Microsoft já vinha documentando. O Relatório de Defesa Digital da Microsoft registrou um crescimento de 2,75 vezes ano a ano em ataques de ransomware operados por humanos — uma categoria de ataque que, na maioria dos casos, começa exatamente por um comprometimento de identidade, não por uma vulnerabilidade técnica sofisticada. A própria documentação da Microsoft para o Entra ID Protection reconhece que, apesar do MFA conseguir mitigar a esmagadora maioria dos ataques de identidade automatizados, o crescimento em escala e sofisticação continua sem sinais de desaceleração.

Como saber se sua empresa está exposta

Antes de qualquer ação corretiva, vale um diagnóstico rápido. Sua empresa está em risco elevado se qualquer uma das situações abaixo for verdadeira:

• Administradores ou desenvolvedores usam o Azure CLI regularmente para gerenciar recursos, e essa autenticação não está explicitamente coberta pela política de Acesso Condicional;
• Existem service principals ou identidades não humanas com segredos de longa duração e sem MFA — um alvo particularmente atrativo, já que garantem acesso privilegiado persistente se comprometidos;
• A política de MFA foi configurada por aplicativo específico, e não para “Todos os Aplicativos de Nuvem”;
• Existem exceções de “localização confiável” na política de Acesso Condicional;
• Alguma política de MFA está em modo apenas de relatório (report-only) e nunca foi efetivamente promovida a “enforced”;
• Sua empresa nunca revisou se o fluxo OAuth ROPC está bloqueado explicitamente.

Se você já opera segurança de acesso remoto para além do Microsoft 365, o mesmo princípio de “nunca confiar, sempre verificar” se aplica à camada de rede — descrevemos essa lógica em detalhe no artigo sobre Sophos ZTNA e a evolução da VPN para o trabalho híbrido.

Como proteger seu ambiente Entra ID e Azure

As recomendações abaixo combinam a orientação técnica publicada pela Huntress com boas práticas consolidadas de governança de identidade no Microsoft Entra ID.

1. Exija MFA para todos os usuários, todos os aplicativos de nuvem e todos os tipos de cliente — sem exceções

É o ajuste mais decisivo. Configurar a política de Acesso Condicional para cobrir “All Users, All Cloud Apps, All Client App Types” — em vez de aplicativos ou grupos específicos — fecha exatamente a brecha que essa campanha explorou. A configuração userStrongAuthClientAuthNRequired reforça a autenticação forte na camada do cliente e bloqueia diretamente fluxos ROPC.

2. Bloqueie ou restrinja o fluxo OAuth ROPC

Como o ROPC não passa pelo endpoint de autorização onde as políticas de Acesso Condicional são normalmente aplicadas, ele precisa ser tratado como exceção perigosa por padrão — não como funcionalidade neutra. Times de TI devem revisar se esse fluxo está habilitado e desativá-lo sempre que não houver uma dependência técnica legítima.

3. Restrinja o acesso ao Azure CLI para usuários não administrativos

Nem todo usuário precisa de acesso via linha de comando ao ambiente Azure. Reduzir essa superfície para quem realmente administra recursos diminui o número de contas expostas a esse vetor específico.

4. Revise identidades não humanas (service principals) com a mesma prioridade das contas de usuário

Contas de serviço com segredos de longa duração e sem MFA são um dos alvos mais valiosos em um ambiente comprometido — oferecem acesso privilegiado persistente sem o atrito de uma autenticação interativa. Aplique rotação de credenciais, prefira identidades gerenciadas quando possível e monitore o uso dessas contas com o mesmo rigor de contas administrativas.

5. Priorize a resposta por validade de credencial, não por volume de tentativas

Um dos aprendizados mais contraintuitivos da investigação: o volume de tentativas de spray por tenant não indica risco real de comprometimento — os tenants mais “esprayados” muitas vezes são os que menos sofrem comprometimentos efetivos. A priorização de resposta deve olhar para tentativas de login com credenciais válidas, não para o volume bruto de tentativas falhas.

6. Vá além do MFA básico para contas críticas

Para administradores e identidades privilegiadas, considere FIDO2 ou passkeys — métodos resistentes a phishing por design, já que a chave criptográfica nunca sai do dispositivo — e frequência de sessão configurada para forçar reautenticação periódica, limitando a janela de uso de um token roubado. Esses controles avançados já são discutidos com mais profundidade no nosso guia sobre proteção do Microsoft 365 contra phishing e malware.

7. Trate governança de dados e IA como parte do mesmo perímetro de identidade

Ambientes onde Copilot e outros assistentes de IA já operam sobre dados corporativos herdam qualquer fragilidade na camada de identidade — se uma conta comprometida tem acesso a documentos sensíveis, um agente de IA autorizado a usar essa conta amplia automaticamente o raio de exposição. O Microsoft Purview ajuda a rastrear esse risco, mas não substitui uma política de Acesso Condicional bem configurada na origem.

O que esse incidente não significa

Não significa que o MFA “não funciona”. A própria Microsoft reconhece que o MFA continua mitigando a esmagadora maioria dos ataques automatizados de identidade. O que esse incidente prova é que MFA parcialmente configurado cria uma falsa sensação de segurança — pior, em certo sentido, do que a ausência total de MFA, porque a equipe de TI acredita estar protegida quando não está.

Não significa que o Azure é menos seguro que outras nuvens. O vetor explorado — um fluxo de autenticação legado mal coberto por políticas de acesso — não é exclusividade da Microsoft; é um padrão recorrente em qualquer plataforma que precisa manter compatibilidade retroativa com integrações antigas. O que diferencia uma organização exposta de uma protegida não é o provedor de nuvem, é a maturidade da configuração de identidade.

Não significa que reagir à origem do ataque resolve o problema. Como mostrou o deslocamento da campanha entre três provedores de infraestrutura diferentes, bloquear um IP, um ASN ou um provedor específico é insuficiente sozinho. A correção estrutural está na configuração das políticas — não na perseguição da origem.

Conclusão

O episódio documentado pela Huntress não é uma anomalia isolada — é a manifestação mais visível de uma tendência que já vinha sendo registrada em relatórios de ameaças ao longo de 2026: identidade se tornou o vetor de ataque preferencial contra ambientes corporativos, superando exploits técnicos sofisticados em volume e eficácia. A boa notícia é que a correção não exige uma reformulação completa da infraestrutura — exige revisar, com precisão, se as políticas de Acesso Condicional realmente cobrem todos os fluxos de autenticação que sua empresa usa, incluindo os que a maioria das equipes de TI nunca para para questionar, como o Azure CLI e as contas de serviço.

Sua empresa sabe se as políticas de Acesso Condicional cobrem todos os fluxos de autenticação usados no seu ambiente Azure e Microsoft 365? A InfoB realiza diagnósticos completos de cibersegurança para identificar gaps reais de configuração antes que atacantes o façam.

Solicitar diagnóstico de segurança de identidade

Perguntas frequentes sobre ataques a identidades no Azure

O que é um ataque de password spray?

É uma variante de força bruta em que o atacante testa um pequeno número de senhas comuns contra uma grande lista de contas, em vez de testar muitas senhas contra uma única conta. Essa abordagem evita políticas de bloqueio por tentativas excessivas em uma mesma conta, tornando o ataque mais difícil de detectar por métodos tradicionais.

Como os atacantes conseguiram driblar o MFA no ataque contra o Azure CLI?

Usando o fluxo de autenticação OAuth ROPC (Resource Owner Password Credentials), um método legado que envia usuário e senha diretamente ao endpoint de token sem disparar um prompt interativo de MFA. Muitas empresas tinham MFA habilitado, mas a política de Acesso Condicional não cobria esse fluxo específico.

O que é OAuth ROPC e por que ele é considerado inseguro?

ROPC é um tipo de concessão OAuth 2.0 já depreciado no padrão OAuth 2.1. Ele não oferece suporte a fluxos de autenticação modernos como MFA ou SSO, permitindo que uma aplicação troque diretamente um usuário e senha por um token de acesso — o que o torna incompatível com controles de segurança baseados em autenticação interativa.

Ter MFA habilitado é suficiente para proteger contra esse tipo de ataque?

Não necessariamente. O incidente mostrou que 15 de 23 empresas comprometidas em um único dia já tinham MFA implementado, mas configurado de forma incompleta — cobrindo apenas aplicativos específicos, grupos de usuários específicos, ou com exceções de localização que os atacantes conseguiram contornar. A cobertura da política importa tanto quanto a existência dela.

O que são service principals e por que são um alvo importante?

Service principals são identidades não humanas usadas por aplicações e automações para acessar recursos do Azure. Muitas vezes usam segredos de longa duração e não têm MFA configurado, o que os torna um alvo atrativo para atacantes que buscam acesso privilegiado persistente sem o atrito de uma autenticação interativa.

Bloquear o IP ou provedor de origem do ataque resolve o problema?

Não sozinho. No caso documentado, a campanha migrou para dois outros provedores de infraestrutura depois que a origem original foi bloqueada, mantendo grande parte dos mesmos alvos. A correção eficaz está em fechar as brechas de configuração nas políticas de Acesso Condicional, não apenas em reagir à origem do tráfego malicioso.

Leia também no blog da InfoB

• Microsoft Entra ID: o guia completo para identidade e acesso corporativo
• Como proteger o Microsoft 365 contra phishing e malware
• Sophos ZTNA: a evolução da VPN para o trabalho híbrido
• O que é um SOC? Guia completo
• MDR, XDR e MXDR: por que viraram prioridade em 2026