Tem MFA ativado? Estas 81 milhões de tentativas mostram onde a proteção falha

Os ataques de password spraying deixaram de ser ruído de fundo nos registos de autenticação. A empresa de segurança Huntress reporta que o volume deste tipo de ataques disparou nos primeiros seis meses de 2026 e que uma única campanha, apoiada num fluxo de autenticação legado do Microsoft Entra ID, gerou dezenas de milhões de tentativas de início de sessão em apenas duas semanas — comprometendo contas em organizações que, em muitos casos, já tinham autenticação multifator (MFA) ativada. O detalhe que interessa a quem gere identidades não é a escala, mas o caminho: um fluxo OAuth obsoleto, o ROPC, que envia utilizador e palavra-passe diretamente para o endpoint de token, sem qualquer desafio interativo.

Um aumento de 155 vezes num semestre

Segundo a empresa, “nos últimos seis meses, a Huntress observou o volume de ataques de pulverização de credenciais aumentar mais de 155 vezes” na sua base de clientes. O pico verificou-se sobretudo entre o final de maio e o início de junho, com um valor médio atual de cerca de 1964 tentativas falhadas por mês e por tenant protegido. É um número relevante para as equipas de deteção: com este volume de base, organizações que dependem de contagens de falhas de autenticação não veem sprays deste tipo nos seus painéis, porque a taxa de falhas por conta é demasiado baixa para acionar os limiares habituais.

A lógica do ataque é diferente da força bruta clássica. Em vez de testar muitas palavras-passe contra uma só conta, a pulverização testa um conjunto limitado de palavras-passe prováveis ou previamente expostas contra muitas contas, para evitar os limiares simples de bloqueio. A atividade parece explorar especificamente combinações antigas de utilizador e palavra-passe já comprometidas em fugas de dados e que nunca foram rodadas. A seleção de vítimas não é setorial: a Huntress afirma que o alvo depende inteiramente da prevalência das palavras-passe em listas de combinações comprometidas, e não do tipo de negócio ou da indústria.

O papel do fluxo ROPC e do Azure CLI

O vetor central é o Resource Owner Password Credentials (ROPC), um dos fluxos originais do OAuth 2.0. Os atacantes reenviam combinações antigas de utilizador e palavra-passe obtidas em fugas de dados contra o fluxo ROPC, que envia as credenciais diretamente para o endpoint /token sem MFA interativo. Este fluxo pode emitir um novo token delegado ao utilizador quando é fornecida a combinação correta de utilizador e palavra-passe. Numa autenticação moderna, o utilizador é redirecionado para a página de início de sessão da Microsoft e é aí que o Acesso Condicional insere o desafio de segundo fator; o ROPC salta essa etapa e pede o token num único passo.

A própria Microsoft desaconselha o mecanismo: na documentação do Entra ID indica que o fluxo ROPC é incompatível com o MFA e que, depois de o MFA ser ativado no tenant, as APIs baseadas em ROPC passam a lançar exceções. Na documentação das bibliotecas MSAL, a empresa é explícita: o fluxo ROPC foi descontinuado devido a riscos de segurança e deve ser substituído por um fluxo mais seguro. Há ainda uma consequência prática relevante para quem já avançou para autenticação sem palavra-passe: contas sem palavra-passe não podem iniciar sessão com ROPC, pelo que funcionalidades como FIDO ou a aplicação Authenticator não funcionam nesse fluxo.

Cronologia da campanha

A cadência foi de duas a quatro contas comprometidas por dia entre 12 e 21 de junho, com exceção de 19 de junho, quando 12 identidades foram comprometidas; a 22 de junho o padrão mudou, com 30 identidades em 23 empresas, e no total foram 78 contas em 64 organizações. A Huntress encontrou endereços IPv6 recentes no intervalo atacante, incluindo um registo de maintainer criado a 11 de junho de 2026 — um dia antes do início da campanha —, o que sugere infraestrutura provisionada especificamente para a operação; a empresa reportou a atividade pelo contacto de abuso da LSHIY, sem resposta.

Indicadores e infraestrutura: um jogo de “whack-a-mole”

A atividade tem origem num intervalo IPv6 (2a0a:d683::/32) controlado pela LSHIY LLC (AS32167), sendo que a LSHIY opera dois ASN distintos — o AS32167 e o AS955 — e terceiros reportam que os intervalos IPv6 associados a ambos têm origem na China. Após a intervenção do provedor, a atividade migrou para a FranTech (AS53667), nos intervalos IPv6 2605:6400::/32 e 2605:6404::/32, com 87% das contas pulverizadas a partir da FranTech a terem sido já visadas a partir da LSHIY. A 15 de julho de 2026, a Huntress identificou uma nova ronda de atividade a partir de um segundo provedor, a 3xK Tech GmbH (AS200373), e com essa mudança os atacantes conseguiram voltar aos níveis de volume da campanha original, com cerca de 1,5 milhões de tentativas de autenticação por dia durante vários dias. A facilidade em trocar de provedor transforma o bloqueio de infraestrutura num problema recorrente para os defensores — razão pela qual bloquear intervalos de IP é, no melhor dos casos, uma medida temporária.

Porque é que o MFA não travou os acessos

Este é o ponto mais incómodo do caso. Muitas das organizações comprometidas tinham políticas de Acesso Condicional ativas. Na análise de um subconjunto de vítimas, a Huntress examinou 23 empresas afetadas, das quais oito não tinham MFA implementado; nas restantes 15, o MFA não se aplicava às tentativas de início de sessão do atacante porque as políticas estavam limitadas a certas aplicações ou grupos de utilizadores, dependiam de localizações fidedignas ou permaneciam em modo de relatório. Um terço dessas 15 tinha o MFA delimitado a utilizadores específicos, deixando de fora determinados grupos. Há ainda um detalhe operacional a retirar: em vários casos, inconsistências de geolocalização rotularam os IP atacantes como endereços dos EUA, permitindo-lhes escapar à lógica de “localização fidedigna” ainda que outra telemetria os situasse na China.

A leitura da própria Huntress é de que o problema não está no conceito: isto não significa que o MFA esteja quebrado, significa que as políticas de Acesso Condicional têm de ser delimitadas para serem efetivamente aplicadas. A empresa admite mesmo que houve negócios com uma política explícita destinada a bloquear este vetor específico que ainda assim foram atingidos.

Mitigações concretas

• Exigir MFA para todos os utilizadores, todas as aplicações cloud e todos os tipos de aplicação cliente, sem exclusões.
• Bloquear métodos de autenticação que não conseguem satisfazer um requisito de MFA, incluindo a concessão legada ROPC.
• Usar uma definição forte de Acesso Condicional, como userStrongAuthClientAuthNRequired, para impor autenticação forte ao nível do cliente e bloquear o ROPC.
• Reforçar a higiene de palavras-passe, considerar opções sem palavra-passe, desativar o ROPC (ou as aplicações que dependem dele) e restringir a aplicação Azure CLI a utilizadores não administradores.
• Não priorizar a resposta pelo volume de pulverização — os tenants mais pulverizados são frequentemente os menos comprometidos —, mas sim pela validade das credenciais.
• Caçar sinais nos registos de identidade: rajadas de falhas de autenticação, inícios de sessão invulgares via Azure CLI, tentativas repetidas em muitas contas, sucessos após atividade de spray e autenticações a partir de ASN suspeitos.

Porque é que isto importa em Portugal

Para as organizações nacionais, o tema deixou de ser apenas boa prática técnica. O Decreto-Lei n.º 125/2025, publicado a 4 de dezembro de 2025, aprovou o novo Regime Jurídico da Cibersegurança, transpondo a Diretiva (UE) 2022/2555, e entrou em vigor a 3 de abril de 2026. Esse diploma sobre o Regime Jurídico da Cibersegurança e a NIS2 define nove áreas de medidas obrigatórias no artigo 27.º, que incluem tratamento de incidentes, continuidade de negócio, segurança da cadeia de abastecimento, gestão de vulnerabilidades, formação periódica e autenticação multifator. Ou seja, ter MFA “ativado” mas com exclusões que deixam passar autenticação legada pode ser exatamente o tipo de lacuna que uma auditoria de conformidade vem expor — sobretudo porque os administradores, diretores e gestores podem responder individualmente por ação ou omissão, com dolo ou culpa grave, nos termos do n.º 2 do artigo 25.º. A concretização prática já existe: foi publicado o Regulamento n.º 756/2026, que concretiza a aplicação do RJCS aprovado pelo Decreto-Lei n.º 125/2025, sendo o CNCS a autoridade nacional de cibersegurança e a entidade que integra a equipa nacional de resposta a incidentes.

Há também um ângulo de proteção de dados. Uma conta Microsoft 365 comprometida dá tipicamente acesso a correio eletrónico, ficheiros e diretórios com dados pessoais de clientes, colaboradores e parceiros, o que pode configurar uma violação de dados pessoais com obrigações de notificação à CNPD nos termos do RGPD. Para as PME portuguesas, que raramente têm equipas dedicadas a identidade, a mensagem operacional é simples: validar se as políticas de Acesso Condicional cobrem realmente todos os utilizadores e todos os tipos de cliente, confirmar que nenhuma política crítica ficou em modo de relatório e rodar palavras-passe que apareçam em fugas de dados conhecidas. Vale ainda recordar que estes ataques não exigem sofisticação — vivem de credenciais antigas nunca alteradas e de exceções de configuração esquecidas há anos.

Perguntas frequentes

O que é um ataque de password spraying?

É um ataque a credenciais que testa um conjunto limitado de palavras-passe prováveis ou previamente expostas contra muitas contas diferentes, em vez de muitas palavras-passe contra uma só conta, precisamente para não acionar os bloqueios automáticos por tentativas falhadas.

Ter MFA ativado deixou de proteger?

Não. O problema identificado foi de âmbito de aplicação: nas organizações afetadas que tinham MFA, este não se aplicava às tentativas do atacante porque as políticas estavam limitadas a certas aplicações ou grupos, dependiam de localizações fidedignas ou estavam em modo de relatório.

O que é o fluxo ROPC e porque deve ser bloqueado?

É um fluxo OAuth em que o cliente envia utilizador e palavra-passe diretamente para o endpoint de token do Entra ID e pede um token num único passo. A Microsoft indica que o fluxo ROPC é incompatível com o MFA e que foi descontinuado por riscos de segurança.

Como detetar esta atividade se o volume de falhas é elevado?

A recomendação é mudar o critério de triagem: não priorizar pelo volume de pulverização, porque os tenants mais atacados são muitas vezes os menos comprometidos, mas sim pela validade das credenciais, cruzando com inícios de sessão bem-sucedidos via Azure CLI e ASN pouco habituais.

Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela Huntress, pela documentação oficial da Microsoft sobre o Microsoft Entra ID e por fontes legais nacionais relativas ao Decreto-Lei n.º 125/2025 e ao CNCS.