O MFA (autenticação multifator) virou sinônimo de segurança. Quase toda auditoria, checklist e política corporativa exige que ele esteja ativo. E está certo, ele precisa estar. O problema é que muitas equipes tratam o MFA como se fosse o fim da linha: “se tem MFA, estamos protegados”. Essa é exatamente a premissa que os atacantes exploram hoje. A realidade técnica é mais desconfortável: o MFA protege uma etapa do login, mas não protega a sessão que vem depois dele. E é na sessão que os ataques modernos ao Active Directory e ao Microsoft Entra ID acontecem.
Quando um usuário faz login, o sistema emite um token de sessão que autoriza o acesso por horas ou até dias. O MFA valida a identidade naquele momento, mas o token que ele gera circula pela rede e pode ser roubado, copiado e reutilizado. Um atacante que captura esse token não precisa da senha, não precisa do código do aplicativo autenticador, não precisa de nada. Ele só precisa do token. É por isso que técnicas como pass-the-cookie, token replay e phishing AITM (adversary-in-the-middle) vêm crescendo: elas não atacam a senha, atacam o que o MFA não cobre.
Este artigo desmonta essa falsa sensação de segurança e mostra, bloco a bloco, por que o MFA sozinho não protege o seu Active Directory, e o que você precisa fazer para proteger de verdade.
Para entender o buraco, é preciso entender o contrato do MFA. Ele prova que a pessoa que está digitando a senha também possui um segundo fator: um código do autenticador, uma notificação no celular, uma chave FIDO. Isso é forte contra roubo de senha, porque mesmo que a senha vaze, o atacante não tem o segundo fator.
Mas o MFA atua em um único ponto do tempo: o momento do login. Depois que a autenticação termina, o sistema entrega um token de sessão que carrega a autorização consigo. Esse token é o que permite ao usuário acessar e-mail, SharePoint, sistemas e o próprio Active Directory sem redigitar a senha a cada clique. O MFA não acompanha esse token, não o protege depois de emitido, e não sabe se quem está usando o token é o dono legítimo ou um invasor.
Em resumo: o MFA protege a porta de entrada. Ele não protege o corredor, as salas e os cofres que ficam depois da porta.
Se o token é o que vale depois do login, o atacante vai atrás do token. A técnica mais conhecida é o pass-the-cookie: roubar o cookie de sessão de um usuário já autenticado e reutilizá-lo de outro lugar. Como o cookie representa uma sessão que já passou pelo MFA, o invasor herda todo o acesso sem jamais passar pelo segundo fator.
Há também o token replay, em que o token roubado é “reapresentado” ao sistema como se fosse o usuário legítimo. O Microsoft DART (Detection and Response Team) documentou essas duas rotas como as mais comuns em roubo de token observado em clientes. O caso mais emblemático foi a sequência de comprometimentos envolvendo a Okta e a Cloudflare: em outubro de 2023 e novamente em 2024, atacantes usaram tokens de sessão roubados para acessar sistemas mesmo com MFA ativo. No incidente de outubro de 2024, o acesso foi feito por replay de um token de sessão de um usuário com MFA habilitado.
A lição é dura: o MFA não foi “quebrado”. Ele foi simplesmente ignorado, porque o atacante não precisou dele.
A forma mais sofisticada de explorar isso é o phishing AITM, feito por ferramentas como Evilginx e Tycoon 2FA. Diferente do phishing clássico, que rouba só a senha, o AITM coloca um proxy malicioso entre a vítima e o serviço legítimo.
O fluxo é o seguinte: o usuário recebe um e-mail ou é levado a uma página que é uma cópia fiel da tela de login real. Ele digita a senha, recebe o código do MFA e o digita também, achando que está tudo certo. Mas tudo isso passa pelo proxy do atacante, que captura as credenciais e, principalmente, o token de sessão emitido no final do login. Em segundos, o invasor reutiliza esse token do próprio ambiente, sem que o usuário perceba nada.
O ponto crítico é que o usuário completou o MFA com sucesso. Do ponto de vista do sistema, aquela foi uma autenticação legítima. O MFA fez o trabalho dele e mesmo assim o atacante entrou. É exatamente o cenário que a Microsoft vem alertando: o AITM não contorna o MFA, ele o usa a favor do atacante.
Além do roubo de token, existem ataques que atacam o próprio fator humano do MFA. O MFA fatigue (ou push bombing) consiste em disparar dezenas de notificações de aprovação no celular da vítima até que ela, cansada ou confusa, aceite uma delas por engano. Não exige nenhuma técnica avançada, apenas insistência.
Há também os vetores estruturais: refresh tokens de longa duração que ficam válidos por dias, contas de serviço e contas de sistema que não têm MFA (porque não têm como usá-lo), e integrações legadas que não suportam autenticação moderna. Cada um desses é uma porta que não depende do MFA do usuário final.
O Active Directory e o Entra ID são alvos especialmente sensíveis porque concentram o acesso a tudo: se o atacante entra com uma conta com privilégios, ele pode escalar para domínio, mover lateralmente e acessar o que quiser. E o MFA não impede nenhuma dessas etapas.
A resposta não é abandonar o MFA, é tratá-lo como uma camada entre várias. A proteção real contra esses ataques exige:
O MFA é indispensável, mas não é suficiente. Ele protege a senha, não a sessão, e os ataques modernos ao Active Directory e ao Microsoft Entra ID exploram exatamente essa lacuna. Se a sua estratégia de segurança se resume a “ativo o MFA e pronto”, você ainda está exposto a token replay, pass-the-cookie, phishing AITM e MFA fatigue.
A postura correta é tratar o MFA como uma camada dentro de uma defesa em profundidade: MFA resistente a phishing, Conditional Access, sessões curtas, dispositivos em conformidade e monitoramento de token. Só a combinação dessas camadas protege o que o MFA sozinho não consegue: o seu Active Directory.
Mais de 25 anos de experiência, atuando com foco em infraestrutura, segurança da informação e ambientes Microsoft.
contato@alcifell.com
