Domain and Website OSINT: Investigate Who Is Behind a Site

The tip-off

A reader forwards you a text: "Your parcel is on hold, confirm the fee at shop-example.com". The page behind it looks like a well-known retailer. Your job, as an analyst, a journalist or just the person who gets asked, is to say whether this site is what it claims, and if it is not, who else sits behind it.

You do not need special access. Domains are the most public part of the internet, and almost every step of building one leaves a record somewhere. This guide walks through those records in the order we use them, with commands you can paste into a terminal and a fictional target throughout. For the identity side (who runs it, which emails and handles show up), the same method as in our email guide picks up where this one ends.

The map: six places to look

You can run these in any order, but the first two take under a minute and often settle the question, so we start there.

Step 1: Registration data (RDAP, not just WHOIS)

WHOIS is the old text protocol for "who registered this domain". Its modern replacement is RDAP, which returns structured JSON and is what registries now run. Both answer the same questions: when was it registered, through which registrar, when does it expire, and sometimes who is the registrant.

# RDAP via a public redirector, dates only
curl -sL https://rdap.org/domain/shop-example.com | jq '.events'
# classic WHOIS, if you have the client installed
whois shop-example.com | grep -iE 'creat|registrar|expir|updated'

Look at the registration event first. Since the GDPR came in, most registrars redact personal details for private individuals, so do not expect a name and address. The date is rarely hidden, and it is the single most useful field. A mismatch between the story and the date is a finding on its own.

Step 2: DNS, hosting and mail

DNS records say where a site lives and what else the owner has set up. Three lookups cover most of it.

dig +short shop-example.com A
dig +short shop-example.com MX
dig +short shop-example.com TXT

The A record gives the IP address. Look that up and you learn the hosting provider and its network (ASN). Many unrelated sites share one big host, so a shared IP alone proves nothing; a small, unusual host used by several suspicious domains does. The MX records name the mail provider: a shop with no mail setup at all but a "contact us" address is odd. The TXT records often leak the services in use, because SPF lists the senders and verification strings point to tools the owner signed up for.

What you get is infrastructure, not a person. But it gives you things to compare against other domains, which is where it gets interesting.

Step 3: Certificate transparency

Whenever a certificate authority issues a TLS certificate, it is written to public logs. Sites like crt.sh let you search them by name. That has two uses: it dates the site's first HTTPS certificate, and it reveals every hostname that has had a certificate, including subdomains the owner never advertised.

# every name seen on a certificate for the domain
curl -s 'https://crt.sh/?q=%25.shop-example.com&output=json' \
  | jq -r '.[].name_value' | sort -u

You may see mail., admin., staging. or login. names, and sometimes other brand names on the same certificate, which points to sister sites. Dates matter here too. Put them next to the registration date and you can rebuild how the site was put together.

Step 4: Look at it without touching it

Fetching the live site is not passive. Their server logs your IP, and a site that serves different content to different visitors may show you a clean page. For anything where you want to stay quiet, start from copies other people already made: the Internet Archive's Wayback Machine and public scanners such as urlscan.io.

# earliest and latest archived captures
curl -s 'https://web.archive.org/cdx/search/cdx?url=shop-example.com&limit=3&output=json'
curl -s 'https://archive.org/wayback/available?url=shop-example.com'

An archive with no captures before last week confirms the age. Older captures may show a completely different business, which suggests a bought or hijacked domain. Contact pages, footer text, privacy policies and "about" pages are worth reading in old copies: owners tidy the live site and forget the archive. Capture what you find with a screenshot and the capture URL, since both can vanish.

Step 5: Shared tracking IDs

Here is the pivot that surprises people. Site owners paste the same analytics snippet, ad publisher ID or chat widget key into every site they build. Those strings sit in the page source in plain sight, and the same ID on two domains is a strong hint that one person or team runs both.

# pull common tracking IDs out of a page you have saved or fetched
grep -oE 'UA-[0-9]{4,10}-[0-9]+|G-[A-Z0-9]{8,12}|pub-[0-9]{16}' page.html | sort -u

Old Universal Analytics IDs (UA-) were retired in 2023, but they remain in the source of sites that were never updated, which makes them good for linking old and new copies of the same operation. Once you have an ID, search for it. Scanner and web-technology services such as urlscan.io and BuiltWith index them, so you can ask "which other domains carry this string?".

Step 6: Look-alike domains

If the target imitates a brand, the interesting question is how many siblings it has. Typo variants (examp1e), swapped endings (.shop for .com) and added words (example-support) are registered in batches. Searching certificate logs for the brand name, or running a permutation tool such as dnstwist, will list candidates, and the registration dates will cluster if they came from one buyer.

For reporting, most registrars and hosting providers have an abuse contact in their RDAP record, and browsers and security vendors accept reports of phishing pages directly.

A worked example

Notice what carried the case: dates and shared infrastructure, not a name. That is typical, and it is why a redacted registrant record is a speed bump rather than a wall.

Domains are cheap to register and expensive to hide completely.

Limits and conduct

RDAP and WHOIS data can be stale or false. CDNs hide real hosting behind their own IPs. Certificate logs show names, not intent. Archives miss sites that block crawlers. Each finding needs the same grading you would give any other lead: confirmed, likely, possible. Our investigation workflow shows how we record that.

Frequently asked questions