Entre 12 e 26 de junho, um atacante automatizado fez mais de 81 milhões de tentativas de login contra contas do Microsoft 365 monitoradas pela empresa de segurança Huntress. O tráfego veio de um bloco de endereços IPv6 registrado em nome de um provedor de infraestrutura chamado LSHIY LLC, e o alvo não era a página de login web do Microsoft 365, mas sim a interface de linha de comando do Azure. Quando a campanha foi documentada, ela já havia comprometido pelo menos 78 contas em 64 organizações, com comprometimentos diários que passaram de duas ou três por dia para 30 contas em um único dia, em 22 de junho.
O que torna essa campanha digna de atenção não é o volume. Credential stuffing em grande escala não é novidade. É o mecanismo que permitiu que tantas dessas 78 contas caíssem apesar de terem a autenticação multifator ativada.
O Fluxo que o Acesso Condicional Esqueceu
Os atacantes se autenticaram usando um mecanismo OAuth legado chamado Resource Owner Password Credentials, ou ROPC. O ROPC permite que um aplicativo troque um nome de usuário e senha diretamente por um token de acesso no endpoint /token da Microsoft, sem que o usuário passe por uma página de login interativa. Esse desenho é anterior à autenticação moderna e nunca foi construído para suportar prompts de MFA, chaves de segurança ou redirecionamentos de login único. Se um par válido de nome de usuário e senha chega a esse endpoint, o ROPC devolve um token. Não há nenhum prompt para interceptar, porque não há nenhuma sessão interativa a ser solicitada.
A Huntress descobriu que muitas das organizações comprometidas já tinham políticas de Acesso Condicional exigindo MFA. Essas políticas simplesmente não foram escritas para cobrir esse fluxo de autenticação. Uma política de Acesso Condicional que exige MFA para logins via navegador, mas que não bloqueia nem restringe explicitamente protocolos legados, deixa o ROPC como uma porta lateral aberta, e atacantes que já sabem disso entram direto por ela. A própria orientação da Microsoft recomenda desabilitar a autenticação legada e, para qualquer política que pretenda ser abrangente, aplicá-la a todos os usuários, todos os aplicativos em nuvem e todos os tipos de aplicativo cliente, em vez de restringir seu escopo.
As senhas vieram de listas combinadas vazadas em violações anteriores. A Huntress observou que a seleção de alvos não foi por setor ou tamanho de empresa, mas pela prevalência da senha. Se um par de credenciais de uma violação antiga ainda funcionasse, a infraestrutura da LSHIY eventualmente o testava.
Por Que Isso Importa Mais que uma História Típica de Credential Stuffing
Uma conta do Microsoft 365 comprometida não é apenas uma caixa de entrada que um atacante pode ler. É uma identidade de envio totalmente autenticada. O e-mail enviado a partir dessa conta passa no SPF porque se origina na própria infraestrutura da Microsoft. Passa no DKIM porque a Microsoft o assina com a chave real do tenant. Passa no DMARC porque as duas verificações passam e se alinham com o endereço De visível. Nenhum dos três protocolos nos quais a maioria dos donos de domínio confia para impedir a falsificação foi projetado para perguntar se a pessoa digitando no teclado está realmente autorizada a estar ali. Eles foram projetados para confirmar que a mensagem veio de onde afirma vir, e depois de uma concessão de token ROPC bem-sucedida, ela genuinamente veio.
Essa é a brecha que essa campanha explora em escala. Uma vez que uma conta é comprometida por password spray, tudo o que vem depois, mensagens de BEC para equipes financeiras, fraude de faturas enviada a fornecedores reais, phishing interno usando a assinatura real de um colega, chega com um resultado de autenticação limpo. Cada valor em dólares de cada relatório de fraude que remonta a uma caixa de entrada sequestrada, incluindo os bilhões que o relatório IC3 do FBI atribuiu ao BEC no ano passado, começa com um evento de autenticação exatamente como este tendo sucesso.
Fechando a Porta Real
A solução para essa campanha específica não é uma mudança no DMARC. É auditar as configurações de Acesso Condicional para confirmar que o ROPC e outros fluxos de autenticação legados estejam bloqueados por completo, não apenas relegados atrás de um prompt de MFA que o ROPC nunca precisa responder. A configuração userStrongAuthClientAuthNRequired da Microsoft aplica autenticação forte no nível do cliente de uma forma que impede o ROPC antes que um token seja emitido. Trocar senhas que aparecem em dados de violações, antes que um atacante chegue primeiro, fecha a outra metade da brecha.
Nada disso substitui o DMARC. Ele o complementa. A aplicação do DMARC impede que alguém envie e-mail que apenas afirma vir do seu domínio sem nunca ter tocado sua infraestrutura. Ele não consegue ver, e nunca foi pensado para ver, uma mensagem enviada por alguém que está tecnicamente dentro do seu tenant porque uma senha de uma violação de 2019 ainda funcionava e uma política de Acesso Condicional tinha uma brecha que ninguém havia testado. O monitoramento contínuo dos seus relatórios agregados e forenses de DMARC é um dos poucos lugares onde o comportamento de envio incomum de uma conta que é legitimamente sua começa a ficar visível, mesmo que o protocolo em si não consiga bloqueá-lo.
A Conclusão
81 milhões de tentativas de login é um número grande o suficiente para soar abstrato. 78 comprometimentos bem-sucedidos, cada um uma identidade do Microsoft 365 totalmente autenticada e agora disponível para enviar e-mails que passarão em todas as verificações executadas pelos filtros dos seus destinatários, não é abstrato de forma alguma. Se a sua organização ainda não testou se suas políticas de Acesso Condicional realmente bloqueiam o ROPC e outros fluxos legados, essa campanha é o motivo para verificar isso ainda esta semana, não na próxima vez que sobrar tempo.
Os protocolos de autenticação só conseguem verificar aquilo para o qual foram projetados. Quando uma conta é comprometida, não falsificada, a visibilidade sobre o seu e-mail enviado é o que detecta isso. Cadastre-se gratuitamente na Excello Mail e monitore os relatórios DMARC do seu domínio continuamente, para que uma conta comprometida não passe livre só porque a senha era real.