Sessão roubada exige resposta além da senha e do MFA

A Huntress identificou uma campanha de reutilização de tokens entre 14 de julho e 22 de setembro de 2026, com 97 contas comprometidas em 79 organizações.[3] Sua telemetria reuniu mais de 200 mil tentativas, 497 eventos de login bem-sucedido e 48 dispositivos Entra fraudulentos.[3] Esses números descrevem eventos e entidades diferentes; não são medidas intercambiáveis de vítimas.

Para quem desenvolve sistemas autenticados, a notícia desloca a discussão do formulário de login para o ciclo completo da identidade. A pergunta não termina em exigir segundo fator. Precisa incluir o que acontece depois que uma sessão é emitida e como seu abuso será interrompido.

O que muda para quem desenvolve

No mecanismo descrito, uma página intermediária repassa credenciais e códigos MFA à Microsoft e captura o token emitido após o login legítimo.[3] O invasor reutiliza a sessão em minutos, sem repetir naquele momento o desafio de segundo fator; a pesquisa também cita phishing por código de dispositivo e engenharia social como fontes de tokens.[3]

A persistência não ficou limitada ao token inicial: em pelo menos 19 organizações, métodos MFA foram removidos e substituídos em até três horas.[3] Também foram observados dispositivos fraudulentos e regras de e-mail que apagavam ou moviam mensagens.[3]

Minha análise é que a recuperação deve considerar alterações de estado feitas pelo invasor, não apenas invalidar o acesso que iniciou o incidente. Vale modelar separadamente sessão, dispositivo, método de autenticação, aplicação autorizada e regra de caixa postal.

Como aplicar

Para uma aplicação própria, descreva um procedimento de revogação com critérios observáveis: qual sessão será encerrada, qual credencial será substituída e quais alterações de conta precisam ser revisadas. Não aceite como evidência suficiente uma tela dizendo que a senha foi trocada.

Um exercício controlado pode usar uma conta de laboratório e duas sessões legítimas em navegadores separados. Execute o procedimento de recuperação e observe se ambas perdem acesso, em quanto tempo isso ocorre e que ações permanecem possíveis. Não copie tokens nem use contas reais de terceiros. O experimento serve para revelar o comportamento do ambiente avaliado, não para simular toda a campanha.

Para Microsoft 365, a resposta recomendada na reportagem combina revogação de sessões, redefinição da senha e inspeção de dispositivos, métodos MFA, aplicações empresariais e regras de e-mail.[3]

Cuidados e limites

A associação da campanha a uma faixa de IPs de hospedagem não identifica, por si só, seu operador.[3] Também seria errado concluir que MFA deixou de ter utilidade. O caso demonstra limites de proteger apenas a autenticação inicial.

Acesso Condicional e restrições ao fluxo de código de dispositivo aparecem entre as medidas sugeridas.[3] Sua aplicação deve considerar fluxos legítimos e recuperação de acesso, evitando transformar uma contenção emergencial em bloqueio permanente sem avaliação.

Fonte

[3] Fonte: The Hacker News