Home Comunidade Eventos YouTube Networks Desafios // produtos Academy News CTI | CVE Contato

07 - URLs, Redirecionamentos e Kits de Phishing

video explicativo
Video explicativoEspaco reservado para o video desta anotação — adicione video: https://youtu.be/... no frontmatter da nota.

URLs, Redirecionamentos e Kits de Phishing

Nota 07 do capítulo 25, que persegue o destino dos links entregues pelas mensagens analisadas na nota 06.
O foco é a anatomia de URLs de phishing, o rastreio de cadeias de redirecionamento com curl e a caracterização de kits e de infraestrutura.
Dialoga com as notas 06 e 08 deste capítulo, com a análise de infraestrutura do capítulo 03 e com a nota 14 do capítulo 08 (DNS, HTTP e TLS).

1. Contexto e Posicionamento na Biblioteca

O link é o elo entre a mensagem da nota 06 e o alvo real da campanha, e raramente aponta para onde parece apontar. Encurtadores, redirecionamentos abertos e sistemas de direcionamento de tráfego formam uma cadeia que esconde a infraestrutura final, mede os cliques e filtra vítimas, e o analista precisa ser capaz de percorrer essa cadeia documentando cada salto. A habilidade é central no trabalho de CTI porque o destino do link entrega a parte mais rica da infraestrutura da campanha: o kit de phishing, o host, o certificado e os domínios satélites.

Esta nota cobre a anatomia da URL, a mecânica das cadeias de redirecionamento, os kits de phishing vendidos como serviço e a infraestrutura típica que os sustenta. A nota 08 usa a mesma mensagem quando a fraude dispensa link, e o capítulo 03 fornece as técnicas de WHOIS, DNS passivo e Certificate Transparency que aqui aparecem aplicadas a um caso concreto. Todo o conteúdo é defensivo: o objetivo é rastrear, documentar e permitir bloqueio, jamais operar a infraestrutura do atacante.

2. Anatomia de uma URL de Phishing

Uma URL tem componentes com papéis claros: esquema, subdomínio, domínio, TLD, caminho e parâmetros de consulta. O phishing explora cada componente de forma específica, porque o usuário médio lê da esquerda para a direita e fixa a atenção no que aparece primeiro, justamente o trecho que o atacante mais controla. A tabela abaixo resume as trapaças mais frequentes por componente, com exemplos fictícios construídos sobre a marca Bancosolar.

Componente Uso legítimo Trapaça comum Exemplo fictício
Esquema https com TLS válido Esquema http simples para reduzir custo de operação http:// em página de login
Subdomínio Serviço real da organização Marca da vítima plantada no subdomínio próprio do atacante bancosolar.secure-login-portal.example
Domínio Identidade registrada da marca Homoglifo, troca de letra, punycode banc0solar.com; xn--bancosolar-ltb.example
TLD Extensão institucional TLDs baratos, novos e sem reputação .top, .xyz, .icu, .cfd
Caminho Rota real do aplicativo Imitação fiel do portal da vítima /internetbanking/login.php
Consulta Parâmetros de aplicação IDs de rastreamento da campanha e dados do alvo ?id=9182&camp=ln-br-jan26

Duas observações elevam a qualidade da leitura. Primeiro, a identidade real da URL é o domínio imediatamente à esquerda do primeiro TLD, e não o começo da string; treinar os usuários com essa regra vale mais do que listas de exemplos. Segundo, os parâmetros de consulta frequentemente carregam identificadores de destinatário codificados pelo atacante, e decodificá-los revela o público da campanha e permite estimar o escopo antes que os relatórios de usuário cheguem.

O protocolo de leitura rápida abaixo consolida as verificações que a triagem executa antes de qualquer ferramenta, e todas levam segundos.

  • Ler a URL da direita para a esquerda até o domínio real, ignorando a isca do subdomínio.
  • Conferir o esquema e a presença de TLS, registrando a inconsistência com o tipo de transação proposto.
  • Decodificar punycode e examinar homoglifos, trocas de letra e TLDs alternativos.
  • Expandir encurtadores com consulta de cabeçalho apenas, sem carregar o destino na rede corporativa.
  • Decodificar parâmetros de consulta em busca de identificadores de campanha e de destinatário.
  • Ler a URL da direita para a esquerda até o domínio real, ignorando a isca do subdomínio.
  • Conferir o esquema e a presença de TLS, registrando a inconsistência com o tipo de transação proposto.
  • Decodificar punycode e examinar homoglifos, trocas de letra e TLDs alternativos.
  • Expandir encurtadores com consulta de cabeçalho apenas, sem carregar o destino na rede corporativa.
  • Decodificar parâmetros de consulta em busca de identificadores de campanha e de destinatário.

3. Cadeias de Redirecionamento: Encurtadores, Open Redirects e TDS

A cadeia de redirecionamento existe por três motivos complementares. O encurtador mede cliques e disfarça o destino em mensagens de SMS e redes sociais; o open redirect explora um parâmetro não validado em um site legítimo de boa reputação, transformando o site em degrau da escada; e o Traffic Direction System, ou TDS, é o filtro do atacante, que recebe o clique, consulta geolocalização, user-agent, referrer e listas de sandboxes conhecidas, e decide se entrega o kit, exibe página branca ou encaminha o tráfego para outro cliente. É a mecânica do TDS que explica o fenômeno mais frustrante da análise: a URL que abriu na máquina da vítima aparece morta no laboratório do analista horas depois.

A tabela abaixo resume os mecanismos que compõem cadeias reais, com o comportamento HTTP observável e o ajuste de rastreio adequado a cada um.

Mecanismo Comportamento HTTP observável Ajuste de rastreio
Encurtador 301 ou 302 com Location imediato Repetir a consulta para medir variação de destino
Open redirect 302 em domínio legítimo com parâmetro de destino Reportar ao dono do site e documentar o parâmetro
TDS 302 condicional ou página branca com 200 Ajustar user-agent, geografia e referrer
Meta refresh HTML com tag meta http-equiv Capturar o corpo, não apenas cabeçalhos
Redirecionamento em JavaScript Página que escreve location no DOM Análise do corpo em sandbox de navegador
Cloaking 200 com conteúdo neutro para o coletor Comparar respostas entre contextos e registrar diferenças

A resposta profissional é imitar o contexto da vítima o mais fielmente possível durante o rastreio, registrando cada salto com os cabeçalhos completos. A cadeia documentada tem valor de inteligência porque cada degrau pertence a um dono diferente: o encurtador é público, o open redirect é vulnerabilidade de terceiros que deve ser reportada, e os últimos saltos são infraestrutura do atacante que alimentam bloqueio e takedown.

4. Rastreando Cadeias com curl: Método e Higiene Operacional

O curl é a ferramenta padrão do rastreio porque segue redirecionamentos, aceita user-agent arbitrário, pinça resolução de DNS e entrega cabeçalhos puros sem renderizar conteúdo. O método abaixo cobre o fluxo completo, e todos os comandos devem rodar a partir de infraestrutura de análise isolada da rede corporativa, nunca da estação de trabalho do analista.

# 1. Cadeia completa com corpo descartado, imitando o navegador da população alvo
curl -s -L -o /dev/null \
  -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36" \
  -w "salto %{num_redirects}: %{http_code} %{url_effective}\n" \
  "https://encurtador-xyz.example/9Fk2q"

# 2. Cabeçalhos de cada salto, sem baixar corpos, para documentar Location e Set-Cookie
curl -sIL -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/126.0.0.0" \
  "https://encurtador-xyz.example/9Fk2q" | grep -iE "^(HTTP|location|set-cookie)"

# 3. Confirmação do host final com resolução pinada no IP investigado
curl -sIL --resolve "login-bancosolar.example:443:185.199.110.153" \
  "https://login-bancosolar.example/painel/login.php" | head -n 12

# 4. Corpo da página final coletado somente em ambiente isolado, para extração de artefatos
curl -s -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/126.0.0.0" \
  "https://login-bancosolar.example/painel/login.php" -o /tmp/kit-final.html

A higiene operacional tem regras inegociáveis. Nenhum dado de credencial é submetido em página nenhuma, mesmo para "testar" o kit, porque a captura é registrada e o teste adiciona risco sem evidência nova. O user-agent e a geografia de saída devem imitar a população alvo, pois o TDS entrega página branca para contextos que não combinam com o alvo. Cada coleta é registrada com carimbo de tempo, URL de origem, IP de saída e hash do corpo baixado, preservando a cadeia de evidência para o relatório.

5. Kits de Phishing e Phishing-as-a-Service

O mercado criminoso industrializou a criação de páginas de captura, e o analista precisa reconhecer as famílias de kit pelo comportamento observado, não apenas pela página. Três arquiteturas dominam as campanhas atuais, e a diferença entre elas define qual sinal de caça é relevante.

Kit ou serviço Mecânica Capacidade de MFA Sinais característicos
Ecstasy (Phish) Página de captura com painel de administração, envio SMTP integrado e templates por instituição Não; captura credencial simples Painel de administração exposto, múltiplos templates no mesmo host, keylogger embutido opcional
Evilginx e EvilProxy Proxy reverso do tipo AiTM entre a vítima e o portal real Sim; captura cookie e token após MFA concluído Domínio lookalike com certificado válido, formulário idêntico ao original, sessão exfiltrada em tempo real
EvilNoVNC Navegador real em contêiner com VNC, operado por humano Sim; o operador conclui o MFA com a vítima ao telefone Perfil de navegador consistente, latência humana nas interações, portas VNC ou RDP expostas no host

O proxy reverso merece atenção especial porque rompe a premissa de que MFA protege sozinho: a vítima faz login no portal real através do proxy do atacante, a autenticação de segundo fator acontece de verdade, e o proxy guarda o cookie de sessão resultante para reuso posterior. O tema é aprofundado na nota 04 do capítulo 26, que trata de tokens e sessões, e o e-mail que entrega o link deste tipo de kit costuma citar o "cancelamento" de uma reunião ou a "atualização" de um documento para induzir o login imediato.

A caracterização de kits também tem assinaturas técnicas: caminhos padronizados de landing e de captura, bibliotecas de front-end reutilizadas entre templates, endpoints de painel de administração expostos e mensagens de erro próprias do framework do kit. O inventário dessas assinaturas, mantido pela equipe, transforma a coleta da seção 4 em classificação automática do kit observado. A mesma lista alimenta regras de detecção em proxy e em gateway web, permitindo bloquear variações da família antes que o tema da isca mude.

6. Infraestrutura Típica: Hosting, Domínios Lookalike e Certificados

A infraestrutura dos kits segue um padrão econômico bastante estável. O hosting é de VPS barato ou de provedores com política laxa de abuso; o domínio é registrado dias antes do pico da campanha, com dados de contato protegidos por privacy proxy; e o certificado TLS é emitido gratuitamente via Let's Encrypt, o que coloca a campanha na lista pública de Certificate Transparency no momento da emissão. Essa previsibilidade é a fraqueza do atacante: o certificado precisa existir antes da isca, e o registro de CT entrega o domínio antes do primeiro clique.

Característica Padrão observado Uso no hunting
Idade do domínio Menos de 7 dias no pico da campanha Filtro de novos registros sobre marca monitorada
TLD .top, .xyz, .icu e similares Priorização de revisão de lookalikes
Certificado Let's Encrypt emitido até 48 horas antes do envio Consulta periódica em CT logs por marca e por nomes de login
Hosting VPS de provedores com abuso crônico ASN e blocos IP recorrentes entre campanhas
Arquitetura Painel do kit e páginas de captura no mesmo host Scanner de superfície para painéis e endpoints de API

A consulta abaixo exemplifica o rastreio por Certificate Transparency, buscando subdomínios emitidos para um domínio de campanha identificado na seção 7. O resultado alimenta a lista de bloqueio, o alerta de variações futuras do mesmo padrão e o processo de takedown junto ao provedor.

curl -s "https://crt.sh/?q=%25.bancosolar-login.example&output=json" \
  | jq -r '.[] | .common_name + " " + .not_before' | sort -u

Os gatilhos de caça abaixo operacionalizam a tabela em rotina diária da equipe, e cada um deles usa apenas fontes públicas.

  • Monitorar novos registros que imitem marcas internas e de fornecedores críticos, com revisão diária de fila curta.
  • Consultar periodicamente os logs de CT por subdomínios emitidos com padrões de campanha, como login, painel e verificação.
  • Acompanhar ASN com histórico crônico de abuso, cruzando com campanhas anteriores registradas no TIP.
  • Alertar sobre certificados emitidos para domínios registrados há menos de sete dias com marca da organização.

7. Exemplo Prático: Rastreio Documentado de uma Cadeia

Uma mensagem denúncia trouxe o link do encurtador da seção 4, enviado a 214 funcionários do setor financeiro com o tema "segunda via do comprovante de rendimentos". O rastreio documentou quatro saltos, resumidos na tabela abaixo, e o corpo final foi coletado em ambiente isolado para extração de artefatos.

Salto URL Mecanismo O que revela
0 https://encurtador-xyz.example/9Fk2q Encurtador público Alvo real no Location e métrica de clique do atacante
1 https://www.revista-financeira.example/out?u=b2FsdG8 Open redirect Parâmetro u sem validação em site legítimo, que empresta reputação
2 https://tds-gate.example/verify.php?camp=ln-br-jan26 TDS Filtra geografia e user-agent; carimbo de campanha no parâmetro
3 https://login-bancosolar.example/painel/login.php Kit de phishing Espelho do portal bancário, captura de credencial e segunda etapa de MFA

A leitura da cadeia entrega três produtos imediatos. O parâmetro camp=ln-br-jan26 nomeia a campanha e permite buscar variações futuras do mesmo identificador em novas mensagens. O open redirect da revista deve ser reportado ao responsável do site, quebra o degrau de reputação e reduz o alcance da campanha em reenvios. O host final entrega os IOCs de bloqueio, o certificado da seção 6 entrega os domínios satélites, e o conjunto vai para o agrupamento de campanhas do capítulo 05 com o identificador da campanha já atribuído.

8. Erros Comuns e Pontos de Atenção

O erro mais perigoso é rastrear a partir da rede corporativa ou da estação de trabalho do analista: o clique sai do IP da empresa, o TDS registra o interesse e a organização entra na lista de alvos validados. O erro mais frequente é concluir que a URL está morta porque o laboratório recebeu página branca, quando na verdade o TDS apenas recusou o contexto de coleta. Ambos se resolvem com a mesma disciplina de método documentada na seção 4.

Completam a lista os itens abaixo.

  • Usar apenas requisições HEAD no rastreio inteiro, perdendo conteúdo e comportamentos que só aparecem em GET.
  • Ignorar o user-agent na coleta, recebendo variações do kit que não refletem a experiência real da vítima.
  • Não registrar hashes e carimbos de tempo das coletas, perdendo a cadeia de evidência do caso.
  • Submeter credenciais fictícias "para testar", adicionando risco operacional e sem gerar evidência que o corpo da página já não entregue.
  • Tratar domínio lookalike como IOC efêmero, sem registrar o padrão de geração que liga as variantes entre campanhas.
  • Esquecer de reportar open redirects a terceiros, mantendo ativo o degrau de reputação da cadeia.
  • Tratar a coleta do corpo como etapa opcional, deixando de extrair os artefatos do kit que sustentam a classificação da família.

9. Integração com o Restante da Biblioteca

Os indicadores coletados aqui, domínios, IPs, certificados e identificadores de campanha, alimentam a gestão de IOCs do capítulo 03, com atenção especial à pirâmide de dor: bloquear o host resolve a campanha atual, enquanto reconhecer o padrão de geração de domínios antecipa a próxima. A nota 08 complementa a trilogia tratando o caso sem link, e a nota 15 do capítulo 08 transforma os padrões desta nota em caça proativa sobre telemetria de e-mail e proxy. A nota 04 do capítulo 22 detalha certificados e CT logs em profundidade, e o documento de campanha da nota 09 recebe desta análise a narrativa de infraestrutura que sustenta o relatório tático.