A cadeia de falha do phishing na Microsoft 365: de Evilginx e repousa pública ao abuso do device code

Uma descoberta aparentemente trivial — um servidor de Python público com a lista de pastas ativado e um .bash_history legível — descorriou a cortina sobre três campanhas de phishing dirigidas à Microsoft 365 e permitiu aos pesquisadores reconstruir uma cadeia completa de ferramentas, operadores e táticas. Essa pequena falha operacional é a moral: a segurança não costuma se quebrar por um único exploit sofisticado, mas por uma combinação de código disponível publicamente, má higiene operacional e automação que baixa a barreira de entrada para atacantes pouco experientes.

Nos casos analisados foram utilizados dois mecanismos tecnicamente distintos para capturar acessos a contas corporativas: por um lado, proxies de adversary-in-the-middle construídos sobre forks do projeto Evilginx (um proxy que preserva a página real para enganar o usuário e captura cookies de sessão) e, por outro, um abuso legítimo do fluxo OAuth conhecido como device code flow, que obriga a vítima a completar o início em microsoft.com/devicelogin e onde o atacante “polling” toma o token quando o usuário o autoriza. Ambas as abordagens são perigosas, mas exigem defesas diferentes: a primeira se mitiga com MFA resistentes a phishing (FIDO2/passkeys) e binding de origem; a segunda exige políticas de acesso condicional que bloqueem ou limitem o device code flow.

É relevante que todos os marcos usados pelos operadores fossem forks públicos ou binários pré-compilados distribuídos no GitHub, alguns com melhorias projetadas para evitar detecção e prolongar a validade dos cookies ou tokens. Isso confirma uma tendência: a comercialização do phishing como serviço e a reutilização massiva de código disponível em repositórios públicos fazem com que campanhas efetivas possam ser montadas com pouco custo e por atores que não desenvolvem infra-estruturas a partir de zero. O repositório original de Evilginx continua sendo um recurso conhecido e acessível: https://github.com/kgretzky/evilginx2.

As consequências práticas para uma equipe de segurança da Microsoft 365 são claras e urgentes. Primeiro, não contar com políticas de acesso condicional que restrinjam o device code flow deixa uma porta aberta que não se fecha com a mera implantação de FIDO2. A Microsoft, por sua vez, documenta o device code flow e suas utilizações legítimas em desenvolvimentos: https://learn.microsoft.com/azure/active-diretory/develop/v2-oauth2-device-code. Para mitigar o abuso, a alavanca operacional é a Conditional Access: inventorya que aplicativos precisam realmente desse fluxo, teste uma política em modo apenas relatório e depois proíbe o fluxo onde não é necessário. O guia geral do Conditional Access e suas capacidades está disponível aqui: https://learn.microsoft.com/azure/active-diretory/conditional-access/overview.

Em paralelo, a defesa contra proxies de tipo AiTM exige implantar MFA resistente a phishing e controles que validen a origem do início de sessão. FIDO2 e passkeys são eficazes para bloquear o Evilginx clássico porque associam a autenticação a uma origem legítima; no entanto, não são suficientes por si só para cobrir device code abuse. Além disso, a Microsoft recomenda adicionar Continuous Access Evaluation para forçar reavaliações de sessões quando um token roubado aparece de locais ou condições anormais: https://learn.microsoft.com/azure/active-diretory/continuous-access-evaluation-overview.

Desde a detecção e a caça de ameaças, há sinais concretos que priorizar. Verifique os registros de login de Entra (Azure AD) em busca de concessões de refresh token associadas ao client ID do cliente do Office desktop d3590ed6-52b3-4102-aeff-aad2292ab01c Quando esse cliente não faz parte da base de uso normal. Crucialmente, rastreem o campo Original transfer method e não apenas o atual evento de autenticação, porque as sessões iniciadas por device code podem conservar esse rastro, embora a autenticação posterior já não o mostre explicitamente.

Em endpoints, busquem artefatos de persistência que os operadores deixam após o seu pivot, incluindo ferramentas RMM que costumam ser implantadas para manter acessos. Nos casos investigados apareceu um agente chamado XEOX (por exemplo C:\\Program Files (x86)\\XEOX\\xeox- agent_ x64.exe) e tarefas agendadas com padrões que podem ser detectáveis. Estas pegadas variam, por isso combinem telemetry EDR com buscas de assinaturas e alerta sobre executáveis desconhecidos ou novos relógios de persistência.

Existe também uma lição operacional para programadores e administradores de infra-estruturas: nunca exponha listas de pastas ou informações sensíveis em servidores públicos, limpa os estóriais de shell e não armazéns senhas em texto claro em painéis ou ficheiros versionados. Se um repositório público contém segredos ou binários pré-compilados expõe a operação completa: aprende a remover dados sensíveis do histórico do Git e a girar credenciais comprometidas; o GitHub explica como tratar repositórios com informações sensíveis aqui: https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository.

Em resposta imediata a uma suspeita: revoquen tokens e sessões afetadas, foirzen a caducidade de refresh tokens comprometedores, apliquem a política de Conditional Access que bloquee device code flow se não for imprescindível, coloquem em quarentena e forense os endpoints detectados com RMM, e notifiquem a Microsoft e os prestadores de serviços comprometidos para coordenar mitigação e bloqueios de infraestrutura rotativa. Considere um exercício de “contenção + endurecimento”; bloquear IPs e domínios é útil, mas insuficiente se as políticas que permitem a técnica não forem corrigidas.

A conclusão editorial é que a proteção efetiva contra essas campanhas requer duas camadas simultâneas: políticas técnicas que fechem vetores protocolarios (bloquear device code onde não é necessário e aplicar CAE) e melhorias operacionais que fecham vazamentos e más práticas (controlo de repositórios, limpeza de histórias, rotação de segredos). Enquanto o ecossistema de phishing continua sendo comercial e modulavel – com forks polidos, binários prontos e geração assistida por modelos –, as organizações que criam que implantar MFA e treinamento de usuários é suficiente estarão expostas. Defender Microsoft 365 hoje significa combinar MFA resistente, Conditional Access bem desenhado, detecção de anomalias em tokens e boas práticas de segurança em servidores e repositórios.