Reverse WHO IS the right way!

Source: Dev.to

🕵️‍♂️ How I Tracked Down a Domain Bought Using My Debit Card

A Real‑World OSINT Investigation

Recently, I found myself in a bizarre situation. Someone I know purchased a domain using my debit card details. At that point, it wasn’t about the money anymore—it was about reputation. I was determined to find that domain.

🧾 What I Knew

I wasn’t starting blind. I had:

• Exact transaction time
• Registrar: Namecheap
• Strong suspicion about who bought it (high probability it was a personal domain)

This quickly turned into a mini cyber‑investigation.

🔍 Attempt 1: Reverse WHOIS API

Approach

• Logged in using a .edu email (Gmail accounts aren’t allowed)
• Queried with:
  • Registrar → Namecheap
  • Date range → the purchase day
  • Keyword → suspected email

Problem
Reverse WHOIS stores data date‑wise, not at minute‑level precision. I fetched all domains registered via Namecheap that day → ~23,000 domains. Too many.

🔎 Narrowing the Search Space

I looked for patterns based on what I knew:

• Likeliest use → personal website
• Premium pricing suggested serious intent
• Indian personal domains rarely use .xyz, .ai, etc. → .com felt most likely

Reduced list: ~5,200 domains – still too many to verify manually.

🤖 AI Filtering Experiment

I asked an AI to generate a script that would:

• Batch 1,000 domains
• Send them to the Gemini API with a prompt to identify domains that look like personal websites for Indian males

The script returned filtered results, but the domain I wanted wasn’t among them. Reverse WHOIS can miss:

• Privacy‑protected registrations
• Uncached entries

Result: Attempt 1 Failed

🏦 Attempt 2: Contacting the Registrar

I contacted Namecheap support about the fraudulent transaction. They:

• Blocked the account
• Refunded my money

But they refused to reveal the domain.

Result: Attempt 2 Failed

🗂 Attempt 3: ICANN CZDS Zone Files

I requested zone files via ICANN CZDS.

Problems:

• Approvals take time; .com requests are slower
• Back‑dated downloads aren’t available; the domain had already been taken down

Result: Inconclusive

🔐 Attempt 4: Certificate Transparency Logs (crt.sh)

I learned that if the domain hosted HTTPS, its SSL certificate must exist in CT logs.

Steps:

1. Queried crt.sh
2. Connected via Postgres and ran batch queries in 5‑minute windows

Issues

• Connection breakages
• SSL errors
• Slow processing

Progress was made, but no success yet.

🚀 Attempt 5: Google BigQuery + crt.sh Dataset

Steps

1. Connected to the dataset.
2. Queried certificates issued during the purchase hour.
3. Filtered for .com domains.

The time‑window reduction went from 700 → 200 domains. After a manual scan of the remaining entries, I found the target domain and matched it to the person.

Result: SUCCESS

🤯 Plot Twist

Later I discovered that the domain was present in my original Reverse WHOIS results. I ignored it because I doubted dataset completeness and trusted the AI filtering too much. Had I manually verified the 5,200 domains, I would have found it earlier.

🧠 Lessons Learned

• Always verify your data – AI helps, but never assume completeness.
• Internet datasets are imperfect – each captures only part of reality.
• OSINT requires patience – impatience slows investigations more than complexity.
• Automation helps; manual validation wins.
• Certificate Transparency logs are gold.

🏁 Final Thoughts

If you take anything from this:

• Double‑check your data.
• Trust, but verify.
• Cultivate patience.

The internet always leaves traces—you just need to know where to look.

Adios.