A suspicious domain or URL is a lead, not a verdict. The useful outcome of a first pass is a decision another analyst can reproduce: what was observed, when it was observed, what remains uncertain, and whether to escalate. Start with passive evidence. Render a page only when the extra visibility is worth the exposure of submitting it to a scanning service.
Preserve the exact observable
Record the full URL or hostname from the alert, the observation time, and where it came from. Keep the path and query string in the case record because they can explain a redirect or identify a phishing lure. If the URL contains credentials, session tokens, personal data, or internal hostnames, redact the sensitive parts before sharing it outside your team. Do not open the original link in your daily-use browser just to see what it does.
Separate a full URL from its hostname and registrable domain. A result for the parent domain does not automatically describe a specific path, subdomain, or point in time. Note any redirect destination as a separate observable rather than silently replacing the original lead.
Build a passive timeline first
- Check VirusTotal for reputation and related objects, then compare its domain resolution history with the alert time. A past IP address is a pivot, not proof that the same host is serving the URL now.
- Use SecurityTrails to inspect historical DNS and neighboring names. Record the first and last observation you can verify, and avoid treating a shared hosting address as ownership evidence.
- Search crt.sh for certificate transparency records that suggest related hostnames. A certificate name can expand a search, but it does not establish that every named host participated in the same activity.
- Search existing urlscan.io results before submitting a fresh scan. Compare the recorded URL, final page, redirects, requests, and observation date with your lead.
These pivots answer different questions. DNS tells you where a name resolved, certificate records reveal names presented for issuance, reputation services show prior reports, and a saved page scan shows a particular rendering. None is a substitute for the others.
Render only when the question requires it
If passive sources cannot show what the URL actually presents, a controlled browser scan may reveal the redirect chain, page screenshot, and network requests. urlscan documentation distinguishes public, unlisted, and private scans. Public results are searchable; unlisted results are available to some vetted researchers and customers; private results have narrower visibility and retention limits. Choose the setting that matches your data handling requirements before submitting. Never paste a token-bearing or internal URL into a public scan.
Save the scan ID, timestamp, initial URL, final URL, redirect hops, and any page elements that support the hypothesis. If the site is unavailable or the scan is blocked, write that limitation down. A failed render is not evidence that the infrastructure is harmless.
Decide from corroborated observations
- Escalate when independent observations point to the same harmful behavior: for example, a reported phishing URL, a captured imitation login page, and a redirect or request pattern consistent with the report. Preserve the screenshot and exact timestamps.
- Keep investigating when the only signal is a shared IP, a certificate name, or a single reputation label. These are useful leads but weak grounds for broad blocking.
- Close or monitor when current checks do not support the initial concern, while retaining the original alert and the limits of the checks. Avoid rewriting an old observation as a current one.
The handoff should include the original observable, scope and timestamps, links or IDs for each source, the strongest supporting and contradicting evidence, your confidence, and the next action. Link colleagues to the specific OSINT tools used, not just a vendor homepage. This keeps the investigation reviewable and makes a later recheck faster.