Desmascarando o Dono do Domínio: Vencendo a Privacidade WHOIS com Metadados de Repositório
O desafio
O domínio nimbus-labs.example esconde seu dono atrás da privacidade WHOIS. Abra as fontes e correlacione-as: o WHOIS está oculto, mas a empresa publica um repositório de código cujos commits trazem um e-mail de autor. Encontre o endereço de e-mail que de fato registrou o domínio e envie-o.
O que você vai aprender
- Reconhecer que a privacidade WHOIS mascara apenas o registro de cadastro, não outros artefatos
- Ler o e-mail de autor e assinatura de um commit git como sinal de atribuição
- Correlacionar o e-mail operacional de um repositório com a infraestrutura DNS do domínio
- Distinguir uma caixa de entrada pública (hello@, jobs@) do dono operacional
- Construir um caso de atribuição a partir de múltiplos sinais fracos, em vez de uma única fonte
Habilidades testadas
Pré-requisitos
- Entendimento básico de registros WHOIS e DNS
- Familiaridade com commits git e metadados de autor
Como funciona
Serviços de privacidade WHOIS substituem o nome real, endereço e e-mail do titular por um contato proxy, então um registro censurado quase nada revela sobre quem é o dono de um domínio. A atribuição então se torna um exercício de encontrar a mesma entidade expressa em um lugar que ela não conseguiu censurar. Metadados operacionais são o vazamento usual: desenvolvedores, sistemas de CI e infraestrutura carimbam sua identidade em artefatos que o serviço de privacidade nunca toca.
Aqui o vazamento é o próprio repositório público da empresa. Todo commit em nimbus-labs/edge-proxy tem como autor [email protected] e é assinado com GPG pelo mesmo endereço. Essa caixa de entrada não é coincidência: a mensagem do commit e o SOA do DNS apontam para os mesmos servidores de nomes da Cloudflare, então a pessoa que faz commits de mudanças de infraestrutura é a mesma que opera o domínio. As caixas de carreiras e geral na página do LinkedIn são iscas deliberadas - são apelidos públicos, não o dono operacional.
O quadro de OSINT te dá cada artefato como um cartão. Nenhum cartão isolado nomeia o titular: o WHOIS está censurado, o DNS é só registros, o LinkedIn lista caixas de entrada genéricas. A resposta surge quando o e-mail de autor do git se alinha com a infraestrutura DNS, apontando para uma única caixa operacional - [email protected].
Erros comuns
- Enviar o e-mail proxy do WHOIS.
[email protected]é o endereço do serviço de privacidade, não do dono. - Escolher a caixa geral ou de carreiras do LinkedIn.
hello@ejobs@são apelidos públicos, não o dono operacional do domínio. - Parar no WHOIS censurado. A privacidade mascara um registro; é preciso pivotar para um artefato que o serviço não tocou.
- Ignorar a ligação entre DNS e repositório. A correspondência entre a mudança da Cloudflare no commit e os servidores de nomes do SOA é o que confirma o e-mail.
Como se proteger
Se você não quer que a titularidade do seu domínio seja trivialmente atribuível, trate os metadados operacionais como parte da sua superfície de ataque, junto com o WHOIS. O serviço de privacidade protege apenas um registro; tudo que você publica deve ser revisado para evitar que a mesma identidade vaze de volta.
- Use um e-mail de autor e uma chave de assinatura dedicados e não identificáveis para commits públicos, não uma caixa vinculada às operações do domínio.
- Audite repositórios públicos em busca de e-mails de committers antes de abrir o código, e limpe o histórico se necessário.
- Mantenha as identidades de gerenciamento de infraestrutura separadas de qualquer coisa publicada ou pesquisável.
- Lembre-se que a privacidade do registrador sozinha não é anonimato - presuma correlação entre todos os seus artefatos públicos.