Campanha de reutilização de tokens sequestra contas Microsoft 365 em 79 organizações

Entre meados de julho e o final de setembro de 2026, uma campanha coordenada assumiu o controlo de contas Microsoft 365 em 79 organizações sem quebrar uma única palavra-passe. Os atacantes roubaram tokens de sessão já autenticados, reutilizaram-nos a partir da sua própria infraestrutura e usaram esse acesso para excluir as vítimas da sua própria autenticação multifator (MFA).

O que aconteceu

A operação durou cerca de dez semanas, de 14 de julho a 22 de setembro de 2026. Nos ambientes onde foi observada, gerou mais de 200.000 tentativas falhadas de início de sessão, 497 inícios de sessão bem-sucedidos e 97 contas comprometidas. Os atacantes registaram pelo menos 48 dispositivos não autorizados no Microsoft Entra ID para manter o acesso após a intrusão inicial.

Três técnicas de entrada alimentaram a campanha:

• Phishing adversary-in-the-middle (AiTM). Uma página de início de sessão clonada colocava-se entre a vítima e a Microsoft, reencaminhando em tempo real o utilizador, a palavra-passe e o desafio MFA, e capturando a sessão autenticada devolvida.
• Phishing por código de dispositivo. Na vaga de agosto, as vítimas foram convencidas a aprovar um código de dispositivo gerado pelo atacante na página legítima da Microsoft, entregando uma sessão sem qualquer página falsa.
• Engenharia social para levar os alvos a interagir com qualquer um dos engodos.

Depois de capturado, o token era reutilizado a partir de servidores alugados na Alemanha. Dois conjuntos de ferramentas distintos tratavam da reutilização: um fazia trocas de tokens automatizadas através das aplicações cliente Microsoft Office e Authentication Broker para chegar ao Microsoft Graph, Exchange Online e SharePoint; o outro reproduzia sessões completas de browser através do cliente OfficeHome. Os relays de phishing e os hosts de reutilização estavam em infraestruturas separadas, pelo que bloquear um não travava o outro.

A velocidade foi um traço marcante. Num incidente de julho passaram doze minutos entre o início de sessão da vítima e a tomada de controlo. Na última tomada de controlo, em setembro, foram apenas quatro.

Como os atacantes se entrincheiraram

Em 19 das organizações afetadas, os intrusos removeram os métodos MFA existentes da vítima e registaram substitutos em menos de três horas após o primeiro início de sessão, muitas vezes identificados como um autenticador de iPhone. Dispositivos Windows não autorizados, com o prefixo DESKTOP- seguido de oito caracteres hexadecimais, deram-lhes uma segunda via de persistência.

Seguiu-se o abuso das caixas de correio. Regras de entrada com nomes descartáveis, como um único ponto ou uma única letra, moviam silenciosamente o correio recebido para pastas como RSS Feeds, RSS Subscriptions e Conversation History. Uma conta sequestrada enviou uma mensagem sobre processamento de salários a um contabilista externo enquanto as regras escondiam as respostas de teor bancário. Outras contas foram usadas para enviar spam a centenas de destinatários.

A atividade não foi associada a uma família de malware conhecida nem a um kit de phishing específico, e não foi atribuída a nenhum grupo em particular.

Porque é que importa

O roubo de tokens de sessão transforma a MFA num obstáculo de utilização única em vez de um controlo permanente. Quando o atacante detém a prova de que o desafio já foi concluído, a Microsoft vê uma sessão legítima. Os passos de persistência, novos métodos MFA, dispositivos inscritos e regras de caixa de correio, foram pensados para sobreviver a uma simples reposição de palavra-passe, e é por isso que tantas vítimas continuam comprometidas depois da correção "óbvia".

A nota positiva: as políticas de Conditional Access bloquearam 1.052 tentativas de reutilização em quatro organizações durante uma única vaga. Foi a aplicação de políticas, e não a MFA por si só, que tornou os tokens inúteis.

O que fazer

• Procure os artefactos. Reveja os registos de início de sessão do Entra à procura de acessos a partir de gamas de alojamento desconhecidas, incluindo o bloco 193.26.115[.]0/24, user agents node ou Mozilla/5.0 simples, e os códigos de erro 53003 (bloqueado pelo Conditional Access) e 50133 (artefacto SSO revogado).
• Audite a persistência. Liste os métodos MFA e os dispositivos registados nos últimos noventa dias e remova tudo o que o utilizador não consiga confirmar, sobretudo dispositivos que sigam o padrão DESKTOP- mais oito caracteres hexadecimais.
• Verifique as regras de caixa de correio em todo o tenant à procura de regras com nomes sem sentido ou que movam correio para as pastas RSS ou Conversation History.
• Corrija como deve ser. Revogue todas as sessões e refresh tokens, reponha a palavra-passe, remova dispositivos e métodos MFA não autorizados, apague as regras maliciosas e volte a inscrever a MFA a partir de um dispositivo de confiança.
• Reforce o tenant. Desative ou restrinja ao máximo o fluxo de código de dispositivo, exija dispositivos conformes ou hybrid-joined para as aplicações sensíveis, ative a proteção de tokens onde estiver disponível e reveja as aplicações com consentimento recente.
• Treine contra o engodo. Os utilizadores devem saber que uma página legítima da Microsoft que lhes pede para aprovar um código que não pediram é, por si só, o ataque.

A reutilização de tokens só funciona onde a política o permite. A nossa equipa de penetration testing avalia tenants Microsoft 365 precisamente neste cenário, verificando se o Conditional Access, as definições de código de dispositivo e os controlos de registo MFA travariam uma sessão reutilizada antes de se tornar uma tomada de controlo.