← 02 — Articles

Investigating a domain or URL with free tools

Threat intel6 min read

“Is this link safe?” arrives in a SOC inbox more often than any other question. The domain behind a link carries more history than an IP address does: when it was registered and through whom, which certificates were issued for it, what the page looked like when someone else scanned it, and whether it is already on a blocklist. Almost all of that can be read without anyone visiting the site.

This is part three of the OSINT series. Part one, OSINT for defenders: the ground rules before the tools, explains passive versus active lookups and why submissions are disclosures; part two, Enriching an IP address with free tools, covers the address the domain resolves to.

Before you start: strip what belongs to you

URLs from real emails often carry data about the recipient: a tracking ID, the user’s email address in a parameter, a token in a password-reset or file-sharing link. Before you paste a URL into any external service:

  • Remove query parameters that identify the recipient, unless the parameter itself is the question.
  • Never submit a link that points to your systems — SharePoint, OneDrive, an internal reset portal — to a public scanner. Investigate those in your own logs.
  • Defang it in tickets and chat: hxxps://login-portal[.]example/reset.

Registration data: RDAP

On January 28, 2025, ICANN sunset the WHOIS requirement for generic top-level domains; RDAP is now the authoritative source for .com, .net, .org and the newer gTLDs. Many country-code domains still answer only over WHOIS.

curl -sL https://rdap.org/domain/login-portal.example \
  | jq '{ldhName, events: [.events[] | {eventAction, eventDate}], status}'

What to read:

  • Registration date. A domain registered in the last few days and already used in email is a strong signal on its own. Most phishing domains are young.
  • Registrar. Some registrars appear in abuse reports far more often than others. It is context, not proof.
  • Name servers and status. A domain on clientHold or serverHold has usually been suspended for abuse already.

Registrant details are redacted for most domains since the GDPR, so expect “REDACTED FOR PRIVACY”. The useful data is the dates.

Certificate history: certificate transparency

Every publicly trusted TLS certificate is logged in public certificate transparency (CT) logs before browsers will accept it. crt.sh, run by Sectigo, searches those logs. A % wildcard finds all subdomains:

https://crt.sh/?q=%25.login-portal.example
https://crt.sh/?q=%25.login-portal.example&output=json

The certificate history tells you when the site started using HTTPS — often within hours of a phishing campaign starting — and which other names were on the same certificate. A certificate that also lists microsoft-login.example and docusign-review.example says a lot about the operator’s plans. crt.sh is a free community service and is sometimes slow or briefly unavailable under load; retry rather than conclude there are no certificates.

CT search is fully passive. Nothing reaches the domain’s infrastructure.

DNS: careful, it can be active

Running dig against a suspicious domain looks harmless, but your resolver forwards the query to the domain’s authoritative name server, which the operator controls. Some phishing and malware operators generate a unique subdomain per target and watch their DNS logs to see who looked. For a domain from a targeted email, prefer data someone else already collected:

  • VirusTotal relations list historical resolutions for a domain (passive DNS) and the files and URLs connected to it.
  • urlscan.io results record the IP addresses, certificates and third-party domains a page loaded.

If you need live DNS, query from an analysis machine outside your corporate network, through a public resolver, and query the base domain rather than the exact unique subdomain from the email.

Has someone already scanned it?

urlscan.io loads a URL in a browser on its own infrastructure and records the screenshot, the page’s requests, redirects, cookies, certificates and the final IP addresses. Search before you submit: someone may have scanned the same campaign already, and a search reveals nothing about you.

https://urlscan.io/search/#domain:login-portal.example

If you do submit, pick the visibility deliberately:

Visibility Who can see the result Use it for
Public Everyone; listed on the front page and in search Generic phishing with nothing about your organization in the URL
Unlisted Vetted urlscan Pro customers Phishing you want researchers and takedown teams to see, when the URL may contain personal data
Private You and whoever you share the scan ID with Anything with your users, tokens or internal names in it

What the scan shows: a screenshot of the page (a fake Microsoft 365 login is obvious at a glance), the redirect chain from the email link to the final page, and the domains and IPs the page talked to. Phishing kits often post credentials to a different host than the one serving the page, and that host appears in the request list.

What it does not show: many phishing kits cloak. They serve the real page only to visitors who look like targets — the right country, a residential IP, a browser that came from the email link — and show a blank or harmless page to scanners. A clean screenshot is not a clean verdict.

Blocklists and reputation

  • VirusTotal checks a URL or domain against dozens of blocklists and URL scanners. Searching an existing report is passive; submitting a new URL makes VirusTotal and its partners fetch it.
  • URLhaus, run by abuse.ch with Spamhaus, tracks URLs that serve malware payloads. A link that downloads a file is worth searching there.
  • Google Safe Browsing has a public site status page that shows whether Google currently flags a site as dangerous. Chrome, Firefox and Safari use Safe Browsing data, so a flagged site also tells you whether your users’ browsers would have warned them.

A domain on no blocklist yet is normal for a campaign that started this morning. Blocklists catch up in hours to days; the registration date and the certificate history do not need to.

When the domain looks like yours

If the suspicious domain resembles your own brand — corp-example.com, c0rp.example, corp.example-login.com — it is probably not the only one. dnstwist (Apache-2.0) generates lookalike permutations of a domain (typos, swapped characters, homoglyphs, other TLDs) and checks which ones are registered:

dnstwist --registered corp.example

It can also flag permutations that have MX records, which means they can receive email misdirected by a typo, and compare their web pages with yours to spot clones. There is a web version at dnstwist.it. Running it against your own domain is part five of this series; during an investigation, it shows whether the lookalike in front of you is a one-off or part of a set.

Note that dnstwist resolves the domains it generates, so it is an active lookup against whoever owns them. Run it from an analysis machine rather than from the network you are defending.

  1. Strip identifying parameters, defang, and check your proxy and DNS logs: who else received or clicked it?
  2. RDAP: registration date, registrar, status.
  3. crt.sh: certificate history and other names on the same certificates.
  4. urlscan.io search, then VirusTotal, URLhaus and Safe Browsing: has anyone already scanned or flagged it?
  5. Only if needed: a private urlscan.io submission.
  6. If anyone clicked: the destination IP goes through the steps in part two, and the investigation moves from OSINT to your endpoint and identity logs.

Limitations

  • Cloaking hides phishing pages from scanners. Absence of a malicious screenshot means little.
  • Legitimate services host malicious content too: file-sharing platforms, form builders and website builders appear in phishing every day. A trusted domain in the URL does not make the link safe, and blocking the whole domain usually is not an option.
  • Registration and certificate dates show intent, not guilt. Plenty of new domains are legitimate.
  • Shortened links (bit.ly and similar) hide the destination. Expand them through urlscan.io, not by clicking.

Adapting this to your environment

  • ADAPT the “strip what belongs to you” list to the services your organization uses: which hosts in a URL mean the link points at your own tenant?
  • ADAPT the visibility default for urlscan.io: private for anything from a targeted email, unlisted or public for bulk phishing you want others to see.
  • ADAPT the lookalike check to every domain you own, including the ones only used for email.

Next in the series: checking a file hash without leaking the file. Corrections go to hello@entropywatch.dev.