EvilTokens: phishing criptografado que se ativa no DOM do navegador e quebra as defesas

Um novo vetor de phishing está explodindo uma fraqueza operacional que muitos equipamentos de segurança assumem cobertura: o ataque permanece criptografado e "fantasma" até que o navegador do empregado o decifra e o renderiza. A campanha EvilTokens que está detectando atividade nos Estados Unidos e na Europa usa exatamente essa técnica: a página maliciosa chega como uma carga cifrada (AES-GCM) e só se torna visível após ser decifrada no DOM do navegador, onde ativa um fluxo legítimo do Microsoft Device Code para convencer a vítima de autorizar acesso à sua conta sem revelar a senha.

A consequência imediata é que os controles convencionais - previsão estática de URLs, bloqueios em passarelas de correio ou filtragem em nível de rede - podem dar um falso negativo. A ligação inspecionada a frio mostra conteúdo inocuo ou blob cifrado, enquanto o usuário, ao abri-lo no seu navegador, vê uma página que inicia o fluxo de autenticação e entrega um código de dispositivo que termina sendo usado para obter tokens e acesso à Microsoft 365. Microsoft documenta como funciona o Device Code Flow e por que não requer ingresso de credenciais no contexto original do atacante https://learn.microsoft.com/en-us/azure/active-diretory/develop/v2-oauth2-device-code.

Isso cria um “ponto cego” crítico nas operações do SOC: a evidência que chega à fila de análise de Tier 1 pode ser incompleta, as decisões de contenção se atrasam e os atacantes ganham janela para consolidar acesso, mover laterais e extrair dados. Os setores mais afetados, segundo a telemetragem de sandbox como ANY.RUN, incluem consultoria, serviços financeiros, manufatura e tecnologia, onde a exposição a phishing relatada é superior a 65% em muitas verticais; um início de sessão comprometido na Microsoft 365 pode significar correio corporativo, arquivos e fluxos de trabalho comprometidos, bem como riscos de fraude e BEC.

A forma mais prática de fechar esse ponto cego é levar a inspeção ao navegador. Ferramentas de sandboxing interativo que capturam o DOM, XHR/Fetch e o tráfego por trás de cena permitem ver o momento exato em que a carga cifrada é decifrada, quais pedidos backend lança o código de dispositivo e que endpoints são usados (por exemplo, rastreando chamadas a /api/device/start e semelhantes). ANY.RUN é um exemplo desta abordagem interativa, onde as sessões reproduzem a experiência do usuário e geram evidências acionáveis para a resposta https://any.run/.

Para os líderes de segurança isso implica reequilibrar controles: não basta bloquear URLs suspeitos, você precisa complementar com inspeção em navegador e controles de identidade fortes. A Microsoft já recomenda políticas de consentimento e controle sobre aplicativos OAuth; revisar e limitar quais aplicativos podem obter permissões, bloquear consentimento de aplicativos de terceiros por defeito e auditar permissões é básico para reduzir o dano possível se um token for emitido a um ator malicioso https://learn.microsoft.com/en-us/azure/active-diretory/manage-apps/secure-your-app- consent.

Em termos operacionais, há medidas concretas e urgentes que deveriam fazer parte da resposta a este tipo de incidentes: isolar a sessão comprometida e revogar tokens e sessões federadas do Azure AD, eliminar consentimentos de aplicativos não reconhecidos, analisar os registros de Sign-In e Audit para identificar quando e como os tokens foram emitidos, e aplicar políticas de acesso condicional e MFA que dificultem a reutilização de credenciais ou tokens roubados. Também é essencial manter evidências do DOM e dos pedidos XHR para obter indicadores de compromisso (domínios, endpoints, hashes) que permitam bloquear infra-estruturas relacionadas e alimentar regras de detecção.

Para além da resposta técnica, convém ajustar processos: dotar Tier 1 de maior visibilidade (capturas do navegador, resumos automatizados e IOCs) reduz a pressão sobre analistas seniores e acelera a contenção; automatizar a geração de relatórios com contexto da sessão evita perda de tempo em reconstruções manuais e reduz o custo operacional. Rever playbooks para incluir passos específicos frente aos fluxos de autorização OAuth/device code deve ser prioridade.

Nem todos os ataques encriptados são idênticos, mas o padrão se repete: conteúdo que escapa aos filtros tradicionais reaparece dentro do navegador e desencadeia um fluxo legítimo que concede acesso. A proteção efetiva combina restrições de identidade e consentimento, detecção baseada em comportamento de navegador, e sandboxes que registram o DOM e as chamadas XHR para rastrear a cadeia completa do ataque. Entender e capturar a fase em que o HTML passa de criptografia em execução é a diferença entre um incidente contido e um que escala a fraude, perda de dados e resposta dispendiosa.

Para equipamentos que gerem riscos em ambientes Microsoft 365, a prioridade imediata é instrumentar controles de identidade e consentimentos, adicionar inspeção em navegador à cadeia de detecção e estabelecer playbooks que incluam revogação de tokens e auditoria de consentimentos. Ao mesmo tempo, convém rever a cifra utilizada pelos atacantes - por exemplo, AES-GCM é a técnica que oculta o payload nestas campanhas - para entender por que as soluções baseadas apenas em URL ou conteúdo estático falham https://en.wikipedia.org/wiki/Galois/Counter_Mode.

Em suma, EvilTokens e variantes semelhantes não introduzem uma nova vulnerabilidade na Microsoft, mas um vetor operacional que explora a falta de visibilidade no navegador e a confiança em fluxos legítimos de autorização. A defesa passa por transferir a inspeção para o local onde ocorre o ataque: o DOM e as comunicações do navegador, alavancar sandboxes interativas para obter provas completas e endurecer políticas de consentimento e acesso na nuvem. Essa combinação reduz a janela de exposição e evita que um único acesso à Microsoft 365 se torne um incidente maior.