Um servidor mal configurado expôs três operações de phishing contra o Microsoft 365

Existe uma ironia recorrente na segurança ofensiva: quem ataca também erra na configuração. Em abril de 2026, um servidor Python usado para hospedar um kit de phishing ficou com o directory listing habilitado e o histórico de comandos legível para qualquer visitante. O resultado foi uma janela rara para dentro da operação, permitindo reconstruir três campanhas distintas de roubo de credenciais do Microsoft 365, os operadores por trás delas e as técnicas que usavam no dia a dia.

Este artigo recria essa análise sob a ótica ofensiva: o que dava para ver nos logs, por que essas técnicas ainda funcionam contra ambientes com MFA e, principalmente, o que sua organização deveria estar caçando nos próprios registros de autenticação.

O erro que abriu a porta

O servidor em questão respondia em um endereço hospedado em Budapeste e servia arquivos sem qualquer restrição de acesso. Directory listing habilitado significa que, ao acessar um diretório sem arquivo index, o servidor devolve a lista completa do que existe ali. Somado a isso, o histórico de shell dos operadores estava salvo em texto plano e acessível pela mesma interface web.

_{Fonte: TheHackerNews}

Do ponto de vista de quem investiga, isso é o equivalente a encontrar o caderno de anotações do atacante. Cada comando executado, cada domínio registrado, cada renovação de certificado e cada credencial capturada estava ali, datado e atribuível. É exatamente o tipo de falha operacional (OPSEC) que ensinamos clientes de red team a evitar: separar infraestrutura, negar listagem de diretórios por padrão e nunca deixar artefato de operação exposto na mesma superfície que serve o phishing.

Três operações, três operadores

O que tornou o achado interessante não foi um único ataque, mas o fato de a mesma infraestrutura abrigar três operações paralelas, cada uma com um perfil de operador diferente:

• codemado — operador com atividade rastreável desde 2018, responsável pela campanha de maior volume de disparos.
• mail-argenta — responsável por uma variante de Evilginx apelidada internamente de "red-queen".
• saroula01 — operador da variante "black-queen", que apresentava o maior número de credenciais efetivamente capturadas.

Esses apelidos e a divisão de trabalho aparecem porque a barreira de entrada para montar uma operação de phishing hoje é praticamente zero. Kits prontos, painéis de gestão e infraestrutura como serviço reduziram o que antes exigia conhecimento técnico a um fluxo de "assinar e disparar". Isso muda o perfil de ameaça: você não está mais lidando apenas com atacantes sofisticados, mas com um ecossistema de comoditização onde qualquer operador consegue rodar um AiTM competente.

As técnicas por trás das campanhas

Duas abordagens distintas apareceram nos logs, e vale entender cada uma porque exigem defesas diferentes.

Adversary-in-the-Middle com Evilginx

Duas das campanhas usavam forks customizados do Evilginx2, uma ferramenta de proxy reverso que se posiciona entre a vítima e a página legítima de login da Microsoft. O funcionamento é o seguinte:

1. A vítima recebe um link de phishing e acessa uma página que parece ser o login da Microsoft.
2. Na prática, essa página é um proxy. Tudo que a vítima digita é repassado em tempo real para o servidor real da Microsoft.
3. A vítima completa o login normalmente, inclusive o MFA, porque está de fato autenticando na Microsoft.
4. O proxy intercepta o cookie de sessão emitido após a autenticação bem-sucedida.

É por isso que AiTM derrota a maioria das implementações de MFA: o segundo fator é validado de verdade, mas o atacante rouba o resultado da autenticação (o cookie de sessão), não a senha ou o código. Com o cookie em mãos, ele entra sem precisar passar pelo MFA de novo.

Um detalhe operacional revelado nos logs: os operadores configuravam um TTL de um ano para os cookies capturados. Ou seja, prolongavam artificialmente a validade da sessão roubada para manter acesso pelo maior tempo possível antes que uma expiração natural os expulsasse.

Abuso do Device Code Flow

A terceira campanha, atribuída a saroula01, usava uma técnica mais elegante e mais difícil de detectar: o abuso do device code flow do OAuth da Microsoft.

O device code flow é um fluxo legítimo, criado para autenticar dispositivos sem teclado (TVs, consoles, alguns apps de linha de comando). O ataque funciona assim:

1. O atacante inicia um device code flow e obtém um código.
2. Ele induz a vítima a acessar a página genuína da Microsoft (microsoft.com/devicelogin) e inserir esse código.
3. A vítima faz login na página real da Microsoft, sem qualquer sinal de phishing tradicional, e ao confirmar o código está na verdade autorizando a sessão do atacante.

Aqui não há domínio falso, não há certificado suspeito, não há proxy. A vítima interage com a infraestrutura oficial da Microsoft o tempo todo. É justamente essa "limpeza" que torna o device code phishing tão perigoso: os indicadores clássicos que você ensina os usuários a observar (URL estranha, cadeado ausente) simplesmente não aparecem.

O que os números revelaram

Os registros deixados no servidor permitiram dimensionar o estrago de uma das campanhas:

Os 97 tokens com capacidade de autorefresh são o dado mais preocupante. Um token que se renova sozinho mantém o acesso vivo indefinidamente, sem precisar de nova interação da vítima. Algumas dessas sessões haviam sido renovadas mais de 25 vezes, o que indica meses de acesso persistente e silencioso a caixas de correio corporativas na América do Norte e na Europa.

O arsenal completo

Além dos forks de Evilginx, a infraestrutura reunia um conjunto de ferramentas que mostra como essas operações se profissionalizaram:

• MaDoO Blaster — disparador em massa de e-mails, usado para a fase de distribuição do phishing.
• SimpleHelp — console de acesso remoto.
• XEOX RMM — ferramenta de gestão remota usada para persistência nos endpoints comprometidos.

_{Fonte: TheHackerNews}

As credenciais roubadas não ficavam paradas. Eram alimentadas em um ecossistema de phishing como serviço, onde acessos válidos viram mercadoria: revendidos, monetizados e reutilizados por outros operadores. É o mesmo padrão de comoditização que discutimos no nosso artigo sobre Threat Intelligence e monitoramento da dark web.

Como se defender

A defesa aqui não é uma bala de prata, e sim camadas específicas para cada técnica. Separei entre prevenção e detecção.

Contra phishing AiTM

Adote autenticação resistente a phishing. FIDO2 e passkeys resolvem o problema de raiz porque vinculam a autenticação ao domínio legítimo. Como o proxy do Evilginx opera em um domínio diferente, a chave criptográfica simplesmente não responde ao pedido de login falso. Diferente de um código TOTP ou de um push, uma passkey não pode ser "repassada" para o site verdadeiro por um intermediário.

Se a migração completa para passkeys não for viável no curto prazo, priorize os acessos privilegiados e as contas de maior risco primeiro.

Contra abuso de device code flow

Bloqueie o device code flow onde ele não é necessário. A maioria das organizações não precisa desse fluxo habilitado para a maior parte dos usuários. Use políticas de Acesso Condicional (Conditional Access) para restringi-lo apenas aos cenários legítimos.

Complemente com:

• Políticas baseadas em localização/IP para limitar de onde autenticações podem partir.
• Continuous Access Evaluation (CAE) para revogar sessões mais rápido quando o risco muda.

Detecção nos logs do Entra

Se você já foi alvo, os sinais estão nos registros de autenticação. Vale a pena montar caça ativa (threat hunting) para:

• Client ID do Office d3590ed6-52b3-4102-aeff-aad2292ab01c partindo de IPs desconhecidos. Esse é o identificador associado ao fluxo abusado.
• O campo Original transfer method nos sign-in logs, que ajuda a distinguir device code flow de autenticações normais.
• Sessões com renovação de token anormalmente frequente ou a partir de geolocalizações incompatíveis com o usuário.

Detecção no endpoint

Como a persistência usava XEOX RMM, procure por:

• O agente em C:\Program Files (x86)\XEOX\xeox-agent_x64.exe.
• Tarefas agendadas que batam com o padrão *XEOX*Agent*Watchdog*.

Conclusão

O que esse caso mostra, mais do que qualquer indicador isolado, é que a defesa baseada em "treinar o usuário a reconhecer o site falso" perdeu força. Com AiTM, o site é real. Com device code, não existe site falso. O MFA tradicional, por si só, já não segura essas técnicas.

A resposta certa é combinar autenticação resistente a phishing (FIDO2/passkeys), redução de superfície via Acesso Condicional e detecção ativa nos logs de autenticação. Do lado ofensivo, é exatamente esse tipo de cenário que simulamos em engajamentos de red team: não basta validar se o MFA existe, é preciso validar se ele resiste a um adversário que já domina essas técnicas.

Se quiser entender como sua organização se comporta diante de um ataque AiTM real, fale com o time da XPSec. E se ainda tem dúvidas sobre a diferença entre um pentest e um exercício de red team para esse tipo de avaliação, vale a leitura do nosso comparativo entre pentest e red team.