Domain OSINT: From WHOIS to Infrastructure Mapping

Disclaimer: This article is for education and for lawful, authorised professional research. Use these methods only where you have a legitimate purpose and a lawful basis, and follow the laws and platform terms that apply to you, including data protection law such as the UK GDPR and EU GDPR. See our Terms of Service.

TL;DR

• The Problem: WHOIS privacy services redact ownership data, so most domains show no registrant at all.
• The Approach: Domain OSINT works from less obvious infrastructure signals: historical records, favicon hashes, analytics IDs and TLS certificates.
• The Tooling: Manual CLI tools (dig, whois, openssl) give you raw data, while UserSearch Domain Intelligence adds ownership history and favicon searches, so one lookalike site can lead you to the wider network.
• Key Takeaway: Do not stop at the "redacted" screen. Use technical evidence to establish which organisation operates a domain.

Every online campaign, every lookalike shop and every disinformation site needs somewhere to live. On the web, that means renting domains. Unlike a physical building, a domain is tied to a large, public ledger of technical dependencies. It has an IP address, a registrar, name servers, a TLS certificate and, often, analytics codes that the operator forgot to change.

The difficulty for researchers is that the "front door", the WHOIS record, is usually closed. Privacy services redact the registrant's details. But if you look at the infrastructure, the wiring of the building, you find the evidence. You find that a lookalike site uses the same Google Analytics ID as a known marketing site. You find that the domain pointed to a company's own server three years ago, before the privacy service was switched on.

This connects closely with other infrastructure techniques, such as wireless network research, where physical places meet digital identifiers.

This is Domain OSINT: moving from a single URL to a clear map of the infrastructure behind it.

What Is Domain OSINT?

Domain OSINT (open-source intelligence) is the process of collecting public data about a domain name to understand its ownership, technical configuration and relationships with other entities on the internet. Unlike simply visiting a website, domain OSINT focuses on metadata and infrastructure records that exist whether the website is online or not.

At its core, a domain is a human-readable pointer. To work, it must connect to servers (A records), mail exchanges (MX records) and name servers (NS records). Each connection is a link in the chain of evidence. Even if an operator registers under a false name, they often reuse the same hosting account, the same certificate provider or the same analytics codes across their whole network. Domain OSINT is about finding those reused signals to map the full scope of an operation.

For background on how registration data works today, including the move from WHOIS to RDAP, see ICANN's registration data lookup FAQ.

Why It Matters in Professional Research

In modern security and research work, the domain is often the first, and sometimes the only, indicator you have. Whether you are reviewing a phishing campaign, a brand infringement case or a disinformation network, the domain is the thread that unravels the sweater.

Consider EU DisinfoLab's Doppelganger research. The researchers described an operation that bought dozens of domain names similar to those of real news outlets and copied their designs. Mapping those domains and their shared infrastructure was central to showing that the sites belonged to one campaign. Frameworks such as MITRE ATT&CK (T1583: Acquire Infrastructure) describe how operators buy or lease domains and servers to stage their activity. A single configuration slip, such as reusing a certificate or a server, can connect a whole network.

For corporate teams, Domain OSINT is valuable for:

• Brand protection: identifying typosquatting domains (for example examp1e.com) that copy a company's login page.
• Attribution: establishing whether a new campaign uses the same infrastructure habits as a known group.
• Due diligence: verifying whether a potential partner company really owns the web assets it claims.

The Manual Method (The Long Way)

Before using automated tools, it is worth understanding the raw data. Automated tools run these same queries faster. If you do not understand the output of dig, you will not understand an automated report either.

1. WHOIS Registration Data

WHOIS is a query and response protocol for databases that store the registered holders of internet resources. It used to be full of names, emails and phone numbers. Today, largely because of GDPR, it is often redacted.

To run a manual check:

whois example.com

What to look for:

• Creation date: a "bank" domain created two days ago is almost certainly not the bank.
• Registrar: large companies tend to use corporate brand registrars such as CSC. Short-lived campaigns often use cheap, bulk registrars or smaller offshore providers.
• Name servers: does the site use standard hosting (ns1.examplehost.net) or custom name servers (ns1.example-internal.com) that may appear on other domains too?

2. DNS Interrogation (dig)

The Domain Name System (DNS) is the phone book of the internet. The dig command (Domain Information Groper) lets you query its records directly. This tells you where the domain "lives".

# Get the IP address (A record)
dig example.com A +short

# Get the mail server (MX record)
dig example.com MX +short

# Get the text records (TXT record)
dig example.com TXT +short

Analysis:

• A record: shows the hosting provider. If it resolves to 104.21.x.x, the site sits behind Cloudflare, which stands in front of the real server. If it resolves to a residential broadband range, that is a clear warning sign for a site claiming to be a business.
• MX record: shows who handles the domain's email. A "bank" using a temporary email service for its MX records is not a bank. Established organisations run their own mail or use providers such as Google Workspace or Microsoft 365.
• TXT record: often contains verification strings for services such as Google Search Console, SPF records for email, or other ownership proofs. Operators sometimes copy these records between sites, which can link a lookalike site to their other projects.

3. Source Code and ID Extraction

Websites are built with code, and that code often contains unique analytics identifiers. If one operator runs 50 lookalike sites, they usually want traffic figures for all of them, so they embed the same Google Analytics or AdSense code.

To find these manually:

# Download the page source
curl -sL https://example.com > source.html

# Search for common patterns (UA- and G- for Google Analytics, pub- for AdSense)
grep -oE "UA-[0-9]+-[0-9]+|G-[A-Z0-9]{8,12}" source.html
grep -oE "pub-[0-9]+" source.html

-o prints only the matching text and -E enables extended patterns. If you find UA-12345678-1 on example-offers.com, search the web for that exact ID. If it also appears on example-agency.com, you have a strong lead on the organisation behind the site.

4. TLS Certificate Analysis

TLS certificates (the padlock icon) contain metadata about the entity that requested them. Domain-validated certificates, such as those from Let's Encrypt, carry no organisation name, but paid certificates (OV or EV) contain verified company names. You can also search Certificate Transparency logs using free tools such as crt.sh to see every certificate issued for a domain.

# Connect and print the certificate details
echo | openssl s_client -showcerts -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -inform pem -noout -text

-servername sends the right hostname to shared servers, and -noout -text prints the certificate in readable form. Look for:

• Subject Alternative Name (SAN): a single certificate is often valid for several domains. You might find example.com also lists dev-server.example.net and admin-panel.example.org in its SAN field, showing less obvious parts of the infrastructure.
• Issuer: which certificate authority validated the request, and at what level?

The Pivot: UserSearch Domain Intelligence

The manual methods above are precise but slow. You cannot run dig and curl on 500 domains an hour without writing and maintaining scripts. Manual checks also show only the current state of the domain. They do not show what the WHOIS record looked like three years ago, before the owner switched on privacy.

UserSearch brings this fragmented workflow into one platform with historical data. Domain Intelligence covers ownership, history and favicon searches, and one account gives you access to 100+ third-party data sources, each result shown with its source.

1. Domain Ownership History (The Time Machine)

The most effective single technique in Domain OSINT is looking back in time. Many operators are not careful from day one. They register a domain with a company email address, realise a month later that it is public, and then pay for WHOIS privacy.

A manual whois check today shows only "Redacted for Privacy". The ownership history in Domain Intelligence shows earlier records from before the details were redacted.

• The check: enter the domain in Domain Intelligence.
• The output: a timeline of records. Scroll back to the earliest entries (2018, 2019 and so on).
• The result: you find [email protected] listed as the registrant in 2019. You can then search that address with Email Intelligence and check the example-media.com domain itself to find the organisation and its other domains.

2. Favicon Search (Visual Fingerprinting)

A favicon is the small icon in your browser tab. To a computer, it is a file with a specific hash (often MurmurHash3, or MMH3). Phishing kits are often lazy: they copy the genuine website, favicon included.

When an operator sets up 100 lookalike login pages on 100 different domains, they rarely change the favicon. That creates a distinctive fingerprint.

• The check: use the favicon search in Domain Intelligence.
• The logic: the system calculates the hash of the site's favicon and finds other sites serving exactly the same image.
• The result: you enter the favicon of a lookalike site. The results return 45 other domains, some created today and some months ago, all using the same icon. You have mapped the active campaign, not just the single URL you started with.

3. Analytics ID Correlation

As mentioned in the manual section, analytics codes (Google Analytics, AdSense, New Relic IDs) are sticky. They often persist across different projects run by the same organisation. Record every unique ID you extract, search each one, and save the matches to your Case so the links are documented.

• The check: extract the IDs from the site's source code and search for other domains using them.
• The output: a list of unique IDs and the other domains that share them.
• The scenario: you are researching a "news" site that publishes false stories. It uses a specific AdSense ID. The same ID appears on a site selling herbal supplements and another hosting copied films. You have now connected the disinformation site to a financially motivated affiliate network rather than a state-linked operation.

4. Reputation and Threat Context

Domain OSINT is not only about ownership; it is about risk. The Threat Intelligence search type in UserSearch adds threat context to infrastructure data, and public reputation lists add more.

• Reputation (Spamhaus): has the domain or its IP address been listed for sending spam or hosting harmful content? Checking the Spamhaus Blocklist (SBL) helps confirm whether a domain has a history of abuse.
• Scan history: public scanning services show what a site looked like when others reported it, which helps when the page has since changed.

5. The "Registered-By" Pivot

Before GDPR, the registrant email was the most useful field in WHOIS. It is rare in live records today, but it remains the most common pivot in historical data. Services such as DomainTools built their reputation on this history, and UserSearch Domain Intelligence provides historical ownership lookups too.

If you find an old address such as [email protected] in a 2017 record for a current lookalike site, you have not just found a name; you have found an organisation. You can then research agency-design.example to see whether the design agency built the site for a client, still manages it, or simply registered it years ago before the domain changed hands. Moving from a technical asset to an organisation is the core of infrastructure research.

Advanced Strategies and Use Cases

Now that we have the tools, here is how to combine them into complete research workflows.

Scenario 1: The Lookalike Login Network

Context: You work for Brightmoor Exchange, a fictional mid-sized crypto exchange. Customers report a fake login page that took their funds. (See our guide on linking wallets, addresses and infrastructure for following the funds themselves.)

1. Initial check: you take the URL secure-login-example.net and run a Domain Intelligence ownership check. It is redacted.
2. Visual pivot: the site uses your company's logo as its favicon. You run a favicon search. It returns 12 other domains, including update-example-wallet.com and verify-example-assets.org.
3. Infrastructure pivot: you run an IP Intelligence check on the new domains. They all resolve to the same dedicated server, 198.51.100.24, at one hosting provider.
4. Historical check: you check the history of the oldest domain in the cluster. The 2020 record shows a registrant address that also appears on four more lookalike domains.
5. Outcome: you now have a documented cluster of 17 domains on shared infrastructure. You send takedown requests to the registrar and hosting provider, warn customers, and pass the sourced report to law enforcement.

Scenario 2: The Undisclosed Promotional Blog

Context: Your company, Larkspur Kitchens, notices an "independent" review blog that praises a competitor and criticises your products days after each of your launches. You want to know whether the blog is really independent.

1. Discovery: you review the blog, honest-kitchen-reviews.example, and note its launch date and posting pattern.
2. ID correlation: you extract the site's analytics identifiers and find a distinctive New Relic application ID.
3. Search: the same New Relic ID appears on competitor-marketing-portal.example.
4. Conclusion: the technical link shows that the "independent" blog runs on the same application performance setup as the competitor's official marketing site. That points to undisclosed marketing rather than independent reviews, which your legal team can raise under the UK advertising code.

Common Pitfalls in Infrastructure Analysis

Even experienced analysts are caught out by false positives. Infrastructure analysis is rarely black and white; it deals in probabilities.

1. The Cloudflare Curtain

An IP address such as 104.21.x.x or 172.67.x.x does not tell you where the server is. These ranges belong to Cloudflare. If you report such an IP to a hosting provider, you are reporting the CDN, not the host. Look for historical IP records from before the CDN was enabled, or subdomains (such as mail.example.com or ftp.example.com) that often point directly to the origin server rather than through the CDN.

2. Shared Hosting Noise

If example-offers.com is hosted on 192.0.2.1 and you run a reverse-IP lookup, you might find 50,000 other domains on the same address. This is shared hosting (for example GoDaddy or Bluehost). Sharing an IP address with a legitimate flower shop does not mean the flower shop is involved. Look for unique identifiers, such as shared analytics IDs or specific network ranges, not just shared public IPs.

3. The Parked Domain Trap

Many domains appear in threat feeds simply because they are "parked" (expired and bought by an advertising aggregator). These pages often carry generic ads that may be flagged as spam, but they are abandoned assets, not an active operation. Always check the content with a safe scanning service such as urlscan.io or VirusTotal before concluding that a domain is part of an active campaign.

Legal and Ethical Guardrails

Domain OSINT is powerful because it relies on publicly available data. There is still a clear line between observation and interaction.

• Passive vs. active: reviewing WHOIS records, DNS entries and passive DNS history is passive. You are reading records that already exist. This is generally appropriate for research with a legitimate purpose.
• Port scanning and probing: actively scanning a server for weaknesses (for example running Nmap against the IP address in the A record) is active. Without explicit permission, it can break laws such as the Computer Fraud and Abuse Act (CFAA) in the US or the Computer Misuse Act in the UK. Stay with passive methods unless you are authorised.
• Touching the glass: take care when visiting doubtful domains in a browser, as they may host harmful code. Use an isolated browser environment or a scanning service that fetches the page for you.
• Personal data: historical registration records can include individuals' names and addresses. Keep them only where your purpose needs them and leave them out of shared reports.

Always make sure your research has a legitimate purpose, such as security research, fraud prevention or legal work, and document your process in a Case.

From Redacted Record to Clear Map

The domain name is only the tip of the iceberg. Below it lies a network of historical records, technical settings and shared identifiers that can link even a careful operator's sites to one another. By combining manual understanding with the ownership history, favicon searches and 100+ third-party data sources available through one UserSearch account, you can turn a single opaque URL into a clear, sourced map, kept in a Case and ready to share as a report.

Do not stop at the "Redacted for Privacy" screen. Look into the infrastructure.

Stop guessing. Start researching with UserSearch.