Servidor mal configurado expõe três operações de phishing com Evilginx contra o Microsoft 365

Directory listing ativo e histórico de shell legível revelaram forks do Evilginx e um abuso do fluxo de device code que dispensa proxy e resiste a passkeys.

Componente	Contas Microsoft 365 e Entra ID atacadas por três forks do proxy adversary-in-the-middle Evilginx e por abuso do fluxo OAuth device code; infraestrutura hospedada em 185.163.204[.]7 (Budapeste) com console remoto SimpleHelp no mesmo host.
Vetor	Dois mecanismos distintos: proxy do login ao vivo (AiTM) que intercepta credenciais e cookies de sessão, e phishing de device code que gera um código real, o embute em página com tema do Authenticator e leva a vítima a autorizar a sessão do atacante no próprio microsoft.com/devicelogin.
Impacto	Captura e refresh contínuo de tokens de sessão do M365; a campanha baseada em device code registrou 218 contas capturadas entre junho de 2025 e julho de 2026, cerca de 94% caixas corporativas, com tokens marcados autoRefresh e renovados até 25 vezes.
Prioridade	Bloquear o device code flow via Conditional Access onde não for necessário e adotar MFA resistente a phishing (FIDO2/passkey) para conter o vetor de proxy; um não cobre o outro.
Artefatos	Agente RMM XEOX em C:\Program Files (x86)\XEOX\xeox-agent_x64.exe e tarefas agendadas no padrão *XEOX*Agent*Watchdog*; client ID do Microsoft Office d3590ed6-52b3-4102-aeff-aad2292ab01c em concessões de refresh token nos logs de entrada do Entra.
IoCs	Domínios de phishing defangados picis[.]net e romnor[.]ca; plataforma de disparo em massa MaDoO Blaster. A infraestrutura de domínios e IPs rotaciona rapidamente, então serve para contenção, não como correção definitiva.

Resumo técnico

Uma operação de phishing ativa contra o Microsoft 365 foi comprometida pela própria negligência do operador: um servidor web em Python permaneceu escutando em porta pública com directory listing habilitado, e o comando operacional que o iniciou ainda estava registrado em um arquivo de histórico de shell legível. A partir dessa exposição, a firma francesa de segurança Lexfo recuperou o toolkit completo do operador e, pivotando pelos artefatos, chegou a mais dois operadores, totalizando três campanhas. Cada uma rodava um fork próprio do proxy de código aberto Evilginx, clonado de repositórios públicos no GitHub.

A maior das três campanhas rodava havia mais de um ano, com vítimas majoritariamente corporativas. O ponto central para quem opera Microsoft 365 é que os três burlaram a MFA de duas formas mecanicamente diferentes: uma proxiando o login ao vivo e outra abusando de um fluxo legítimo de autenticação da Microsoft. Como os mecanismos são distintos, exigem defesas distintas, e uma mitigação não neutraliza a outra.

Fluxo técnico

O directory listing em um servidor de ataque em operação funcionou como confissão quase completa. A listagem expôs configurações de phishing, logs de coleta de credenciais, instaladores de RMM, combolists, arquivos de backup e até arquivos de sessão do Telegram do operador. No mesmo host rodavam um proxy adversary-in-the-middle Evilginx e um console remoto SimpleHelp, no endereço 185.163.204[.]7, em Budapeste, catalogado no fim de abril de 2026 durante uma varredura rotineira da internet. O histórico de shell e um conjunto de repositórios públicos apontaram diretamente para o operador, identificado pelo handle codemado, um ator egípcio ativo em fóruns de VoIP e hacking desde 2018, que mantinha uma plataforma AiTM de Microsoft 365 e monetizava o acesso por meio de um disparador em massa próprio chamado MaDoO Blaster.

O primeiro fork adicional, chamado red-queen, atribuído a um operador nigeriano rastreado como mail-argenta, mostra o grau de refinamento aplicado sobre um framework público: ele renomeia os atributos HTML de crossorigin e integrity para derrotar checagens de Subresource Integrity e adiciona um mecanismo de reescrita de URL ao componente http_proxy.go para escapar de detecção baseada em caminho, além de pré-preencher o e-mail da vítima para reduzir abandono. Esse operador acabou exposto do mesmo modo que suas vítimas: seu e-mail e uma senha apareceram em logs de infostealer, e essa senha vazada coincidia com a que estava fixada como senha do MySQL em seu painel Kraken e reutilizada em outras contas.

O terceiro fork, black-queen, atribuído ao handle saroula01, é o mais relevante em termos defensivos porque nunca toca em senha. Ele foi construído em torno do fluxo OAuth device code da Microsoft, um caminho de autenticação legítimo destinado a dispositivos com entrada limitada. O ataque gera um código de dispositivo real, o envolve em uma página-isca com tema do Authenticator e instrói o alvo a inseri-lo na página genuína de device login da Microsoft. A vítima autentica em uma página real da Microsoft e satisfaz a própria MFA; o backend do operador consulta o endpoint de token e captura o token no instante em que a autorização é concedida.

Superfície afetada

Chamar o abuso de device code de bypass de MFA descreve mal o mecanismo: nada é contornado. A página-isca com tema do Authenticator é construída pelo atacante, mas o código de dispositivo e a página onde a vítima conclui o login são genuínos, então o prompt de MFA satisfeito é real. Por isso, uma passkey ou chave FIDO2 não ajuda nesse vetor específico: a vítima autentica em infraestrutura genuína da Microsoft enquanto autoriza a sessão do atacante, e a vinculação de origem que interrompe o Evilginx passa limpa porque a origem realmente é a Microsoft.

• Contas corporativas de Microsoft 365 em pelo menos uma dúzia de países foram capturadas na campanha baseada em device code, com cerca de 94% de caixas corporativas entre 218 contas registradas.
• Um arquivo de tokens brevemente enviado ao repositório e depois apagado, ainda legível no histórico do git, guardava 97 tokens ativos da Microsoft ligados a três vítimas, todos com autoRefresh e alguns renovados até 25 vezes.
• Ambientes que dependem legitimamente de device code flow, como dispositivos de sala Teams e algumas ferramentas de linha de comando, e que por isso deixam o fluxo habilitado de forma ampla.
• Organizações que adotaram apenas MFA resistente a phishing acreditando estar totalmente cobertas continuam expostas ao caminho de device code.

Hunting e telemetria

A detecção precisa cobrir os dois vetores separadamente. Para o abuso de device code, a orientação da própria Microsoft sinaliza um detalhe importante: uma sessão iniciada com device code flow permanece marcada em refreshes posteriores mesmo quando o evento atual já não exibe o método, então a caça deve ocorrer sobre o campo de método de transferência original do login, e não apenas sobre o protocolo de autenticação ativo no momento.

• Concessões de refresh token associadas ao client ID do Microsoft Office d3590ed6-52b3-4102-aeff-aad2292ab01c nos logs de entrada do Entra, onde esse cliente desktop não está em uso normal, cruzadas com IPs de origem incomuns.
• Capturas repetidas da mesma conta a partir de IPs diferentes, comportamento consistente com refresh de tokens roubados conforme expiram.
• Sessões cujo campo de método de transferência original indica device code flow, mesmo quando o protocolo de autenticação corrente não o reflete.
• Presença do agente RMM XEOX em C:\Program Files (x86)\XEOX\xeox-agent_x64.exe e tarefas agendadas no padrão *XEOX*Agent*Watchdog*, usadas pelos operadores para persistência em endpoints.
• Tokens de sessão marcados com autoRefresh sendo renovados de forma anômala e prolongada, indício de framework mantendo sessões vivas por conta própria.

Mitigação

As duas técnicas não compartilham correção. MFA resistente a phishing, FIDO2 ou passkeys ainda encerram o lado Evilginx ao vincular o login ao domínio real, mas não detêm o abuso de device code. Para esse segundo caminho, a alavanca é o Conditional Access. A recomendação da Microsoft é bloquear o device code flow onde for possível, mantendo-o apenas para os poucos cenários que realmente dependem dele, como hardware de entrada limitada.

• Inventariar o uso real de device code flow a partir dos logs de entrada, bloquear o fluxo em todo o restante e testar a política em modo report-only antes de forçar a aplicação.
• Aplicar políticas de Conditional Access baseadas em localização/IP e habilitar Continuous Access Evaluation, para que um token roubado visto fora das faixas permitidas seja reavaliado em vez de sobreviver por todo o seu tempo de vida em cargas de trabalho suportadas.
• Manter MFA resistente a phishing (FIDO2/passkey) para conter o vetor de proxy reverso do Evilginx, reconhecendo que ele não cobre o device code.
• Tratar domínios e IPs conhecidos como medida de contenção temporária, dada a rápida rotação de infraestrutura observada, e priorizar controles de identidade sobre bloqueio de indicadores.
• Investigar endpoints com sinais de RMM abusado (XEOX e tarefas de watchdog associadas), revogar sessões e tokens ativos das contas afetadas e forçar reautenticação após a contenção.