Dox the Domain Owner: Beating WHOIS Privacy with Repo Metadata
The challenge
The domain nimbus-labs.io hides its owner behind WHOIS privacy. Open the sources and correlate them: the WHOIS is redacted, but the company ships a public code repository whose commits carry an author email. Find the email address that actually registered the domain and submit it.
What you'll learn
- Recognise that WHOIS privacy masks only the registration record, not other artifacts
- Read a git commit's author and signing email as an attribution signal
- Correlate a repo's operational email with the domain's DNS infrastructure
- Distinguish a public-facing inbox (hello@, jobs@) from the operational owner
- Build an attribution case from multiple weak signals rather than one source
Skills tested
Prerequisites
- Basic understanding of WHOIS and DNS records
- Familiarity with git commits and author metadata
How it works
WHOIS privacy services replace the registrant's real name, address, and email with a proxy contact, so a redacted record tells you almost nothing about who owns a domain. Attribution then becomes an exercise in finding the same entity expressed in a place they could not redact. Operational metadata is the usual leak: developers, CI systems, and infrastructure all stamp their identity into artifacts that the privacy service never touches.
Here the leak is the company's own public repository. Every commit on nimbus-labs/edge-proxy is authored by [email protected] and GPG-signed by the same address. That mailbox is not a coincidence: the commit message and the DNS SOA both point at the same Cloudflare nameservers, so the person committing infrastructure changes is the person operating the domain. The careers and general inboxes on the LinkedIn page are deliberate decoys - they are public aliases, not the operational owner.
The OSINT board gives you each artifact as a card. No single card names the registrant: the WHOIS is redacted, DNS is just records, LinkedIn lists generic inboxes. The answer emerges when the git author email lines up with the DNS infrastructure, pointing at one operational mailbox - [email protected].
Common mistakes
- Submitting the WHOIS proxy email.
[email protected]is the privacy service's address, not the owner's. - Picking the LinkedIn general or careers inbox.
hello@andjobs@are public aliases, not the operational owner of the domain. - Stopping at the redacted WHOIS. Privacy masks one record; you must pivot to an artifact the service did not touch.
- Ignoring the DNS-to-repo link. The match between the commit's Cloudflare change and the SOA nameservers is what confirms the email.
How to defend against it
If you do not want your domain ownership trivially attributable, treat operational metadata as part of your attack surface alongside WHOIS. The privacy service only protects one record; everything you publish should be reviewed for the same identity leaking back out.
- Use a dedicated, non-identifying author email and signing key for public commits, not a mailbox tied to domain ops.
- Audit public repositories for committer emails before open-sourcing them, and scrub history if needed.
- Keep infrastructure-management identities separate from anything published or searchable.
- Remember that registrar privacy alone is not anonymity - assume correlation across all your public artifacts.