Comece pelo domínio, não pela página
A infraestrutura de phishing geralmente envolve várias camadas: o domínio no link, o servidor que aloja a página, o sistema de e-mail que entregou a isca e, às vezes, um segundo domínio usado apenas para recolha de credenciais. Antes de examinar o conteúdo da página, recolha o domínio registrável, o seu registo RDAP, as respostas DNS e quaisquer certificados associados a ele. Isso fornece uma estrutura de referência estável que não depende da página ainda estar online.
Registar a data de criação, registador, servidores de nomes e estado atual do RDAP. Um domínio registado alguns dias antes do início da campanha, usando um serviço de privacidade e apontado para servidores de nomes não relacionados com qualquer marca legítima, é um padrão comum, mas não universal. Trate cada um destes como um ponto de dados, em vez de uma prova conclusiva.
Contexto de alojamento e rede
Resolver o nome do host para seus registros A/AAAA e consultar o titular da rede para cada IP através do Registro Regional da Internet relevante via RDAP. Kits de phishing são frequentemente hospedados em servidores legítimos comprometidos, hospedagem em massa barata ou atrás de uma rede de entrega de conteúdo que oculta a origem. Identificar o titular real da rede informa qual central de abuso pode realisticamente derrubar a página.
Onde o site está por trás de uma CDN ou proxy reverso, o IP visível pertence a esse provedor, não ao operador. Indique isso explicitamente no relatório em vez de nomear a CDN como o host responsável pelo conteúdo.
Certificados e nomes de host relacionados
Os registos de transparência de certificados, pesquisáveis através de serviços como crt.sh, registam cada certificado publicamente confiável emitido para um nome. Pesquisar o domínio apex e prefixos comuns pode revelar nomes de host relacionados, como subdomínios de login, seguro, e-mail ou pagamento, que foram preparados para a mesma campanha, mas ainda não foram ligados por outros meios. O registo também mostra a data de emissão mais antiga, que pode corroborar ou contradizer a linha do tempo de registro.
Múltiplos domínios de aparência não relacionada que partilham o mesmo padrão de emissão de certificado, o mesmo registador e o mesmo dia de registo é uma pista útil para identificar uma campanha mais ampla, mas a infraestrutura partilhada por si só não estabelece propriedade comum.
Evidência de entrega de e-mail
Se a isca de phishing chegou por e-mail, os cabeçalhos da mensagem e a configuração MX, SPF e DMARC do domínio fornecem uma linha de evidência separada. Um domínio com registos MX configurados e uma política SPF/DMARC permissiva ou ausente está pronto para enviar e receber e-mails, o que é relevante quando a campanha inclui engenharia social baseada em resposta, em vez de apenas um link.
Mantenha o ficheiro de e-mail original intacto. Os resultados da autenticação devem ser lidos da sua própria infraestrutura de receção fidedigna, não recalculados posteriormente, pois os registos DNS podem mudar após o incidente.
Preparando o relatório
Um relatório útil de infraestrutura de phishing separa o que foi observado (respostas DNS, campos RDAP, entradas de certificado, cabeçalhos de e-mail) do que é inferido (relações prováveis de campanha, intenção provável). Cada observação deve incluir a sua fonte e um carimbo de data/hora UTC. Sele a evidência compilada com um hash criptográfico para que possa ser posteriormente comprovado que não foi alterada, e depois submeta relatórios de abuso precisos e com base em evidências ao registador, ao host e a qualquer CDN envolvido.
- Domínio registrável, data de criação RDAP, registador e estado.
- DNS: A/AAAA, NS, MX, TXT, SOA com carimbos de data e hora de recolha.
- Titular da rede IP para cada endereço resolvido, observando o uso de CDN.
- Pesquisa de transparência de certificados para o domínio e subdomínios comuns.
- Postura de SPF/DMARC e, se aplicável, e-mail original preservado.
- Relatório selado e com hash antes de enviar avisos de abuso.