Por Andrew Matheus da Silva Lobo
Os ataques de phishing baseados em Adversary-in-the-Middle (AiTM) continuam crescendo e, entre o último ano e o início de 2025, esse tipo de fraude — especialmente as variantes que burlam MFA — se tornou ainda mais frequente. Depois que o Exchange Online aposentou a autenticação básica, muitos agentes maliciosos passaram a adotar técnicas mais avançadas, como proxies AiTM, captura de cookies de sessão, phishing via QR code e outros métodos modernos voltados a interceptar credenciais e tokens.
A Microsoft registrou um aumento de 146% nos ataques do tipo Adversary-in-the-Middle (AiTM) ao longo de 2024, mostrando que os atacantes continuam evoluindo suas técnicas para invadir contas mesmo quando protegidas por autenticação multifator (MFA).
ℹ️ A MFA, isoladamente, não resolve todos os desafios de segurança de identidade. Mesmo com esse recurso habilitado, o usuário ainda pode ser alvo de ataques mais sofisticados, como MFA fatigue, AiTM, exploração de PRT, abusos de OAuth, entre outros.
O que é phishing AiTM?
O phishing do tipo Adversary-in-the-Middle (AiTM) não é uma técnica nova; ele vem sendo utilizado há alguns anos e permanece entre os métodos mais eficazes de ataque. Embora a MFA adicione uma camada importante de proteção contra o roubo de credenciais, os invasores continuam encontrando formas de contornar essa defesa adicional.
No phishing tradicional, o site falso apenas coleta usuário e senha, sem concluir o processo de autenticação. Assim, quando a conta exige MFA, o atacante não consegue prosseguir mesmo com as credenciais roubadas. Já no modelo AiTM, o atacante atua como um intermediário entre a vítima e o serviço legítimo, permitindo que todo o fluxo de autenticação — incluindo MFA — seja concluído. Com isso, o invasor captura não apenas as credenciais, mas também o token de sessão, que é o verdadeiro alvo.
A técnica funciona por meio de um proxy: o kit AiTM intercepta e repassa as requisições entre o usuário e o site real. Como os serviços modernos utilizam cookies de sessão após a autenticação, o atacante consegue replicar essa sessão sem precisar refazer o login.
Visualmente, o site falso é idêntico ao portal da Microsoft; a única diferença perceptível é o endereço na barra de URL — ponto onde muitos usuários não prestam atenção.
A imagem abaixo demonstra o processo do ataquei AiTM (creditos: Microsoft)
Kits AiTM por grupos APT
Atualmente, alguns grupos de Ameaça Persistente Avançada (APT) não apenas realizam ataques diretamente, mas também oferecem infraestrutura e kits AiTM como um serviço para terceiros.
Esse modelo “phishing-as-a-service” (PhaaS) representa uma industrialização do crime cibernético: atores mais sofisticados desenvolvem, mantêm e vendem ou alugam kits que qualquer criminoso pode usar para lançar campanhas de phishing de alta escala.
Essa prática reduz o nível técnico necessário para realizar ataques sofisticados e democratiza o acesso a ferramentas poderosas — permitindo que tanto atores individuais quanto grupos menos habilidosos executem ataques AiTM sem precisar codificar suas próprias soluções.
Qilin (DEV-0253 / Storm-0253) — AiTM como etapa inicial de ataques mais complexos
O Qilin, também rastreado pela Microsoft como Storm-0253, é um grupo cibercriminoso que opera um modelo “as-a-service” voltado para extorsão e ransomware. Esse ator utiliza campanhas de phishing com kits AiTM como primeira etapa, com o objetivo de capturar cookies de sessão e comprometer contas corporativas de maneira silenciosa.
Assim como outros grupos avançados, o Qilin fornece infraestrutura e ferramentas para terceiros (afiliados), incluindo:
🔹 kits AiTM baseados em proxy reverso capazes de interceptar MFA;
🔹 automação para coleta de credenciais e sessões válidas de Microsoft 365;
🔹 suporte técnico e canais exclusivos para os “parceiros” da operação.
O grupo evoluiu suas táticas para priorizar:
🔹 disfarce de páginas maliciosas com alta fidelidade visual (imitando login corporativo);
🔹 acessos laterais após autenticação bem-sucedida com sessão roubada;
🔹 elevação de privilégio para atingir serviços críticos (ex.: e-mail, SharePoint, OneDrive).
Após o comprometimento inicial por AiTM, afiliados do Qilin frequentemente implantam ferramentas adicionais para movimento lateral, coleta de dados sensíveis e posterior dupla extorsão via ransomware.
Esse cenário reforça que mesmo um ataque de phishing aparentemente simples pode evoluir rapidamente para incidentes graves envolvendo perda de dados, sequestro de ambiente e impactos financeiros significativos para a organização
Evilginx
Para fins de teste, configurei o Evilginx em um servidor Debian 12 simples e configurei o domínio: login.mysignins-office365.com.
Após a configuração do IP e do domínio, podemos configurar e habilitar os phishlets. Como a versão 3.0 não inclui nenhum phishlet pré-criado, modifiquei os phishlets do Office 365 com alguns pequenos ajustes para que funcionassem com a versão 3.0.
Com os comandos, os phishlets foram habilitados no domínio login.mysignins-office365.com e o phishlet foi ativado.
Com o comando lures get-url, é possível obter o link URL completo:
Página de login:
A página de login utiliza o estilo padrão do login.microsoftonline.com. Ao fazer login com as credenciais do cliente, a identidade visual do locatário do cliente é aplicada, o que torna o conhecimento da identidade visual do cliente inútil para os recursos de prevenção.
Estilo padrão da Microsoft:
⚠️ Um dos sinais mais evidentes de que um ataque está em andamento é o domínio utilizado na tentativa de autenticação. No caso analisado, o endereço login.mysignins-office365.com é claramente suspeito. O domínio legítimo utilizado pela Microsoft para processos de login é o login.microsoftonline.com. Qualquer variação fora desse padrão deve ser tratada como potencial phishing.
Após informar o e-mail, é apresentado a tela de login personalizado de sua empresa:
Proteções/mitigações contra phishing do AiTM
Com a crescente implementação/adoção da autenticação multifator (MFA), espera-se que o phishing direcionado a dispositivos móveis (AiTM) aumente nos próximos anos (devido ao uso de novas técnicas pelos atacantes). Medidas adicionais de mitigação contra o phishing direcionado a dispositivos móveis são importantes.
A proteção/mitigação é possível com base em diversas configurações:
🔹 Soluções de MFA resistentes a phishing (autenticação baseada em FIDO/certificado)
🔹 Proteja-se contra ataques usando Acesso Condicional.
🔹 Monitoramento/proteção usando o Microsoft Defender/Entra ID Identity Protection
Vamos começar com uma visão geral baseada em soluções resistentes a phishing, métodos de autenticação de dois fatores (2FA) e multifator (MFA) protegidos, a parte de proteção do Acesso Condicional e os produtos/recursos de segurança da Microsoft. Qual recurso/configuração protege contra o AiTM?
Soluções de MFA resistentes a phishing (autenticação baseada em FIDO/certificado)
A Microsoft oferece uma ampla gama de opções para o método de autenticação principal; atualmente, os seguintes métodos estão disponíveis:
🔹 FIDO2 security keys
🔹 Windows Hello for Business
🔹 Certificate-based authentication
🔹 Passwordless phone sign-in
🔹 Phone number and SMS
🔹 Username and password
O Acesso Condicional permite proteger as contas de maneira muito mais completa contra ataques, incluindo AiTM. Quando essa camada extra não está configurada, alguns métodos de autenticação acabam ficando desprotegidos enquanto outros oferecem proteção. Em outras palavras, sem políticas de Acesso Condicional aplicadas, os métodos que o usuário usa para se autenticar podem ou não estar protegidos contra AiTM — e essa diferença é exatamente o que deixa brechas para que o atacante consiga capturar tokens mesmo após a MFA ter sido aprovada.
| Método (autenticação principal) | Proteção contra AiTM |
| FIDO2 security keys | Protege |
| Windows Hello for Business | Protege |
| Certificate-based authentication | Protege |
| Passwordless phone sign-in | Não protege |
| Phone number and SMS | Não protege |
| Username and password | Não protege |
Somente FIDO2, Windows Hello for Business e autenticação baseada em certificado oferecem proteção real contra ataques de AiTM. Já o uso de usuário e senha pode até ganhar uma camada extra de segurança por meio do Acesso Condicional, mas, na prática, o acesso só é bloqueado porque as políticas restringem a sessão — não porque essas credenciais por si só sejam resistentes ao ataque.
No caso do Windows 11, o Windows Hello for Business combinado ao TPM funciona como um autenticador certificado pelo padrão FIDO2. Isso significa que você não precisa de nenhum hardware adicional para usar uma autenticação realmente resistente a phishing, seguindo os padrões mais fortes adotados pelo mercado.
Métodos de autenticação de dois fatores/autenticação multifator protegidos
Ao analisar os diferentes métodos de autenticação de dois fatores (2FA) e autenticação multifator (MFA), destaca-se a proteção contra ataques AiTM, além dos métodos que não exigem senha.
| Método (MFA secundário) | Proteção contra AiTM |
| SMS | Não protege |
| Phone-call | Não protege |
| Microsoft Authentication App | Não protege |
| Microsoft Authentication App + Number matching | Não protege |
| Microsoft Authentication App + Additional context | Não protege |
| Microsoft Authentication App + Number matching + additional context | Não protege |
Acesso condicional protegido e controles adicionais
A resposta é simples: não há proteção apenas com autenticação de dois fatores (2FA) ou autenticação multifator (MFA); a proteção só existe quando reforçada com controles de acesso condicional adicionais. Os seguintes controles de acesso condicional oferecem proteção contra ataques de AiTM.
| Método | Proteção contra AiTM |
| Exigir que o dispositivo seja marcado como estando em conformidade. | Protege |
| Exigir que o dispositivo seja marcado como ingresso híbrido Microsoft Entra. | Protege |
| Controles de sessão de acesso condicional | limitar o período de tempo de uso de cookie de sessão |
| Acesso condicional a locais confiáveis | O agente de ameaça pode logar em locais confiáveis |
| Entra Global Secure Access | Não protege |
Informações adicionais
O Entra ID e os serviços adicionais de proteção dentro do ecossistema Microsoft Security não oferecem uma defesa direta contra ataques de AiTM. Isso fica ainda mais evidente com ferramentas como o Evilginx3, que já suporta customização completa de tenant branding, permitindo ao atacante copiar integralmente a aparência do site original. Embora esses produtos não impeçam o roubo inicial do token, eles ajudam a mitigar o impacto do ataque. As funcionalidades de Attack Disruption atuam reduzindo o risco de danos maiores no ambiente, interrompendo atividades maliciosas antes que o atacante consiga avançar ainda mais.
| Método | Proteção contra AiTM |
| Identidade visual | Não protege. |
| EntraID Identity Protection | Bloqueios de usuários baseado em risco |
| Microsoft Defender for Endpoint | Alerta bloqueios de sites AiTM conhecidos |
| Microsoft Defender SmartScreen | Bloqueio de sites conhecidos de AiTM |
Revogar sessão e inscrição no MFA
A revogação de sessão e do registro de MFA é essencial após a identificação de um ataque. É possível encerrar todas as sessões ativas diretamente pelo Azure, Entra ou Defender XDR, e ao fazer isso o invasor deixa de conseguir usar o cookie já roubado por meio do ataque de phishing.
Depois de revogar as sessões, é fundamental verificar se novas opções de autenticação foram adicionadas de forma suspeita e, em seguida, alterar a senha imediatamente. Em muitos casos, os atacantes registram novos dispositivos durante o processo de comprometimento, criando um “dispositivo confiável” para facilitar futuros acessos não autorizados.
Revogar a sessão remove a autenticação atual; NÃO é uma medida preventiva após uma tentativa. Sempre execute etapas adicionais durante a análise. E se os invasores registrarem outros métodos de MFA?
O invasor pode facilmente acessar aka.ms/mysecurityinfo e registrar uma chave de segurança FIDO2 como um novo método. Na próxima vez, o invasor poderá usar a chave de segurança FIDO2, que é considerada um método forte. Sempre verifique se novos fatores de autenticação foram registrados para o usuário específico durante o período analisado.
Proteção de token
Esse recurso busca reduzir ataques baseados em roubo de token, garantindo que o token só possa ser utilizado a partir do dispositivo para o qual foi emitido. A proteção cria uma vinculação criptograficamente segura entre o token e o dispositivo. Sem o segredo do cliente, o token vinculado torna-se totalmente inútil para qualquer invasor.
| Método | Proteção contra AiTM |
| Proteção por token para o aplicativo Outlook | Protege |
| Proteção de tokens para Exchange Online | Protege |
| Proteção de token para SharePoint Online | Protege |
Proteção de token no Acesso Condicional do Microsoft Entra
A Proteção de Token é um controle de sessão de Acesso Condicional que tenta reduzir os ataques de reprodução de token, garantindo que apenas tokens de sessão de entrada associados ao dispositivo, como PRTs (Tokens de Atualização Primária), sejam aceitos pela ID do Entra quando os aplicativos solicitam acesso aos recursos protegidos.
Referências
🔹 Appel, J. (2023). AiTM MFA phishing attacks in combination with new Microsoft protections (2023 edt.)
🔹 Microsoft. Revoke user access in Microsoft Entra ID
Microsoft. Conditional Access – Token Protection
🔹 Microsoft. Automatic attack disruption in Microsoft Defender
🔹 Microsoft. Configure Microsoft Defender for Identity – Action Accounts.
🔹 Microsoft. Detecting and mitigating a multi-stage AiTM phishing and BEC campaign
🔹 Sekoia io. Exposing a new AiTM Phishing-as-a-Service
