← Todos os artigos

Phishing adversário no meio: como o EvilGinx derrota a MFA

GottaPhish Team · July 8, 2026

A autenticação multifator devia tornar inúteis as palavras-passe roubadas. O phishing de adversário no meio (AiTM) — popularizado por frameworks de código aberto como o EvilGinx — quebrou essa premissa em silêncio ao roubar a sessão, não a palavra-passe. Perceber como funciona é o primeiro passo para se defender.

O que é o phishing de adversário no meio

O phishing clássico mostra à vítima um clone estático de uma página de acesso e limita-se a registar o que ela escreve. Não consegue lidar com um código de uso único em direto nem passar um verdadeiro desafio de MFA.

O phishing AiTM elimina essa limitação inserindo um proxy inverso entre a vítima e o site genuíno. O servidor do atacante não aloja qualquer página falsa — retransmite a real:

Vítima → login.micros0ft-verify.example (proxy do atacante) → login.microsoftonline.com

Cada pedido da vítima é reencaminhado para o serviço legítimo e cada resposta devolvida. A vítima vê o fluxo de acesso autêntico — marca real, mensagens de erro reais, pedidos de MFA reais — porque, de facto, está a falar com o serviço real, apenas através de um relé que lê tudo em trânsito.

Porque derrota o OTP e o push

O ponto crucial é que o atacante não tenta conhecer a sua palavra-passe nem o seu código. Tenta capturar o que o acesso bem-sucedido produz: o cookie de sessão autenticado.

Nesse ponto o OTP já cumpriu a sua função e é inútil repeti-lo. O atacante importa o cookie roubado para o seu próprio navegador e fica autenticado como o utilizador — sem palavra-passe, sem código, sem segundo pedido. É por isto que os códigos SMS, as aplicações autenticadoras TOTP e as aprovações push caem todos perante uma montagem AiTM competente: cada um é um segredo partilhado que a pessoa pode ser enganada a retransmitir em tempo real.

O pedido de MFA que a vítima aprovou era genuíno. É precisamente isso que torna o AiTM tão eficaz — nada parece errado para o utilizador, e nada parece errado para o fornecedor de identidade.

Porque as defesas existentes tropeçam

A verdadeira solução: MFA resistente ao phishing

O AiTM funciona porque o segundo fator viaja através do atacante. Retire essa possibilidade e o ataque desmorona. FIDO2 / WebAuthn e as passkeys ligam a credencial criptograficamente à origem web exata para a qual foi registada:

Credencial registada para : https://login.microsoftonline.com
O navegador vê a origem   : https://login.micros0ft-verify.example
→ discrepância de origem → o autenticador recusa assinar → o acesso falha

Não há código para retransmitir nem cookie para colher, porque a autenticação nunca tem êxito contra a origem errada. É o navegador que o impõe — não o utilizador. Controlos complementares reforçam o resto:

O objetivo é a MFA resistente ao phishing como obrigatória, e não apenas disponível — qualquer recuo phishável é um caminho para o qual os atacantes encaminham os utilizadores.

Como a GottaPhish automatiza as simulações AiTM

Os ataques AiTM derrotam a MFA por OTP e push retransmitindo a sessão em tempo real, e nenhum proxy ou filtro por si só fecha essa lacuna de forma fiável. A GottaPhish e a sua equipa de especialistas reproduzem cenários de adversário no meio de forma automática e segura dentro de simulações autorizadas — não há infraestrutura de atacante que a sua equipa tenha de montar, alojar ou desmantelar. Demonstramos, com auditoria completa, como a MFA por OTP e push cai perante um proxy real enquanto as credenciais resistentes ao phishing aguentam, dando-lhe dados de exposição mensuráveis por utilizador, departamento e função; os nossos especialistas ajudam-no a desenhar os cenários, montar as campanhas e interpretar os resultados. Essa evidência concretiza o argumento de negócio para FIDO2/passkeys, e os nossos relatórios acompanham a adoção a par das suas taxas de clique e de comunicação, para que possa provar que a lacuna phishável está mesmo a fechar — e não apenas que existe uma política no papel.