Phishing moderno: anatomia, kits e defesa
Como kits AiTM (Evilginx, Modlishka) contornam MFA por session-hijacking, e o que realmente bloqueia — FIDO2, conditional access, DMARC estrito.
🎧 audiobook · nível 1
Phishing moderno: anatomia, kits e defesa
O salto de qualidade: AiTM
Phishing tradicional copia uma página de login. AiTM (Adversary-in-the-Middle) faz proxy reverso transparente: o usuário fala com o site real através do servidor do atacante, que captura o cookie de sessão DEPOIS do MFA. TOTP e push não protegem — o cookie já está autenticado.
Etapas de uma campanha (visão defensiva)
- Aquisição de domínio similar (typosquatting, IDN, TLD barato).
- Cert TLS via Let's Encrypt — visualmente idêntico ao real.
- Deploy de Evilginx/Modlishka com phishlet do alvo.
- Envio: email com pretexto (RH, fatura, MFA reset) ou SMS.
- Vítima loga, MFA passa, cookie é exfiltrado e usado pelo atacante.
- Persistência: criar app password, registrar dispositivo MFA do atacante.
O que REALMENTE bloqueia AiTM
FIDO2/WebAuthn (passkeys com bind ao origin), Conditional Access exigindo dispositivo gerenciado, e detecção de impossible travel + new device. TOTP/push isolados não bastam.
Sinais de detecção
- Login bem-sucedido seguido em segundos por registro de novo MFA.
- User-Agent inconsistente entre auth e primeira ação.
- ASNs de hospedagem (DigitalOcean, OVH) em logins corporativos.
- DMARC/DKIM falhando em remetentes que imitam o domínio.
Higiene de email do lado do dono do domínio
; SPF restritivo
empresa.com. TXT "v=spf1 include:_spf.google.com -all"
; DKIM com seletor por provedor (configurado no painel)
; DMARC reject + relatório
_dmarc.empresa.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@empresa.com; adkim=s; aspf=s"Ferramentas relacionadas
Template OffSec · aplicar antes de rodar
Objetivo → Preparação → Execução → Evidência → Ética
Objetivo
Reconhecer padrões técnicos e psicológicos de phishing para treinar detecção e resposta — nunca para operar em terceiros sem autorização contratual (red team formal).
Pré-requisitos
- Contrato de red team ou treinamento interno assinado
- Domínio de teste registrado e isolado da marca real
- GoPhish/Evilginx2 rodando em VM dedicada
- Landing page e template revisados pelo jurídico
Passos
- Definir persona-alvo e vetor (e-mail, SMS, WhatsApp)
- Registrar domínio look-alike + certificado + SPF/DKIM
- Subir landing clone e servidor de captura em VPS isolada
- Disparar em wave pequena, medir CTR e credenciais capturadas
- Encerramento: destruir infraestrutura e entregar relatório com IoCs
Evidências a coletar
- Screenshots do e-mail e da landing enviados
- Log do servidor com timestamps de acesso (hash de credencial, não plaintext)
- Relatório com métricas agregadas — nunca dados individuais além do necessário
Regra prática: se você não guardou evidência reprodutível, o achado não existe.
Guia prático (lab autorizado)
alvo · GoPhish em Docker contra caixas de e-mail internas de treinamento
docker run -it -p 3333:3333 -p 8080:8080 gophish/gophish # painel: http://localhost:3333verificar · Toda credencial 'capturada' vira hash imediato (bcrypt) no log — nunca plaintext. Sem hash, o log é ilegal de guardar.
Checklist interativo
Checklist ético (marcar antes do primeiro comando)
Autorização, escopo, lab e proteção de dados. Sem 100%, não roda fora do lab.
Prática segura · Phishing
→ guia do labMonte um ambiente isolado antes de qualquer teste — use Docker (DVWA/juice-shop), uma VM host-only ou um alvo autorizado (HTB, TryHackMe, PortSwigger Academy).
Nunca aponte para alvo em produção. Se estiver no celular, use proot-distro + Debian para não sujar o Termux principal.