Commencez par le domaine, pas par la page
L'infrastructure de phishing implique généralement plusieurs couches: le domaine dans le lien, le serveur qui héberge la page, le système de messagerie qui a livré l'appât et parfois un second domaine utilisé uniquement pour la collecte de justificatifs d'identité. Avant d'examiner le contenu de la page, collectez le domaine enregistrable, son enregistrement d'inscription RDAP, les réponses DNS et tous les certificats qui lui sont associés. Cela fournit un cadre de référence stable qui ne dépend pas de la page étant toujours en ligne.
Enregistrer la date de création, le registraire, les serveurs de noms et le statut actuel à partir du RDAP. Un domaine enregistré quelques jours avant le début de la campagne, utilisant un service de confidentialité et pointant vers des serveurs de noms sans rapport avec une marque légitime, est un schéma courant mais non universel. Traitez chacun de ces éléments comme un point de données plutôt que comme une preuve concluante.
Contexte de l'hébergement et du réseau
Résoudre le nom d'hôte en ses enregistrements A/AAAA et rechercher le détenteur du réseau pour chaque IP via le Registre Internet Régional pertinent (RDAP). Les kits de phishing sont fréquemment hébergés sur des serveurs légitimes compromis, des hébergements de masse à bas coût, ou derrière un réseau de diffusion de contenu qui masque l'origine. L'identification du véritable détenteur du réseau indique quel service d'abus peut concrètement faire retirer la page.
Lorsque le site se trouve derrière un CDN ou un proxy inverse, l'adresse IP visible appartient à ce fournisseur, et non à l'opérateur. Notez-le explicitement dans le rapport plutôt que de nommer le CDN comme l'hôte responsable du contenu.
Certificats et noms d'hôte associés
Les journaux de transparence des certificats, consultables via des services tels que crt.sh, enregistrent chaque certificat publiquement fiable émis pour un nom. La recherche du domaine de pointe et des préfixes courants peut révéler des noms d'hôte connexes tels que des sous-domaines de connexion, sécurisés, de messagerie ou de paiement qui ont été préparés pour la même campagne mais n'ont pas encore été liés par d'autres moyens. Le journal affiche également la date d'émission la plus ancienne, ce qui peut corroborer ou contredire la chronologie d'enregistrement.
Plusieurs domaines d'apparence non liée partageant le même modèle d'émission de certificat, le même registraire et le même jour d'enregistrement constituent une piste utile pour identifier une campagne plus vaste, mais une infrastructure partagée à elle seule n'établit pas une propriété commune.
Preuves de livraison de courriel
Si l'hameçonnage est arrivé par courriel, les en-têtes de message et la configuration MX, SPF et DMARC du domaine fournissent une ligne de preuve distincte. Un domaine avec des enregistrements MX configurés et une politique SPF/DMARC permissive ou absente est prêt à envoyer et recevoir des courriels, ce qui est pertinent lorsque la campagne inclut de l'ingénierie sociale basée sur les réponses plutôt qu'un simple lien.
Gardez le fichier email original intact. Les résultats d'authentification doivent être lus depuis votre propre infrastructure de réception fiable, et non recalculés après coup, car les enregistrements DNS peuvent changer après l'incident.
Élaboration du rapport
Un rapport utile sur l'infrastructure de phishing sépare ce qui a été observé (réponses DNS, champs RDAP, entrées de certificat, en-têtes d'e-mail) de ce qui est inféré (relations de campagne probables, intention probable). Chaque observation doit comporter sa source et un horodatage UTC. Scellez les preuves compilées avec un hachage cryptographique afin qu'elles puissent être ultérieurement prouvées comme étant inchangées, puis soumettez des rapports d'abus précis et étayés par des preuves à l'enregistreur, à l'hébergeur et à tout CDN impliqué.
- Domaine enregistrable, date de création RDAP, registraire et statut.
- DNS: A/AAAA, NS, MX, TXT, SOA avec horodatages de collecte.
- Détenteur du réseau IP pour chaque adresse résolue, en notant l'utilisation d'un CDN.
- Recherche de transparence des certificats pour le domaine et les sous-domaines courants.
- Position SPF/DMARC et, le cas échéant, e-mail original conservé.
- Rapport scellé et haché avant de soumettre les notifications d'abus.