CYBERSECURITY · OSINT

Investigate a suspicious domain: a workflow.

A reproducible, passive OSINT workflow to investigate a suspicious domain: OPSEC, reputation, WHOIS, DNS, certificates, pivoting, and documenting IOCs.

July 20, 202615 min readDaniel A. & Óscar S.

A user forwards you a link. A SIEM alert fires on an outbound connection. A takedown request lands on your desk. Whatever the trigger, the question is the same: is this domain hostile, and what is it connected to? This is the analyst's version of that investigation: a reproducible workflow you can run end to end without ever loading the site in your real browser. If you only need the quick consumer-grade "is this a scam?" check, read how to check if a domain is suspicious instead. This piece is the technical companion, and it assumes you want infrastructure, evidence, and pivots you can hand to a takedown or a detection rule.

Everything here is passive OSINT: we read what third parties and the target have already published, and we let sandboxes do any touching. We do not log in, submit forms, scan ports, or probe for flaws. That is not just good manners: it is the line between research and a computer-misuse offence. If you are new to the discipline, what is OSINT lays out the passive-versus-active distinction and the legal boundaries in full. Keep one rule in your head throughout: observe, do not interact; document, do not exploit.

A safe, repeatable workflow for investigating a suspicious domain.

Step 0 – OPSEC first, before you touch anything

Why: the moment you visit a live phishing or malware domain from your normal browser, three bad things can happen. You can get exploited or fingerprinted; you can leak your real IP into the attacker's logs and tip them off that they are being investigated (so they rotate infrastructure or serve you a clean decoy); and you can pollute your own findings with cookies and sessions from your real identity. Attackers routinely cloak – showing benign content to datacentre IPs and known researchers, and the real payload only to fresh residential visitors.

How: never open the URL directly. Use a disposable analysis environment and let remote sandboxes fetch the page for you:

A throwaway VM or an isolated browser profile you can roll back to a clean snapshot – never your host or work machine.
A VPN or a research egress so your home or corporate IP never lands in the target's logs.
urlscan.io to render the page remotely and give you a screenshot, redirect chain, and resource list without your machine ever connecting. Submit it as unlisted if the case is sensitive, since public scans are searchable by anyone – including the attacker.

One habit runs through the whole workflow: write every indicator defanged: paypa1-secure[.]com, hxxps://, 198.51.100[.]24 – so nobody in the thread clicks it by reflex. You re-fang (strip the brackets) only inside a command you deliberately run.

The quick-reference map

The whole investigation is a sequence of "what am I trying to learn, which tool answers it, and what specifically am I looking at." Keep this table next to you:

Objective	Tool	What you're looking for
Don't get burned looking	urlscan.io, VM/sandbox, VPN	Render remotely; hide your origin
Is it already known-bad?	VirusTotal, URLhaus/ThreatFox, Safe Browsing, AbuseIPDB, GreyNoise	Existing detections, abuse reports
How old / who registered it	WHOIS / RDAP	Creation date, registrar, privacy
Where it's hosted	dig, ipinfo.io, bgp.he.net	A/MX/NS/TXT records, IP geo, ASN
Certificate history	crt.sh	Issuance dates, sibling subdomains
What the site does	urlscan.io, web-check.xyz, Wayback, BuiltWith/Wappalyzer, securityheaders.com	Screenshot, redirects, tech, headers
Look-alike variants	dnstwist	Typosquats that resolve
Related infrastructure	Shodan, Censys	Same IP / cert / favicon hash
Who to notify	Report / block	Registrar, host, abuse contacts

Step 1 – Reputation: has someone already done the work?

Why: most malicious domains are not novel. Before you spend an hour on infrastructure, check whether the community already flagged it: a positive hit can close the case in thirty seconds. A clean result proves nothing (fresh phishing is live for hours before anyone indexes it), so treat "unknown" as "keep going," never as "safe."

How: run the domain, the URL, and its hosting IP through the reputation layer:

VirusTotal – dozens of engines plus a relations graph (the same IP, certs, and sibling domains you'll pivot on later).
URLhaus and ThreatFox from abuse.ch – malicious URLs and shared indicators of compromise, free and high quality.
Google Safe Browsing – is the URL already on the block list your browser reads from?
AbuseIPDB – community abuse reports and a confidence score for the hosting IP.
GreyNoise – is that IP part of internet-wide "background noise," or is it quiet and targeted? It cuts false positives when you triage an address.

Step 2 – WHOIS / RDAP: how old is it, and who runs it?

Why: domain age is one of the strongest single signals in phishing triage. An established brand does not suddenly run its login page from a domain registered last Tuesday. A registration only days old, on a bulk registrar, impersonating a decade-old company, is a red flag by itself. WHOIS/RDAP also gives you the registrar, which you'll need to know who to report to. Read what is WHOIS for how to interpret each field and why privacy masking is normal.

How: use the classic whois client, or query RDAP (the modern, structured, JSON replacement) directly:

$ whois paypa1-secure.com | grep -Ei 'creat|registrar:|expir'
Registrar: Cheap-Bulk-Reg, LLC
Creation Date: 2026-07-12T09:14:00Z
Registry Expiry Date: 2027-07-12T09:14:00Z

$ curl -s https://rdap.org/domain/paypa1-secure.com \
    | jq '.events[] | select(.eventAction=="registration")'
{
  "eventAction": "registration",
  "eventDate": "2026-07-12T09:14:00Z"
}

Registered a handful of days ago, on a cheap bulk registrar, with a one-year term paid in full: the classic disposable-phishing profile. Privacy protection hiding the registrant name is common and not by itself suspicious – the date is what carries the weight.

Step 3 – DNS and hosting: where does it actually live?

Why: the IP and the network behind a domain are what let you pivot to the rest of the campaign. The nameservers, the mail setup, and the ASN all tell you what kind of operator you are dealing with – a mainstream cloud, a cheap reseller, or a network with a reputation for looking the other way.

How: resolve the core records with dig, geolocate the IP with ipinfo.io, and look up the network on bgp.he.net:

$ dig +short A   paypa1-secure.com
198.51.100.24
$ dig +short NS  paypa1-secure.com
ns1.cheap-dns.example.
ns2.cheap-dns.example.
$ dig +short MX  paypa1-secure.com
$ dig +short TXT paypa1-secure.com
"v=spf1 -all"

$ curl -s https://ipinfo.io/198.51.100.24/json | jq '{ip,org,country,hostname}'
{
  "ip": "198.51.100.24",
  "org": "AS64501 Example Hosting Reseller",
  "country": "NL",
  "hostname": "vps-24.example-host.test"
}

No MX record and a locked-down -all SPF policy tell you the domain is not built to send mail from itself – consistent with a link-only phishing lure rather than a real business. The IP resolves to a small reseller ASN, not the brand's real cloud. On bgp.he.net you can see every other prefix and domain that ASN announces, which becomes a pivot in Step 6. (The addresses here are documentation ranges from RFC 5737 and a documentation ASN from RFC 5398 – the case is fictional.)

Step 4 – Certificates and CT logs: the free history book

Why: every publicly trusted TLS certificate is written to Certificate Transparency logs, which are append-only and world-readable. That gives you two gifts: a precise timeline (a cert minted the same day the domain was registered), and sibling subdomains the operator may never have meant to expose. See TLS certificate transparency for why these logs exist and how to read them.

How: query crt.sh – no need to touch the target at all:

$ curl -s 'https://crt.sh/?q=paypa1-secure.com&output=json' \
    | jq -r '.[] | "\(.entry_timestamp)  \(.name_value)"' | sort -u
2026-07-12T09:41:03  paypa1-secure.com
2026-07-12T09:41:03  www.paypa1-secure.com
2026-07-12T10:02:55  login.paypa1-secure.com
2026-07-12T10:02:55  secure.paypa1-secure.com

The certificate was issued minutes after registration, and there are subdomains – login., secure. – that scream credential harvesting. Note the certificate serial and the issuing CA; a reused serial or key across several domains is one of the cleanest pivots there is.

Step 5 – Analyse the site without visiting it

Why: you still want to know what the page does – what it looks like, where its form posts, what it loads, how it redirects – but you refuse to load it yourself. Remote sandboxes and archives answer all of that safely.

How: stack the passive site-analysis tools:

urlscan.io: the anchor. A remote browser loads the URL and returns a screenshot, the full redirect chain, every contacted domain, and the page's resources. You see the login clone without ever rendering it locally.
web-check.xyz – a one-page dashboard of DNS, headers, certs, and detected tech in a single view.
Wayback Machine – what the domain (or its IP's earlier tenants) served in the past; useful when a site has already been swapped or taken down.
BuiltWith and Wappalyzer – the tech stack and any phishing-kit fingerprints.
securityheaders.com – a throwaway kit usually scores an F; a real bank does not.

The signal you care about most from urlscan: where does the form actually post? A login page branded as PayPal that submits credentials to an unrelated host on the same cheap reseller is as close to a confession as this workflow gets.

Step 6 – Typosquatting and pivoting to the wider campaign

Why: a single phishing domain is rarely alone. The same actor usually registers a spread of look-alikes and hosts them on shared infrastructure. Finding the siblings turns one indicator into a campaign map, and a far more useful takedown.

How: run dnstwist against the legitimate brand to enumerate registered look-alikes, then pivot on the shared artefacts you collected. Note how paypa1- swaps the letter "l" for the digit "1": the exact trick the tool models:

$ dnstwist --registered --format cli paypal.com
paypa1.com          203.0.113.10    registered
paypa1-secure.com   198.51.100.24   registered  2026-07-12
paypai-login.com    198.51.100.24   registered  2026-07-12

Two of those squats share 198.51.100.24: your host. Now pivot on every shared artefact:

Same IP / ASN: reverse-lookup the address and browse the ASN on bgp.he.net for co-hosted domains.
Same certificate: search crt.sh for the certificate serial or an unusual Subject value.
Same favicon: phishing kits reuse a brand's favicon, and its hash is searchable. This is where Shodan and Censys earn their keep:

$ shodan search 'http.favicon.hash:-1234567890' --fields ip_str,org
198.51.100.24   Example Hosting Reseller
203.0.113.77    Example Hosting Reseller
203.0.113.10    Example Hosting Reseller

Three hosts, one favicon, one reseller: the campaign's footprint. Everything so far has been passive: querying third-party datasets and search engines, never scanning or exploiting the attacker's servers yourself. That distinction is exactly where the legal line sits. Enumerating public records is OSINT; port-scanning, brute-forcing the login, or "testing" the form is unauthorised access, and it is a crime in most jurisdictions no matter how obviously malicious the target is. Map the infrastructure – do not attack it.

Step 7 – Document IOCs and decide

Why: an investigation nobody can act on was a hobby, not work. Package what you found into indicators others can block and report, with the evidence attached.

How: write a defanged IOC block and a one-line verdict with your confidence level:

Indicator                          Type    Note
paypa1-secure[.]com                domain  PayPal typosquat, reg. 2026-07-12
login.paypa1-secure[.]com          host    credential-harvest subdomain
198.51.100[.]24                    ipv4    hosting IP, AS64501 (reseller)
203.0.113[.]77                     ipv4    sibling host, same favicon hash
hxxps://paypa1-secure[.]com/login  url     phishing page, posts off-domain

Verdict: malicious (high confidence). Brand-impersonation
credential phishing. Domain + cert both < 1 day old at first
observation; login clone posts to unrelated host on shared
reseller infra; two sibling squats on the same IP.

Then act on it. To get it taken down, you report to the right parties: the registrar for the domain, the hosting provider for the server, the brand's abuse team, and national reporters. Our guide to reporting a scam website walks the process, and registry, registrar, ISP and hosting explains which of those actors controls what, so your abuse report reaches whoever can actually pull the plug. To protect your own users right now, push the domains and IPs to your DNS filter, proxy, and EDR block lists.

The workflow as a checklist

OPSEC: disposable VM, VPN, and remote sandboxes – never your real browser.
Reputation: VirusTotal, URLhaus/ThreatFox, Safe Browsing, AbuseIPDB, GreyNoise.
WHOIS/RDAP: creation date (age is the strongest signal), registrar, privacy.
DNS: A/MX/NS/TXT with dig; IP geo with ipinfo.io; ASN on bgp.he.net.
Certificates: crt.sh for issuance timeline and sibling subdomains.
Site analysis: urlscan.io, web-check.xyz, Wayback, BuiltWith/Wappalyzer, securityheaders.com – where does the form post?
Typosquat and pivot: dnstwist on the real brand; pivot on shared IP, cert, and favicon hash via Shodan/Censys.
Document and decide: defanged IOCs, a confidence-rated verdict, then report and block.

Run these steps in order and the picture almost always resolves before you reach the end. The domain age and the certificate timeline usually decide it; the site analysis confirms intent; and the pivots turn one bad link into the map of a campaign. The discipline that makes it repeatable is the same one that keeps it legal and keeps you safe: passive collection, careful documentation, and never once interacting with the attacker's machine.

Frequently asked questions

How do I check if a website is a scam safely?

Never load a suspicious URL in your normal browser. Let a remote sandbox do the looking: submit it to urlscan.io, which renders the page on its own infrastructure and returns a screenshot, the redirect chain, and every domain it contacts, so your machine never connects and your IP never lands in the attacker's logs. Cross-check the reputation layer – VirusTotal, Google Safe Browsing, the abuse.ch feeds, AbuseIPDB – and read the registration date from WHOIS/RDAP. If you must interact more directly, do it from a throwaway virtual machine behind a VPN, on a snapshot you can roll back. The golden rule is passive: observe through third parties, do not interact with the site itself.

How can I tell how old a domain is?

Query its registration record. The classic way is the whois client (whois example.com) or ICANN's web lookup at lookup.icann.org; the modern, structured way is RDAP, which returns JSON – for example, curl -s https://rdap.org/domain/example.com and read the event with eventAction "registration." The creation date is the field that matters. A domain registered days ago that is impersonating an established company and asking for credentials is a strong red flag on its own; a legitimate ten-year-old business does not suddenly move its login page to a week-old domain. Certificate Transparency logs at crt.sh give you a second, independent timeline, since the first certificate is usually issued right after registration.

How do I find who is behind a phishing site?

Passively, and with realistic expectations. WHOIS/RDAP gives you the registrar and dates, though the registrant name is often privacy-masked. The stronger leads are infrastructure: the hosting IP and ASN (dig, ipinfo.io, bgp.he.net), the certificate serial and subdomains (crt.sh), and the favicon hash and shared hosts (Shodan, Censys). Pivoting on those shared artefacts usually links a cluster of look-alike domains to one operator and one network, which is what a takedown actually needs. Attributing a real-world identity is rarely possible from open sources alone and is a job for law enforcement; your goal is to map the infrastructure and hand over evidence, not to unmask a person.

Is it safe to visit a suspicious link?

Assume it is not. A live phishing or malware page can fingerprint you, exploit your browser, or simply log your IP and know it is being investigated, and attackers often cloak, serving harmless content to researchers and the real payload only to fresh victims. So do not visit it directly. Use urlscan.io or a similar sandbox to see the page remotely, and if you need to go further, use an isolated virtual machine behind a VPN with a snapshot you can revert. Also remember that a valid HTTPS padlock proves only that the connection is encrypted, not that the site is who it claims to be – plenty of phishing pages have perfectly valid certificates.

What are the IOCs of a malicious domain?

Indicators of Compromise are the concrete, blockable artefacts an investigation produces: the domain and its subdomains, the hosting IPv4/IPv6 addresses, the ASN, URLs (especially the credential-posting endpoint), certificate serials and hashes, file hashes of any downloaded payload, and fingerprints like a reused favicon hash. Good IOCs are always written defanged – paypa1-secure[.]com, hxxps://, 198.51.100[.]24 – so nobody clicks them by accident, and each carries a short note on how it was observed. You feed them into block lists (DNS filters, proxies, EDR) and into reports to the registrar, host, and threat-intel feeds like abuse.ch's ThreatFox.

What is the difference between passive and active investigation, and where is the legal line?

Passive investigation reads data from third parties and public logs – WHOIS/RDAP, Certificate Transparency, urlscan, reputation feeds, search engines like Shodan – without ever touching the target's own servers. The target cannot tell you looked. Active investigation touches the target directly: resolving its hosts against it, scanning ports, submitting its forms, testing the login. That is where the legal line runs. Reading public records about even an obviously criminal domain is lawful OSINT; port-scanning it, brute-forcing it, or "just testing" its form is unauthorised access and a crime under laws like the US Computer Fraud and Abuse Act and the UK Computer Misuse Act – regardless of how malicious the target is. Stay passive: map the infrastructure, document it, and hand it to whoever is authorised to act.