Ter a autenticação multifator (MFA) ativada já não basta para garantir que uma conta está protegida. As campanhas mais recentes contra ambientes Microsoft 365 e Entra ID mostram que os atacantes não estão a quebrar o segundo fator. Procuram os fluxos de autenticação, as exceções e as configurações em que esse fator nunca chega a ser pedido. O caso mais evidente deste ano é uma campanha de password spraying documentada pela Huntress. Segundo a empresa, foram feitas mais de 81 milhões de tentativas de início de sessão em duas semanas, e muitas organizações comprometidas tinham MFA configurado.
Resposta rápida: Os atacantes aproveitam falhas na forma como o MFA é aplicado, como fluxos antigos (ROPC), políticas limitadas a certos grupos ou aplicações, exceções por “localização de confiança” e o fluxo de código de dispositivo. Numa campanha contra o Azure CLI, a Huntress registou 78 contas comprometidas em 64 organizações. O que se recomenda é exigir MFA para todos os utilizadores, aplicações e tipos de cliente, bloquear ROPC e device code flow onde não sejam necessários, mudar palavras-passe reutilizadas e avançar para MFA resistente a phishing (FIDO2/passkeys).
O caso que expôs o problema: 81 milhões de tentativas sem um único pedido de MFA
A investigação mais detalhada sobre o tema foi publicada pela Huntress. A empresa descreve um ataque de password spraying contra o Microsoft Azure CLI, com origem num intervalo de endereços IPv6 controlado pela LSHIY LLC. Entre 12 e 21 de junho, a empresa observou mais de 81 milhões de tentativas de login contra os seus clientes, com 78 contas de utilizador comprometidas em 64 organizações. Nesse período de duas semanas, os atacantes comprometeram entre duas e quatro contas por dia, com um pico por volta de 22 de junho, quando 23 empresas foram afetadas.
Não houve nenhuma vulnerabilidade de software envolvida. Segundo a Huntress, os ataques parecem assentar inteiramente em listas de combinações de palavras-passe comprometidas, ou seja, credenciais de fugas de dados anteriores que nunca foram alteradas. A campanha integra uma tendência mais ampla: nos últimos seis meses, a Huntress observou um aumento de mais de 155 vezes no volume de ataques de credential spray na sua base de clientes.
Porque é que o MFA não travou o ataque
A campanha usou o Resource Owner Password Credentials (ROPC), um mecanismo antigo do OAuth. Os atacantes recorreram a este fluxo para validar credenciais. Foi descontinuado no OAuth 2.1 e emite um novo token delegado do utilizador quando recebe as credenciais certas. A Huntress explica que o ROPC não suporta fluxos de autenticação modernos como MFA ou SSO, pelo que envia a palavra-passe diretamente para o endpoint /token, sem qualquer pedido interativo de MFA.
O ROPC sozinho não explica o sucesso do ataque. A falha esteve na forma como as políticas de Acesso Condicional estavam construídas. A Huntress encontrou vários padrões nas organizações afetadas: em alguns casos, o MFA não era aplicado a todas as aplicações na cloud; noutros, era aplicado só a certos grupos de utilizadores, exigido apenas fora de localizações de confiança, ou estava implementado mas não era efetivamente imposto. Além disso, oito das empresas afetadas não tinham qualquer política de MFA.
Em muitos casos, o utilizador comprometido não estava abrangido por nenhuma das regras. Se o MFA só é exigido a administradores, só para certas aplicações ou só fora da rede da empresa, um utilizador comum que entra pelo Azure CLI a partir de um local considerado “de confiança” não ativa nenhuma política. Basta-lhe a palavra-passe correta.
Cronologia e indicadores da campanha
| Data (2026) | Acontecimento |
|---|---|
| Final de maio / início de junho | A Huntress deteta um aumento de password spraying em várias empresas |
| 12 de junho | Início da vaga automatizada contra o Azure CLI |
| 22 de junho | Pico: 23 empresas comprometidas |
| 26 de junho | Fim da janela analisada: 78 contas em 64 organizações |
| 30 de junho | Publicação do relatório da Huntress |
| 22 de julho | A Huntress publica o resumo e as recomendações de mitigação |
| Tipo | Indicador |
|---|---|
| Sistema autónomo | AS32167 (LSHIY LLC) |
| Intervalo IPv6 | 2a0a:d683::/32 |
| Aplicação visada | Microsoft Azure CLI |
| Fluxo abusado | ROPC (OAuth), pedidos diretos ao endpoint /token |
Os indicadores de infraestrutura têm valor limitado. A própria Huntress referiu que, numa fase posterior, os ataques estavam a usar IPv4, embora a empresa admitisse que isso pudesse mudar. Bloquear intervalos de IP pode ajudar, mas não substitui a correção das políticas.
As outras portas que os atacantes procuram
O ROPC é só um exemplo. Há outros caminhos em que o MFA existe mas não protege:
- Fluxo de código de dispositivo (device code flow): a Microsoft considera-o de alto risco, porque um atacante pode iniciar o fluxo, enviar um código ao utilizador e pedir-lhe que o introduza numa página de login legítima da Microsoft, o que torna o ataque mais difícil de reconhecer.
- Fadiga de MFA (push bombing): o atacante, já com a palavra-passe, envia notificações repetidas até a vítima aprovar uma.
- SMS e códigos partilháveis: a agência norte-americana CISA avisa que nem todas as formas de MFA são igualmente seguras, havendo algumas vulneráveis a phishing, push bombing, falhas do protocolo SS7 ou troca de cartão SIM.
- Recuperação de contas e helpdesk: processos de reposição de credenciais que podem ser explorados com engenharia social, fora do fluxo normal de login.
Sobre o código de dispositivo, a Microsoft diz na sua documentação que este fluxo raramente é usado pelos clientes, mas é usado com frequência pelos atacantes. Recomenda que as organizações se aproximem o mais possível de um bloqueio total do device code flow.
O que fazer: passos concretos de mitigação
As recomendações da Huntress incluem desativar o ROPC (ou as aplicações que dependem dele) e restringir a aplicação Azure CLI a utilizadores que não sejam administradores. A medida mais importante é exigir MFA (ou bloquear) para todos os utilizadores, todas as aplicações na cloud e todos os tipos de aplicação cliente, sem condições. Na prática, para administradores de Microsoft 365 e Entra ID:
- Rever as políticas de Acesso Condicional para identificar exclusões de grupos, aplicações e localizações de confiança, e políticas esquecidas em modo
Report-only. - Bloquear a autenticação legada e o fluxo de código de dispositivo com a condição
Authentication flows, depois de inventariar o uso real nos registos de início de sessão. - Procurar nos sign-in logs autenticações de fator único bem-sucedidas através do Azure CLI, sobretudo de contas que não sejam de administração.
- Forçar a mudança de palavras-passe reutilizadas ou expostas em fugas de dados.
- Usar number matching enquanto ainda houver notificações push, e migrar contas privilegiadas para FIDO2/WebAuthn ou passkeys.
No longo prazo, a referência continua a ser a ficha técnica da CISA sobre MFA resistente a phishing. A agência diz que qualquer MFA é melhor do que nenhum, mas o MFA resistente a phishing é o padrão de referência, e a migração deve ser prioritária. Para quem ainda não consegue dar esse passo, a CISA sugere considerar o MFA com correspondência de números para travar o bombardeamento de notificações e ataques baseados em SMS. A Microsoft também disponibiliza orientações para bloquear fluxos de autenticação com Acesso Condicional.
Porque é que isto importa em Portugal
Muitas PME portuguesas e entidades públicas usam Microsoft 365 e tratam o MFA como uma caixa que já está assinalada. Estes casos mostram que é preciso verificar a cobertura real das políticas, e não só se o MFA foi ativado. No Regime Jurídico da Cibersegurança (Decreto-Lei n.º 125/2025, que transpõe a diretiva NIS2), a autenticação multifator está entre as medidas de gestão de riscos esperadas das entidades abrangidas. Uma política com exceções mal pensadas pode ser difícil de justificar perante o regulador depois de um incidente.
Uma conta de correio comprometida dá muitas vezes acesso a dados pessoais de clientes e trabalhadores. Nesse caso, uma violação de dados pode ter de ser notificada à CNPD ao abrigo do RGPD. Os incidentes também podem ser comunicados ao CNCS/CERT.PT, que acompanha as ameaças a nível nacional. Para os cidadãos, a regra mantém-se: não reutilizar palavras-passe e preferir chaves de acesso (passkeys) ou aplicações de autenticação ao SMS sempre que o serviço o permita.
Perguntas frequentes
Se tenho MFA ativado, a minha conta pode mesmo ser comprometida?
Pode. Se as políticas não cobrirem todos os utilizadores, aplicações e fluxos de autenticação, um atacante com a palavra-passe certa pode entrar sem que o segundo fator seja pedido. Foi o que aconteceu na campanha contra o Azure CLI analisada pela Huntress.
O que é o ROPC e porque é perigoso?
O ROPC (Resource Owner Password Credentials) é um fluxo antigo do OAuth que troca diretamente o nome de utilizador e a palavra-passe por um token, sem pedido interativo de MFA. Foi descontinuado no OAuth 2.1 e deve ser bloqueado sempre que não seja indispensável.
Que tipo de MFA é mais seguro?
O MFA resistente a phishing, baseado em FIDO2/WebAuthn (chaves de segurança e passkeys) ou em PKI, é considerado pela CISA o padrão de referência. SMS, códigos e notificações push continuam a ser úteis, mas podem ser intercetados ou manipulados.
Que verificações deve uma PME fazer já?
Rever as exclusões nas políticas de Acesso Condicional, bloquear a autenticação legada e o fluxo de código de dispositivo, procurar inícios de sessão de fator único bem-sucedidos nos registos e forçar a mudança de palavras-passe reutilizadas ou expostas.
Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela Huntress (ver também o resumo de mitigação), pela CISA e pela Microsoft.