A repetição de tokens no Microsoft 365 evidencia uma fragilidade importante na segurança de identidades corporativas: mesmo quando uma organização utiliza autenticação multifator (MFA), criminosos podem assumir o controle de sessões legítimas sem precisar descobrir novamente a senha da vítima. Em campanhas que exploram técnicas de interceptação de autenticação, o alvo deixa de ser apenas a credencial e passa a ser o próprio estado autenticado da sessão.
Uma investigação da empresa de cibersegurança Huntress identificou uma campanha que combina ataques de intermediário, roubo de tokens e tentativas automatizadas de autenticação contra ambientes corporativos. Os dados divulgados apontam para quase 500 logins confirmados, 97 contas comprometidas e mais de 200 mil tentativas de autenticação associadas à infraestrutura utilizada pelos invasores.
O cenário reforça uma mudança na estratégia dos cibercriminosos. Em vez de insistir na adivinhação de senhas ou em campanhas tradicionais de phishing, os atacantes procuram contornar as etapas de autenticação e reutilizar sessões que já passaram pelas verificações de segurança. Para administradores de sistemas, compreender essa técnica é essencial para identificar acessos indevidos, interromper a persistência dos invasores e reduzir o risco de comprometimento de toda a infraestrutura em nuvem.
Como funciona o ataque de repetição de tokens no Microsoft 365
O ataque explora a maneira como os serviços modernos de identidade mantêm usuários autenticados. Depois que uma pessoa informa suas credenciais e conclui a verificação multifator, o provedor de identidade emite tokens que permitem acessar recursos autorizados sem exigir que o usuário repita todo o processo a cada operação.
Esses tokens funcionam como comprovantes temporários de autenticação e autorização. Dependendo do tipo, dos recursos solicitados e das políticas aplicadas, podem permitir acesso ao Outlook, ao SharePoint, ao OneDrive, ao Teams e a outros serviços corporativos.
O problema surge quando um invasor consegue obter um token válido ou um cookie de sessão associado à autenticação. Em determinadas circunstâncias, ele pode reutilizar esse material para assumir a identidade da vítima, aproveitando a confiança que os serviços depositam na sessão já estabelecida.
Isso não significa que o MFA seja inútil. A autenticação multifator continua sendo uma barreira importante contra o roubo de senhas. Entretanto, métodos convencionais, como códigos temporários e aprovações de notificações, não garantem proteção contra todas as técnicas de sequestro de sessão.
Da captura à repetição em massa: o conceito de token spraying
O token spraying é o termo utilizado para descrever, nesse contexto, a reutilização automatizada de tokens capturados em tentativas de autenticação contra contas e recursos corporativos. Diferentemente de um ataque de password spraying, que testa uma senha comum contra várias contas, essa abordagem utiliza material de autenticação previamente obtido.
Uma das técnicas empregadas para conseguir esse material é o Adversary-in-the-Middle (AitM), ou ataque de intermediário. Nesse modelo, o criminoso posiciona uma infraestrutura entre a vítima e o serviço legítimo de autenticação, geralmente por meio de uma página que imita o fluxo de login de uma organização.
A vítima acredita estar acessando o serviço verdadeiro, mas suas interações passam por um intermediário controlado pelo atacante. Se a operação for bem-sucedida, o invasor poderá capturar credenciais e elementos da sessão autenticada, inclusive cookies que permitam reutilizar a autenticação em determinadas condições.
Quando a vítima conclui o MFA, o intermediário pode transmitir a autenticação ao serviço legítimo e capturar os elementos de sessão resultantes. O criminoso tenta, então, reutilizá-los para acessar os recursos disponíveis àquela identidade.
A diferença fundamental é que a sessão já autenticada pode permitir o acesso sem apresentar um novo desafio de MFA. Isso depende das características do token, das restrições aplicadas pelo serviço e das políticas de segurança vigentes.
Por esse motivo, a repetição de tokens no Microsoft 365 representa um risco que não pode ser tratado apenas com a exigência de senhas mais longas ou com a troca periódica de credenciais.
A anatomia dos números: vítimas, logins e taxa de sucesso
Os números atribuídos à campanha investigada pela Huntress ajudam a dimensionar o problema. O levantamento mencionado aponta para quase 500 logins confirmados, 97 contas comprometidas e mais de 200 mil tentativas de autenticação relacionadas à atividade investigada.
Esses indicadores precisam ser interpretados com cuidado. As tentativas representam o volume de operações observadas, não necessariamente 200 mil vítimas distintas. Da mesma forma, logins confirmados e contas comprometidas são métricas diferentes, que não devem ser somadas como se representassem indivíduos únicos.
A infraestrutura observada incluía endereços IP romenos e serviços de hospedagem associados ao ecossistema StarkRDP. A presença desses elementos pode ajudar investigadores a correlacionar atividades, mas um endereço IP ou uma conexão proveniente de determinado serviço não comprova, isoladamente, a identidade do operador de um ataque.
Para equipes de segurança, o principal alerta está na escala e na automatização. Uma única sessão comprometida pode abrir caminho para acessar informações empresariais, interceptar comunicações, manipular mensagens e preparar novas etapas de invasão.
Além disso, a utilização de infraestrutura distribuída dificulta a identificação de padrões exclusivamente baseados em endereços IP. A análise precisa considerar também o comportamento das contas, os dispositivos utilizados, os registros de autenticação e as alterações realizadas após o acesso inicial.
Como os invasores mantêm o acesso após comprometer uma conta
Roubar um token é apenas uma etapa de uma invasão. Para ampliar o impacto e evitar perder o acesso, criminosos podem tentar modificar configurações da identidade comprometida, registrar novos métodos de autenticação e alterar regras de processamento de mensagens.
Essas ações transformam uma sessão comprometida em uma oportunidade de persistência. Mesmo que o acesso inicial seja interrompido, alterações realizadas na conta podem continuar produzindo efeitos até serem identificadas e removidas.
Para os administradores, isso significa que a resposta ao incidente precisa ir além da redefinição da senha. É necessário investigar o que aconteceu durante a sessão comprometida e verificar se o invasor deixou mecanismos adicionais de acesso.
O perigo dos dispositivos não autorizados no Microsoft Entra ID
O Microsoft Entra ID, anteriormente conhecido como Azure Active Directory, centraliza a gestão de identidades, dispositivos e políticas de acesso em muitos ambientes corporativos.
Durante uma invasão, um criminoso pode tentar registrar um dispositivo não autorizado, adicionar um método de autenticação ou explorar permissões já concedidas à conta. A inclusão de um dispositivo desconhecido, especialmente pouco tempo depois de um login suspeito, deve ser tratada como um possível indicador de comprometimento.
A investigação descrita aponta para atividades de persistência realizadas em intervalos curtos, incluindo registros de dispositivos falsos menos de uma hora após a invasão inicial.
É importante distinguir o registro de um dispositivo da emissão de um token. São mecanismos diferentes, com implicações distintas para a segurança. Um dispositivo registrado não garante automaticamente acesso permanente, mas pode facilitar acessos posteriores quando combinado com permissões, métodos de autenticação ou políticas inadequadas.
Por isso, administradores devem verificar os dispositivos associados às identidades comprometidas e comparar os registros com o inventário corporativo. Equipamentos desconhecidos, nomes genéricos, registros recentes e atividades incompatíveis com o usuário exigem investigação.
Também é necessário revisar os métodos de autenticação cadastrados. Um aplicativo autenticador adicionado sem autorização pode permitir que o invasor continue recebendo códigos ou aprovando desafios, dependendo do método utilizado e das proteções implementadas.
Regras silenciosas de e-mail e manipulação de caixas de entrada
Outro mecanismo de persistência consiste na criação de regras maliciosas nas caixas de correio. No Microsoft 365, regras de processamento podem mover mensagens, encaminhar determinados conteúdos ou excluir e-mails automaticamente.
Criminosos podem utilizar essa funcionalidade para ocultar notificações de segurança, desviar comunicações financeiras ou dificultar a identificação de alterações realizadas na conta. Regras com nomes aparentemente insignificantes, como “.”, “sss” ou “iT”, podem passar despercebidas em uma inspeção superficial.
Uma regra maliciosa pode, por exemplo, direcionar mensagens que contenham termos relacionados a pagamentos para outra pasta. Em ataques contra empresas, isso pode ajudar a acompanhar negociações, interceptar instruções financeiras ou preparar fraudes envolvendo fornecedores.
A exclusão automática de alertas também pode reduzir a chance de a vítima perceber uma invasão. Entretanto, a ausência de mensagens na caixa de entrada não significa que o registro da atividade tenha desaparecido de todos os sistemas de auditoria.
As equipes de segurança devem examinar as regras de caixa de entrada, os encaminhamentos externos, as permissões de delegação e as alterações recentes nas configurações de correio. Qualquer mudança incompatível com o comportamento habitual do usuário precisa ser investigada.
Guia de resposta a incidentes e mitigação para administradores
Diante de um possível comprometimento, a prioridade é interromper o acesso indevido e preservar informações que permitam reconstruir a sequência do ataque.
A resposta deve abranger a identidade, os dispositivos, as sessões autenticadas, os métodos de MFA e os serviços acessados. Uma abordagem limitada à troca da senha pode deixar mecanismos de persistência ativos.
1. Revogue as sessões e os tokens de autenticação
Comece identificando as contas afetadas e revogando suas sessões por meio do centro de administração do Microsoft Entra ou dos recursos administrativos disponíveis.
No PowerShell, o módulo Microsoft Graph permite executar ações administrativas, desde que o operador tenha as permissões necessárias. Um exemplo de revogação das sessões de um usuário é:
Connect-MgGraph -Scopes "User.RevokeSessions.All","User.Read.All"
Revoke-MgUserSignInSession -UserId "usuario@empresa.com"Substitua o endereço pelo identificador da conta investigada. Antes de executar comandos em produção, confirme as permissões concedidas, os requisitos atuais do módulo e os procedimentos internos de resposta a incidentes.
A revogação de sessões não deve ser interpretada como garantia de invalidação instantânea de todos os tokens em todos os serviços. Alguns tokens podem continuar utilizáveis por determinado período, conforme o tipo de token, a aplicação e os mecanismos de validação empregados.
Por isso, combine a revogação com a redefinição da senha quando indicada, a remoção de métodos de autenticação não autorizados e a investigação dos recursos acessados.
2. Audite dispositivos e métodos de autenticação
No Microsoft Entra ID, revise os registros de entrada e os dispositivos associados às contas comprometidas.
Procure autenticações provenientes de locais ou redes inesperados, mudanças abruptas de dispositivo, sequências de acesso incompatíveis com o perfil do usuário e atividades registradas pouco antes ou depois do incidente.
Em seguida, verifique os métodos de autenticação cadastrados. Remova aplicativos autenticadores, números de telefone, chaves ou outros métodos que não pertençam legitimamente ao usuário, seguindo o procedimento de recuperação de identidade da organização.
Não remova indiscriminadamente todos os dispositivos corporativos. Primeiro, confirme a propriedade e o vínculo de cada registro com o inventário de TI. Essa precaução reduz o risco de interromper operações legítimas durante a contenção.
3. Inspecione regras de e-mail e permissões
Examine as regras de caixa de entrada, o encaminhamento automático e as permissões de delegação das contas afetadas.
Busque regras recém-criadas, nomes incomuns, condições que correspondam a mensagens financeiras e ações que movam ou excluam comunicações. Verifique também se foram concedidas permissões a aplicativos ou usuários que não deveriam ter acesso à caixa de correio.
Remova as alterações maliciosas identificadas e registre as evidências relevantes antes de modificar as configurações, quando isso for compatível com o procedimento de resposta da organização.
A investigação deve incluir ainda os registros de auditoria disponíveis para identificar mensagens acessadas, regras alteradas, permissões concedidas e outras atividades executadas durante o período do comprometimento.
4. Implemente políticas de acesso condicional mais rigorosas
As Políticas de Acesso Condicional (CAP) permitem estabelecer condições para conceder, restringir ou bloquear o acesso aos recursos corporativos.
Uma política bem planejada pode exigir dispositivos compatíveis com os padrões de segurança da organização, restringir acessos de risco e limitar sessões de acordo com a sensibilidade dos dados. Recursos de avaliação contínua de acesso, quando disponíveis e compatíveis com os serviços utilizados, também podem ajudar a responder a mudanças relevantes nas condições de autenticação.
A configuração precisa considerar as contas administrativas, os aplicativos legados, as exceções necessárias e os procedimentos de recuperação. Testar as políticas em modo de relatório antes de aplicá-las amplamente reduz o risco de bloquear usuários legítimos.
Também é recomendável restringir o fluxo de código de dispositivo aos cenários em que ele seja realmente necessário. Esse mecanismo legítimo de autenticação pode ser abusado em campanhas de phishing quando a vítima é induzida a autorizar uma sessão iniciada por outra pessoa.
5. Adote MFA resistente a phishing
O uso de MFA resistente a phishing é uma das medidas mais importantes para reduzir o risco de roubo de credenciais por páginas intermediárias.
Métodos baseados em FIDO2, WebAuthn e chaves de segurança vinculadas ao domínio legítimo oferecem proteções que códigos temporários convencionais não proporcionam. As passkeys compatíveis com esses padrões também podem reduzir a exposição a páginas fraudulentas, dependendo da implementação e das condições de autenticação.
Certificados de autenticação e outros mecanismos corporativos podem complementar a estratégia, desde que sejam configurados de acordo com os requisitos do ambiente.
Nenhum método deve ser tratado como solução isolada. A organização precisa combinar autenticação resistente a phishing, políticas de acesso, monitoramento, proteção de dispositivos e processos de recuperação de contas.
Lições cruciais para a segurança de identidade na nuvem
A campanha evidencia que a segurança de uma identidade corporativa não termina quando a senha é protegida ou o MFA é ativado. A sessão autenticada também se tornou um alvo prioritário, pois pode concentrar o acesso a documentos, mensagens, aplicações e informações estratégicas.
A repetição de tokens no Microsoft 365 mostra por que os administradores precisam avaliar toda a cadeia de autenticação. A captura de uma sessão, o registro de dispositivos desconhecidos e a criação de regras maliciosas de e-mail podem formar etapas complementares de uma invasão.
A defesa exige uma combinação de autenticação resistente a phishing, políticas de acesso condicional, auditoria contínua e capacidade de revogar acessos suspeitos. Também requer atenção às mudanças realizadas depois do login inicial, especialmente quando envolvem métodos de MFA, dispositivos e configurações de correio.
Para equipes de TI, a recomendação é revisar periodicamente os registros do Microsoft Entra ID, testar os procedimentos de contenção e verificar se as políticas atuais realmente limitam o acesso em situações de risco.
