How to Investigate a Phishing Domain End to End

Do not make the first move from your own browser. That is how you give the operator a clean hit from your IP, run their client-side code, or miss the part of the kit that only triggers from the lure path. I work around the domain first: the reported URL, the render, redirects, DNS changes, certificate records, and blocklist or vendor history. Phishing infrastructure rarely behaves politely. It may be parked when you check it. It may only show the payload from a phone. It may vanish after lunch. It may sit on the same shared host as completely normal sites.

This is the passive-first workflow I use when a suspicious phishing domain needs a defensible answer, not just a gut call. The tools are urlscan.io, VirusTotal, SecurityTrails, crt.sh, and Destroylist. I use each for a different job. urlscan.io shows behavior: the page, redirects, and requests. VirusTotal gives vendor, community, and relationship context. SecurityTrails makes DNS and ownership history easier to read. crt.sh turns certificate transparency into pivots. Destroylist answers the practical blocklist question: has this domain already shown up in a phishing and scam feed?

The output is a classification you can explain later. Benign. Unclear. Suspicious. Confirmed phishing. Campaign lead. That label drives blocking, takedown, monitoring, and whether another analyst spends tomorrow chasing the same cluster.

What this workflow does

An end-to-end phishing domain investigation has three jobs. Preserve the evidence. Keep the analyst out of range. Separate current behavior from stale artifacts. Start with the report exactly as it arrived: domain, full URL, source, timestamp, visible lure, email headers, screenshots, and referrer context. Keep the string intact. Do not tidy it too early. example[.]com, a URL with tracking parameters, and a shortened redirect can each expose different evidence.

Before you touch the target, decide what you can collect without talking to it. A direct visit from a corporate network or personal laptop can trigger attacker telemetry, expose an investigation address, or execute hostile JavaScript. Most cases start better with sandboxed rendering and third-party enrichment. If the report involves credential capture, malware delivery, or a sensitive target, I keep the whole job inside an isolated investigation environment.

My order is conservative on purpose:

Preserve the reported indicator and visible context.
Render or search the target in urlscan.io.
Check VirusTotal and Destroylist for existing reputation signals.
Map DNS, WHOIS, and hosting history in SecurityTrails.
Expand certificate transparency leads with crt.sh.
Correlate the overlaps into a confidence decision and next action.

That keeps reputation in its lane. Useful, yes. Final, no. A fresh phishing domain can take credentials for hours before a vendor calls it malicious. A clean result often means the domain is new, not safe.

Key features of the investigation

Safe first look with urlscan.io

When I have the full phishing URL, urlscan.io is usually where I begin. Search first. Do not submit reflexively. If someone has already scanned the URL or domain, you may get the screenshot, DOM data, redirect chain, network requests, IP address, ASN, TLS certificate details, and linked resources without creating a new interaction with the target.

If no scan exists and policy allows a submission, slow down on visibility. Public scans can leak sensitive URLs, tokens, victim identifiers, internal hostnames, and the fact that someone is looking. For case-specific links, or anything where early exposure could make the operator change behavior, use private or unlisted visibility.

The screenshot is a clue, not the case. I record the final landing URL, each redirect hop, page title, form actions, contacted domains, JavaScript hosts, favicon hash, server IP, ASN, and any visible brand impersonation. One pattern is easy to miss and worth catching: the lure opens on one domain but sends credentials to another host. That receiving host is often the better pivot.

urlscan can also help you tell a dead page from a cloaked page, but only if you read beyond the thumbnail. A blank render, HTTP error, or parking page is not a safety verdict. Check region, user agent, timing, and referrer assumptions. Plenty of kits show the payload only to mobile browsers, certain countries, fresh sessions, or visitors arriving from the original lure link.

Reputation checks with VirusTotal and Destroylist

VirusTotal gives broad reputation and enrichment. Query the full URL, the bare domain, resolved IPs, and any redirect targets you found. Detection count is the loud number on the screen. I still read past it: community comments, first submission time, last analysis time, associated files, contacted URLs, passive DNS where available, and relationships to other observables.

Timing changes the interpretation. A domain first submitted five minutes ago with no detections is not comparable to a domain seen for weeks with mixed vendor results. A high detection count can support a confirmed-malicious call. One or two detections need context. Some engines are noisy. Some are late. Record who flagged the indicator, when they flagged it, and whether the label matches the behavior you observed.

Destroylist gives a narrower operational signal. It is presence in a phishing and scam domain feed, not a full intelligence product. I use it for confirmation and blocking context. If the domain appears in Destroylist and urlscan shows phishing behavior, the case gets much stronger. If Destroylist is clean, keep investigating. Absence from a blocklist does not clear the domain.

Use reputation tools as corroboration. They should not carry the finding by themselves. The stronger read comes from behavior, vendor or feed context, infrastructure overlap, and timing lining up.

DNS and ownership history with SecurityTrails

SecurityTrails is where I go after the page-level behavior starts to make sense. Current DNS tells you where the domain points right now. One frame only. Phishing infrastructure moves fast: A records change, nameservers rotate, Cloudflare or another reverse proxy appears and disappears, and registrant data is usually privacy-protected. Historical DNS and WHOIS show the movement.

I pull the live DNS set first: A, AAAA, CNAME, MX, NS, TXT, and SOA. Then I compare history. The questions are practical:

Did the domain resolve to a hosting provider commonly used in recent abuse?
Did it move between IPs immediately after registration?
Are the nameservers shared with other suspicious domains?
Did MX records appear even though the page is only a credential-harvest site?
Was the domain recently created, recently transferred, or recently changed?

SecurityTrails also helps separate ownership clues from hosting clues. A CDN may hide origin infrastructure, but nameserver history, old A records, or neighboring domains can still expose cluster leads. Treat old records carefully. An IP from months ago may belong to a different customer now, so historical co-location alone is weak grounds for blocking or attribution.

For the report, build the timeline. Do not stop at "domain resolves to IP X." Write the finding so another analyst can replay it cold: "reported at 14:22 UTC, first seen in urlscan at 14:31 UTC, current A record points to X, SecurityTrails shows nameserver change from Y to Z within the last day, and related domains share the same NS pattern." That is evidence. The shorter version is just a note.

Certificate transparency expansion with crt.sh

crt.sh searches certificate transparency logs, and that makes it useful during triage. I use it to find related hostnames when an operator has requested TLS certificates for several phishing subdomains or sibling domains. Search the suspicious domain, then inspect subject alternative names, naming patterns, certificate issuer, logged dates, and repeated host structures.

Suppose the reported domain is login-example-security[.]com. Certificate transparency might show account.example-security, verify.example-security, or other names built from the same lure vocabulary. It might also show wildcard certificates or short-lived certificates issued close together. None of that proves the names are malicious. It starts to matter when those names share content, hosting, nameservers, or timing.

Two crt.sh mistakes show up all the time. First, CT data is historical. A hostname in a certificate log may not resolve now. Second, certificates can include names tied to legitimate services, misissued records, or abandoned assets. Validate current DNS and current behavior before escalating a CT lead.

Use crt.sh to expand the search, not to decide the verdict. It gives you candidate infrastructure to test passively through urlscan, VirusTotal, SecurityTrails, and DNS history.

Campaign context through correlation

Campaign context comes from overlap. One phishing domain may be an isolated report. Ten domains with the same naming convention, nameserver pattern, favicon, redirect path, hosting ASN, certificate issuer timing, and form destination are a different case.

I keep a small pivot table while the details are still fresh:

Original domain and URL
Final landing URL
Redirect domains
Form post destination
IP and ASN
Nameservers
Registrar and registration date
TLS certificate subjects and SANs
urlscan page title and screenshot notes
VirusTotal and Destroylist status
Related domains from SecurityTrails and crt.sh

Then I look for reuse. Shared infrastructure alone is weak, especially on large hosting providers and CDNs. Better links are narrower: repeated lure paths, identical page titles, matching favicons, the same credential post endpoint, clustered registration times, narrow nameserver reuse, and repeated certificate patterns.

This is the point where the work starts helping defenders. Blocking the reported domain may stop one lure. A related cluster can support email gateway rules, DNS blocks, takedown requests, brand-monitoring queries, and watchlists for future registrations.

Pricing

This workflow mixes free public sources with paid or freemium services. Manual triage can live in the free interfaces for a while. A SOC with steady phishing intake usually needs quota, privacy controls, and API access.

urlscan.io offers public scanning and search access, with paid tiers for higher quotas, private scanning, API-heavy workflows, team use, and advanced collection options. The free tier works for occasional manual triage. Teams handling constant phishing reports usually need private scan capacity and API quota.

VirusTotal provides a public API and community access at no cost after account registration, while premium services are built for professional threat intelligence and high-volume automation. For this workflow, the free interface can support manual review. Bulk enrichment and SOC-scale pivoting usually require paid access.

SecurityTrails is freemium to paid. Its current commercial pricing page lists paid plans for larger query volumes and API access. Limited access can answer basic DNS questions. Historical DNS at volume, plus repeatable automation, is where paid access matters more.

crt.sh is free to use as a public certificate transparency search interface. It is valuable because it exposes CT data without a paid account. Treat it as a research pivot, not an enrichment service with operational guarantees.

Destroylist is maintained as a free phishing and scam domain blocklist/API feed by PhishDestroy. Its value is freshness and simple blocklist integration, not deep enrichment.

There is no single affiliate URL for this workflow because it combines multiple tools and free public resources.

Verdict

Good phishing-domain analysis is sequential and reproducible. Start with safe collection. Use urlscan.io for behavior and redirects. Use VirusTotal and Destroylist to see whether the domain is already known. Use SecurityTrails to reconstruct DNS and ownership history. Use crt.sh to expand certificate transparency leads. Then correlate before making the confidence call.

The workflow works because each source covers a different blind spot. urlscan can show behavior before reputation engines classify it. VirusTotal can surface community and vendor context that a sandbox render misses. SecurityTrails can reveal infrastructure movement hidden by current DNS. crt.sh can expose sibling hostnames. Destroylist can confirm that the domain is already part of an operational phishing feed.

The limitation is simple. None of these tools proves attribution or intent by itself. A parked page can turn malicious later. A shared IP can host unrelated customers. A certificate log can contain stale or benign names. A clean reputation result may only mean the domain is new. Write confidence levels, not absolutes.

For most operators, this is the right baseline: passive first, evidence-driven, and built to move from one suspicious domain to a defensible cluster view. Test everything. Trust nothing.

Quick-reference checklist

Preserve the exact reported domain, full URL, source, timestamp, and lure context before you normalize anything.
Do not browse directly until you understand the risk.
Search urlscan.io first; an existing scan may already contain the screenshot, redirects, and network trace.
If you submit to urlscan, choose visibility based on URL sensitivity and investigation risk.
Record the screenshot, redirects, final URL, contacted domains, form actions, IP, ASN, and page title.
Query VirusTotal for the full URL, domain, IP, and redirect targets.
Check Destroylist for operational blocklist presence.
Use SecurityTrails for current DNS, historical DNS, WHOIS history, nameservers, and hosting changes.
Use crt.sh for certificate transparency leads and related hostnames.
Validate CT and historical DNS leads before escalation.
Correlate infrastructure, redirects, page content, certificates, and timing. One overlap is not enough.
Categorize the result as benign/unclear, suspicious, confirmed phishing, or campaign lead.
Document confidence, evidence, and the recommended defensive action.