Voltar à sala de imprensa
Ameaças

Campanha de token replay no Microsoft 365 compromete 97 contas em 79 organizações

Os atacantes encaminharam as vítimas para páginas falsas de login da Microsoft, guardaram os tokens de sessão e reutilizaram-nos a partir dos seus próprios servidores. A campanha contornou o MFA, registou 48 dispositivos falsos e escondeu regras de correio para fraude salarial. O que aconteceu e como reforçar o seu tenant.

Campanha de token replay no Microsoft 365 compromete 97 contas em 79 organizações

Campanha de token replay no Microsoft 365 compromete 97 contas em 79 organizações

Uma campanha de vários meses contra tenants do Microsoft 365 recorda que a palavra-passe, e até o código MFA de utilização única, deixam de importar assim que o atacante possui um token de início de sessão válido. Entre 14 de julho e 22 de setembro de 2026, os atacantes encaminharam as vítimas para páginas de login que imitavam a Microsoft, capturaram os tokens emitidos após cada autenticação bem-sucedida e reutilizaram-nos a partir das suas próprias máquinas. O balanço: 97 contas comprometidas em 79 organizações, 48 dispositivos falsos registados nos diretórios das vítimas e regras de caixa de entrada concebidas para esconder fraudes salariais.

Como funciona o ataque

O ponto de entrada é uma página de autenticação do tipo adversary-in-the-middle (AitM). A vítima chega a uma página igual ao formulário de login da Microsoft, mas que na realidade se coloca entre ela e o serviço verdadeiro. Tudo o que a vítima escreve, incluindo o nome de utilizador, a palavra-passe e o código MFA, é reencaminhado para a Microsoft em tempo real, pelo que o login é bem-sucedido e nada parece errado.

Os atacantes não querem a palavra-passe. Querem o token de acesso que a Microsoft emite depois de concluídos o início de sessão e a verificação MFA. Essa "prova de login" é reutilizada em poucos minutos a partir de dispositivos controlados pelos atacantes, para lançar tentativas automáticas de acesso aos serviços Microsoft 365 sem voltar a passar pelo MFA.

Como a mesma técnica foi aplicada em simultâneo a muitos tokens roubados em muitas organizações, o padrão passou a ser designado token spraying, o primo baseado em tokens do password spraying.

Escala e infraestrutura

Durante a janela da campanha, mais de 200.000 tentativas de início de sessão foram rastreadas até um único bloco de rede, 193.26.115[.]0/24. Destas, 497 foram bem-sucedidas. A primeira atividade partiu de um endereço geolocalizado na Roménia dentro desse bloco, também associado a tráfego do trojan de acesso remoto AsyncRAT.

O bloco pertence a um fornecedor de alojamento alemão que aluga servidores virtuais, e vários outros endereços do mesmo intervalo já têm reputação maliciosa ou suspeita. Marcas ligadas a esse fornecedor foram apanhadas numa operação policial internacional em janeiro de 2025 e entretanto ressurgiram com novos nomes. O operador negou publicamente qualquer envolvimento em atividades criminosas, pelo que a ligação à infraestrutura deve ser lida como contexto e não como atribuição.

Os tokens roubados também não vinham de um único sítio. A campanha recorreu a relés AitM escondidos atrás de páginas de login falsas, a phishing por device code e a engenharia social aplicada enquanto a vítima fazia um início de sessão legítimo.

Persistência: novos métodos MFA e dispositivos falsos

Uma vez lá dentro, os atacantes agiram depressa para garantir que uma sessão revogada não os voltaria a deixar de fora.

  • A sua própria aplicação de autenticação. Registaram um novo método MFA para poderem responder eles próprios aos desafios futuros. Em pelo menos 19 organizações, os métodos MFA existentes da vítima foram removidos e substituídos em menos de três horas após o primeiro login malicioso. Num caso de 21 de julho de 2026, uma aplicação de autenticação chamada "iPhone 13" estava ativa menos de 51 minutos depois do sequestro da sessão.
  • Dispositivos falsos. Pelo menos 48 computadores fictícios foram registados nos diretórios Entra ID das organizações afetadas. Um dispositivo registado é uma forma muito mais duradoura de pedir tokens novos do que uma sessão roubada, e permanece no diretório até que um administrador repare nele e o elimine.

Regras de caixa de entrada feitas para a fraude salarial

A atividade nas caixas de correio aponta diretamente para business email compromise. Foram criadas regras ocultas com nomes descartáveis como ".", "s", "d", "iT", "sss" ou uma sequência de pontos para apagar mensagens recebidas que mencionassem salários, depósitos ou bónus, ou para as mover para pastas raramente abertas, como Feeds RSS ou Histórico de Conversações. É a preparação clássica para desviar pagamentos de salários ou tomar conta de uma conversa sobre uma fatura.

Numa caixa comprometida, uma regra marcava todas as mensagens recebidas como lidas e apagava-as. A conta foi depois usada para enviar spam a centenas de destinatários externos antes de o Entra ID Protection a classificar como de alto risco.

Porque é que isto importa

O MFA estava ativo nestas organizações, e foi ultrapassado. O ataque decorre inteiramente depois da autenticação, o que significa que os sinais de que precisa são diferentes daqueles que a maioria das equipas monitoriza:

  • um login bem-sucedido a partir de um IP ou dispositivo novo, segundos ou minutos depois de um legítimo;
  • um novo método MFA ou uma nova aplicação de autenticação numa conta;
  • registos de dispositivos inesperados no Entra ID;
  • regras de caixa de entrada com nomes sem sentido, ou regras que apagam ou movem correio;
  • novos consentimentos de aplicações empresariais.

Bloquear intervalos de IP ajuda durante um dia. Os servidores virtuais alugados são baratos e os operadores vão rodando.

O que fazer

Se suspeita de um comprometimento por token replay no seu tenant:

  1. Revogue todas as sessões ativas da conta e, em seguida, redefina a palavra-passe.
  2. Audite os dispositivos registados no Entra ID e remova tudo o que não consiga justificar.
  3. Reveja os métodos MFA da conta e apague os que o utilizador não adicionou.
  4. Verifique as regras de caixa de entrada, os reencaminhamentos e as aplicações empresariais autorizadas recentemente.
  5. Restrinja ou bloqueie o fluxo de autenticação por device code através do Conditional Access.

Para um reforço a longo prazo, as políticas de Conditional Access devem exigir MFA, ou bloquear o acesso por completo, para todos os utilizadores, todas as aplicações na nuvem e todos os tipos de aplicação cliente, sem exceções por conveniência. Complemente com autenticação resistente a phishing, como passkeys ou chaves FIDO2, sempre que possível, crie alertas para alterações de métodos MFA e novos registos de dispositivos, e adicione 193.26.115[.]0/24 às suas listas de vigilância.

A configuração de identidade é uma das áreas que os nossos serviços de penetration testing analisam com mais atenção em ambientes Microsoft 365. Verificamos se as políticas de Conditional Access, as restrições de device code e as regras de registo MFA travam de facto um token reutilizado, para que encontre a falha antes de um atacante.

PARTILHAR