Cibersegurança

Ataques com reprodução de tokens no Microsoft 365 comprometem 97 contas em 79 organizações

Pesquisadores de segurança revelaram uma campanha contra o Microsoft 365 que usa um relé de adversário no meio para capturar sessões de login e reutilizar os tokens roubados, invadindo contas de e-mail em 79 organizações.


Ravie Lakshmanan Segunda - 26 de Outubro de 2026 às 16:44
The Hacker News

Pesquisadores de segurança revelaram uma campanha contra o Microsoft 365 que vem sendo observada com o uso de um relé de adversário no meio (AitM, de adversary-in-the-middle) para capturar sessões de login e, em seguida, reproduzir os tokens roubados para invadir contas de e-mail em 79 organizações.

A Huntress, que observou a atividade entre 14 de julho e 22 de setembro de 2026, afirmou ter detectado 497 eventos de login bem-sucedidos no Microsoft 365 nas organizações vítimas, a partir de mais de 200 mil tentativas de login. No fim, os atacantes comprometeram 97 contas e registraram 48 dispositivos Entra não autorizados.

“Em vez de adivinhar senhas, o atacante reproduziu tokens de login roubados das vítimas, e rastreamos mais de 200 mil tentativas de login malsucedidas da campanha até o intervalo de IP (sigla de Internet Protocol) 193.26.115[.]0/24”, disseram os pesquisadores da Huntress Andrea Hatcher, Susannah Matt, Matt Poto e Andrew Schwartz.

O ataque utiliza uma página de login AitM que fica entre as vítimas e a infraestrutura legítima da Microsoft, capturando as credenciais digitadas e os códigos de autenticação multifator (MFA, de multi-factor authentication) e repassando essas informações à página de login verdadeira.

O objetivo final é coletar o token de acesso emitido pela Microsoft após o processo de login, para que o invasor não precise contornar a MFA uma segunda vez. O “token de prova de login” é então reproduzido pelo atacante a partir de seus próprios dispositivos, em questão de minutos, para realizar tentativas automatizadas de login nos serviços do Microsoft 365.

A abordagem recebeu o nome de token spraying, pois envolve a reprodução de muitos tokens roubados, em grande escala e em várias organizações, de forma análoga à password spraying, técnica que testa um mesmo conjunto de senhas em muitas contas.

Após obter acesso bem-sucedido, os atacantes trataram de adicionar seu próprio aplicativo autenticador como forma de persistência, para concluir desafios de MFA em novos logins e contornar situações em que o token de sessão roubado expira ou é revogado pela vítima.

Em pelo menos 19 organizações, os métodos de MFA existentes das vítimas foram removidos, e um novo método foi registrado em até três horas após o primeiro login. Em um caso observado em 21 de julho de 2026, os agentes de ameaça ativaram um novo aplicativo autenticador chamado “iPhone 13” menos de 51 minutos após a sessão ser sequestrada.

“Dispositivos falsos cumpriram a mesma finalidade”, disseram os pesquisadores. “O agente de ameaça registrou pelo menos 48 computadores falsos nos diretórios da Microsoft das organizações vítimas. Um dispositivo registrado pode dar ao atacante uma forma mais durável de solicitar tokens do que apenas a sessão roubada, e ele permanece no diretório até que alguém o exclua.”

Além disso, foi flagrado que os atacantes configuram regras de e-mail ocultas nas caixas de entrada das vítimas, com nomes como “.,”, “sss,”, “ss,”, “iT,”, “,.,”, “........,”, “s,” e “d”, para excluir mensagens recebidas que contenham palavras-chave como folha de pagamento, depósito e bônus, ou para movê-las a pastas discretas, como RSS Feeds e Conversation History.

Em uma caixa de correio comprometida, a regra de e-mail marcou todas as mensagens recebidas como lidas e as excluiu. A caixa foi então usada para enviar spam a centenas de destinatários externos, até que o Microsoft Entra ID Protection classificasse a conta como de alto risco.

A Huntress afirmou que os tokens têm múltiplas origens, incluindo relés AitM por trás de páginas de login falsas, phishing por código de dispositivo e engenharia social durante um processo de login legítimo.

A campanha foi observada pela primeira vez a partir de um endereço IP romeno, “193.26.115[.]221”, que, segundo o VirusTotal, é usado por um trojan de acesso remoto (RAT, de remote access trojan) chamado AsyncRAT. O endereço está associado a um provedor de hospedagem alemão chamado 1337 Services GmbH.

Dados do GreyNoise listam atualmente 29 endereços IP correspondentes ao provedor de hospedagem, dos quais 10 foram marcados como maliciosos e cinco como suspeitos. Vale notar que a entidade está ligada ao StarkRDP e ao rdp[.]sh, que permite que clientes pagantes aluguem servidores virtuais.

Os domínios ligados ao StarkRDP e ao rdp[.]sh foram derrubados, junto com os sites do Nulled, Cracked e Sellix, como parte de uma operação internacional de aplicação da lei batizada de Talent, em janeiro de 2025. Até a publicação deste texto, as duas plataformas seguem em funcionamento, sendo que a primeira foi rebatizada como exy[.]sh.

“O StarkRDP sempre operou dentro da lei e não está envolvido em nenhum desses supostos crimes, e o processo legal confirmará isso”, disse a conta do StarkRDP no Telegram em uma publicação datada de 30 de janeiro, segundo o jornalista independente de cibersegurança Brian Krebs.

“As únicas coisas apreendidas foram o servidor do site e nosso domínio. Infelizmente, ninguém consegue dizer quem o levou nem com quem podemos conversar sobre isso. Por isso, vamos retomar as operações em breve, sob outro nome, para encerrar o capítulo [de] ‘StarkRDP’.”

Organizações que suspeitam de comprometimento por reprodução de token são aconselhadas a revogar sessões e redefinir a senha, auditar dispositivos do Entra, revisar os métodos de MFA, verificar regras de caixa de entrada inesperadas ou novos aplicativos corporativos e restringir o fluxo de código de dispositivo com políticas de Acesso Condicional.

“As políticas de Acesso Condicional (CAP, de Conditional Access Policies) podem ajudar a preencher algumas lacunas de segurança que a MFA não consegue cobrir, desde que sejam implementadas adequadamente”, afirmaram os pesquisadores da Huntress. “Empresas que configurarem CAPs devem exigir MFA (ou bloquear o acesso) para todos os usuários, todos os aplicativos de nuvem e todos os tipos de aplicativo cliente, sem exceções.”

Microsoft 365 Cibersegurança Ataques com tokens