Doxxer le propriétaire d'un domaine : contourner la confidentialité WHOIS grâce aux métadonnées d'un dépôt
Le défi
Le domaine nimbus-labs.example cache son propriétaire derrière la confidentialité WHOIS. Ouvrez les sources et corrélez-les : le WHOIS est masqué, mais l'entreprise publie un dépôt de code dont les commits portent un e-mail d'auteur. Trouvez l'adresse e-mail qui a réellement enregistré le domaine et soumettez-la.
Ce que tu vas apprendre
- Comprendre que la confidentialité WHOIS ne masque que l'enregistrement, pas les autres artefacts
- Lire l'e-mail d'auteur et de signature d'un commit git comme un signal d'attribution
- Corréler l'e-mail opérationnel d'un dépôt avec l'infrastructure DNS du domaine
- Distinguer une boîte e-mail publique (hello@, jobs@) du propriétaire opérationnel
- Construire un dossier d'attribution à partir de plusieurs signaux faibles plutôt que d'une seule source
Compétences testées
Prérequis
- Compréhension de base des enregistrements WHOIS et DNS
- Familiarité avec les commits git et les métadonnées d'auteur
Comment ça marche
Les services de confidentialité WHOIS remplacent le nom réel, l'adresse et l'e-mail du titulaire par un contact proxy, si bien qu'un enregistrement masqué ne dit presque rien sur le propriétaire réel d'un domaine. L'attribution devient alors un exercice consistant à retrouver la même entité exprimée là où elle n'a pas pu être masquée. Les métadonnées opérationnelles constituent la fuite habituelle : développeurs, systèmes CI et infrastructure impriment tous leur identité dans des artefacts que le service de confidentialité ne touche jamais.
Ici, la fuite provient du dépôt public de l'entreprise elle-même. Chaque commit sur nimbus-labs/edge-proxy est créé par [email protected] et signé GPG par la même adresse. Cette boîte n'est pas une coïncidence : le message de commit et le SOA DNS pointent tous deux vers les mêmes serveurs de noms Cloudflare, donc la personne qui commit les changements d'infrastructure est celle qui opère le domaine. Les boîtes carrières et générales sur la page LinkedIn sont des leurres délibérés - ce sont des alias publics, pas le propriétaire opérationnel.
Le tableau OSINT vous donne chaque artefact sous forme de carte. Aucune carte ne nomme le titulaire à elle seule : le WHOIS est masqué, le DNS n'est que des enregistrements, LinkedIn liste des boîtes génériques. La réponse émerge quand l'e-mail d'auteur git s'aligne avec l'infrastructure DNS, pointant vers une seule boîte opérationnelle : [email protected].
Erreurs fréquentes
- Soumettre l'e-mail proxy du WHOIS.
[email protected]est l'adresse du service de confidentialité, pas celle du propriétaire. - Choisir la boîte générale ou carrières de LinkedIn.
hello@etjobs@sont des alias publics, pas le propriétaire opérationnel du domaine. - S'arrêter au WHOIS masqué. La confidentialité ne masque qu'un seul enregistrement ; il faut pivoter vers un artefact que le service n'a pas touché.
- Ignorer le lien entre le DNS et le dépôt. La correspondance entre le changement Cloudflare du commit et les serveurs de noms du SOA est ce qui confirme l'e-mail.
Comment s'en protéger
Si vous ne voulez pas que la propriété de votre domaine soit trivialement attribuable, traitez les métadonnées opérationnelles comme une composante de votre surface d'attaque au même titre que le WHOIS. Le service de confidentialité ne protège qu'un seul enregistrement ; tout ce que vous publiez doit être vérifié pour la même identité qui pourrait refaire surface.
- Utilisez un e-mail d'auteur et une clé de signature dédiés et non identifiants pour les commits publics, pas une boîte liée aux opérations du domaine.
- Auditez les dépôts publics pour repérer les e-mails des committeurs avant de les open-sourcer, et nettoyez l'historique si nécessaire.
- Gardez les identités de gestion d'infrastructure séparées de tout ce qui est publié ou indexable.
- Rappelez-vous que la confidentialité du bureau d'enregistrement seule n'est pas l'anonymat : supposez une corrélation possible entre tous vos artefacts publics.