Uma pulverização, não uma descoberta técnica

A empresa de segurança Huntress revelou uma campanha de password spraying que decorreu de 12 a 26 de junho de 2026, com o pico a 22 de junho. Nessas duas semanas, mais de 81 milhões de tentativas de início de sessão foram dirigidas a contas do Microsoft 365. O tráfego saía de um intervalo IPv6 registado em nome de um único operador, e os atacantes não adivinhavam palavras-passe às cegas. Repetiam pares de nome de utilizador e palavra-passe recolhidos em fugas anteriores e sem qualquer ligação entre si, apostando que as pessoas reutilizam as mesmas credenciais de serviço para serviço. Daquela enxurrada saíram 78 contas comprometidas em 64 organizações.

O que salta à vista é a ausência de seja o que for de exótico. Não houve dia zero, nem malware engenhoso, nem truque na cadeia de fornecimento. Houve volume, credenciais reutilizadas e uma via de autenticação fraca. Essa combinação está ao alcance de qualquer atacante comum, e é justamente por isso que merece a atenção de um proprietário. A técnica é barata, repete-se as vezes que forem precisas e aponta à camada de identidade que a maioria das empresas dá por segura graças à autenticação multifator.

Como os inícios de sessão passaram pelo MFA

O mecanismo era uma via de acesso antiga. Os atacantes autenticaram-se através das ferramentas de linha de comandos do Azure com o fluxo Resource Owner Password Credentials, conhecido como ROPC, um método OAuth antigo que aceita diretamente um nome de utilizador e uma palavra-passe e que, em muitos inquilinos, nem sequer aciona um pedido multifator. Onde um inquilino tinha o MFA ligado mas com um âmbito estreito, as credenciais reutilizadas entraram a direito pela brecha. A Huntress encontrou as mesmas más configurações vezes sem conta: MFA aplicado apenas a aplicações selecionadas, MFA imposto apenas aos grupos de administradores, MFA exigido apenas a partir de localizações não fiáveis e políticas de Conditional Access esquecidas no modo apenas relatório, onde registam mas nunca bloqueiam.

A lição menos óbvia é que o MFA não é um interruptor, mas um mapa de cobertura. Um inquilino pode passar numa auditoria que se limita a perguntar se o MFA existe e ainda assim deixar uma porta antiga por trancar. Os atacantes não derrotaram a autenticação multifator. Encontraram os inícios de sessão em que ela nunca era pedida. Toda a história está nessa diferença, e ela permanece invisível enquanto ninguém verificar que vias de autenticação um inquilino ainda permite.

A meia hora que fecha a falha

Um problema de configuração tem uma resposta de configuração, e quase tudo se resolve numa curta sessão administrativa, sem comprar nada. Bloqueie a autenticação antiga e desative o fluxo ROPC, para que os inícios de sessão com nome de utilizador e palavra-passe que saltam o MFA sejam pura e simplesmente recusados. Imponha a autenticação multifator em cada aplicação e em cada início de sessão, não apenas nas contas de administrador ou nas localizações não fiáveis, e passe o Conditional Access do modo apenas relatório para o bloqueio ativo. Depois, verifique os registos de início de sessão à procura do padrão da pulverização falhada e reponha qualquer credencial que uma fuga passada possa ter exposto.

Para uma empresa europeia há uma segunda razão para agir depressa. Se credenciais reutilizadas abrirem uma caixa de correio com dados pessoais, o incidente pode desencadear um dever de notificação ao abrigo do RGPD no prazo de 72 horas, e uma falha de identidade silenciosa passa assim a ser um evento notificável e uma conversa com a autoridade de controlo. Fechar a porta custa uma tarde de configuração. Deixá-la aberta paga-se em obrigações de divulgação e em confiança perdida. Trate a camada de identidade como aquilo em que se tornou, ou seja, o perímetro.

Leia a seguir: Auditoria de IA não viu a falha Linux que dá root  |  Falha Squid de 29 anos expõe logins em texto simples