Uma campanha agressiva de password spraying contra ambientes Microsoft 365 gerou mais de 81 milhões de tentativas de autenticação em apenas duas semanas, comprometendo pelo menos 78 contas em 64 organizações. A descoberta é da Huntress, empresa de cibersegurança gerida que documentou o ataque entre 12 e 26 de junho, e que alerta para um detalhe particularmente preocupante: muitas das organizações afetadas tinham autenticação multifator (MFA) ativa, mas configurada de forma incompleta.
Como funciona o ataque
O atacante testou pares de nome de utilizador e password válidos, obtidos de fugas de dados anteriores e nunca substituídos pelos utilizadores, contra a interface de linha de comandos do Azure (Azure CLI), a ferramenta que administradores usam para gerir recursos na cloud da Microsoft. Depois de encontrar uma combinação válida, o atacante autenticava-se através do mecanismo OAuth ROPC (Resource Owner Password Credentials), um método de autenticação já considerado obsoleto que envia a password diretamente para o endpoint de token, sem qualquer pedido interativo de MFA.
Este pormenor técnico é o cerne do problema: o ROPC não foi concebido para suportar métodos modernos de autenticação como o MFA ou o single sign-on. Por isso, mesmo organizações que tinham políticas de acesso condicional (Conditional Access Policies) configuradas acabaram por ficar expostas, porque essas políticas simplesmente não cobriam este fluxo de autenticação específico.
Porque contornou o MFA em tantas organizações
Segundo a Huntress, das 23 organizações afetadas pelo pico de ataques registado a 22 de junho, 15 tinham MFA implementado e reforçado através de políticas de acesso condicional. Ainda assim, o mecanismo de proteção falhou por várias razões distintas: em alguns casos, o MFA estava configurado apenas para aplicações específicas, como os portais de administração, e não para “todas as aplicações na cloud”, deixando de fora precisamente os pedidos de autenticação feitos através do Azure CLI. Noutros casos, o MFA só se aplicava a grupos de utilizadores específicos, como administradores, excluindo as contas comuns que acabaram por ser comprometidas.
Houve ainda situações em que o MFA apenas era exigido para acessos a partir de localizações não confiáveis, um critério que o atacante conseguiu contornar porque os seus endereços IP eram, por erro de geolocalização de terceiros, identificados como provenientes dos Estados Unidos. Em pelo menos duas organizações, a política de MFA estava configurada apenas em modo de “relatório”, ou seja, nunca chegou a ser realmente aplicada. Oito das organizações afetadas não tinham, sequer, qualquer política de MFA implementada.
A escala e a evolução do ataque
O ritmo de tentativas de login manteve-se elevado ao longo de todo o período analisado, com a Huntress a registar entre duas e quatro contas comprometidas por dia entre 12 e 21 de junho. A situação agravou-se significativamente a 22 de junho, quando 30 contas em 23 organizações foram comprometidas num único dia. Este tipo de ataque não é um caso isolado: a Huntress refere que, nos últimos seis meses, o volume de ataques de credential spraying contra os seus clientes aumentou mais de 155 vezes, com as organizações protegidas a registar, em média, quase dois mil tentativas falhadas de login por mês.
Quem está por detrás do ataque
A maioria do tráfego malicioso foi associada a um intervalo de endereços IPv6 controlado pela LSHIY LLC, um fornecedor de infraestrutura de Internet com moradas registadas em edifícios industriais em Hong Kong e na China continental, além de um escritório partilhado em Nova Iorque, um espaço de aluguer genérico que não permite identificar quem gere de facto a empresa. A LSHIY opera pelo menos dois sistemas autónomos distintos, incluindo o mencionado AS32167, e ferramentas de terceiros geolocalizam parte destes endereços na China, embora outras ferramentas de geolocalização os associem, por erro, aos Estados Unidos, o que ajuda a explicar como o atacante conseguiu contornar regras de acesso condicional baseadas em localização geográfica.
A identidade exata de quem está por detrás da campanha permanece desconhecida, e a Huntress já reportou a atividade à LSHIY através do respetivo canal de denúncia de abusos, sem resposta até à data. Este tipo de ambiguidade quanto à origem geográfica real de um atacante é, aliás, um obstáculo recorrente na resposta a incidentes deste género, e mais um argumento a favor de defesas baseadas na validade das credenciais e no comportamento de autenticação, e não apenas na origem geográfica do tráfego.
O que fazer para proteger a sua organização
A Huntress e outros investigadores de segurança recomendam um conjunto de medidas concretas para organizações que utilizem Microsoft 365 e Azure:
- Configurar as políticas de acesso condicional para exigir MFA, sem exceções, para todos os utilizadores, todas as aplicações na cloud e todos os tipos de aplicação cliente, em vez de aplicar o MFA apenas a grupos ou aplicações específicas.
- Restringir o uso da aplicação Azure CLI a utilizadores administrativos, removendo o acesso a utilizadores comuns que normalmente não precisam desta ferramenta.
- Rever se alguma política de acesso condicional está ainda em modo de “apenas relatório”, já que, nesse estado, não bloqueia qualquer tentativa de acesso, apenas regista.
- Não depender exclusivamente do volume de tentativas de login para acionar alertas, uma vez que os tenants mais visados nem sempre são os que sofrem mais comprometimentos reais; a validade das credenciais usadas é um indicador mais fiável.
Porque é que isto importa
Este caso ilustra bem como a autenticação multifator, apesar de continuar a ser uma das defesas mais eficazes contra o roubo de credenciais, só protege eficazmente quando está corretamente configurada para cobrir todos os métodos de autenticação em uso numa organização. Para entidades abrangidas pelo Regime Jurídico da Cibersegurança português, o Decreto-Lei n.º 125/2025 que transpõe a diretiva NIS2, este tipo de incidente reforça a importância de auditorias periódicas às políticas de acesso condicional, e não apenas à sua existência nominal. Ter MFA “ativado” no papel não é o mesmo que ter MFA a cobrir, na prática, todos os fluxos de autenticação que uma organização utiliza.
Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela Huntress, reportados pela BleepingComputer, SecurityWeek e outros órgãos de imprensa internacional especializados em cibersegurança. Os gráficos incluídos neste artigo pertencem à Huntress e são reproduzidos com a devida atribuição.