In this post, I will show you how to scan a URL and confirm a phishing page.
Pick the right scan depth, read the render rather than the reputation, and separate an impersonated brand you can evidence from one you are guessing at.
A user reports a link. Before you decide whether to block the domain, reset a credential or escalate, you need three answers: what the page actually serves, whether it is impersonating something, and whether it connects to malware you already know about. The URL scanner answers all three, but only if you choose the right depth and read the right panels.
If you are looking for a free malware analyzer that can also investigate suspicious URLs, MalwareAnalyzer provides the scanning depth and evidence needed to move beyond a simple reputation check.
BEFORE YOU STARTÂ Open the scanner at malwareanalyzer.com/scan. Do not paste a URL that contains a session token, password-reset token or API key into a public scan. Sensitive URLs are auto-scrubbed and forced private, but the safe habit is to strip the query string yourself and set visibility to Private first.
Table of Contents
1. Choose a scan depth deliberately
The Depth selector is the most consequential control on the page, and Standard is the default. The three passes collect genuinely different things.
Choosing the right depth is what makes a malware analyzer useful for phishing investigations: Fast works for triage, while Standard and Deep provide the additional evidence needed to investigate suspicious pages.
| Depth | What it collects | Reach for it when |
|---|---|---|
| Fast (static, sub-second) | Response headers, TLS certificate, favicon, the full redirect chain, referenced resources, and a verdict — all through an SSRF-locked fetcher, with no browser. | You are triaging a list, checking whether a domain is alive, or you need an answer inside a ticket SLA. Also the default for bulk scanning. |
| Standard (full render) | Everything in Fast, plus a headless-browser pass: screenshot, rendered DOM, HTTP transactions, cookies and console output. | Almost always, for a single reported URL. A phishing page is a visual and a form — you need to see it. |
| Deep (multi-vantage + files) | Everything in Standard, from multiple network vantages, plus retrieval and analysis of files the page serves. | The page is geo-fenced or cloaks by user agent, or it delivers a payload you need detonated. This is premium compute and spends credits. |
The deep-pass browser stage runs when a browser worker is attached; if the worker is unavailable, the report will show you the static evidence and say so rather than invent a render. Check for that before concluding a page was blank.
Visibility
Public (shareable) puts the scan in the public feed and makes the result linkable — the right choice for a commodity phishing kit you want on record. Private (account) keeps it out of the recent-scans list and the feeds entirely. Private and unlisted scans are never listed publicly.
2. Scan, then watch the result stream
Paste the URL and press Scan. Results arrive in stages: the first signal lands almost immediately, then the deep-pass enrichment fills in behind it. If you are driving this from a script, subscribe to the stream rather than polling:
# submit (public, no credential required)
curl -X POST https://malwareanalyzer.com/v1/scan \
  -H “content-type: application/json” \
  -d ‘{“url”:”https://suspicious.example/login”}’
# stream snapshots as they land (SSE)
curl -N https://malwareanalyzer.com/v1/result/<uuid>/stream
# or block until complete
curl -X POST “https://malwareanalyzer.com/v1/scan?sync=true” …
The full result at GET /v1/result/{uuid} is unmetered — verdict, screenshot, DOM, HTTP transactions, cookies, console, extracted IOCs and correlated malware. Fetching a completed scan costs you nothing, so there is no reason to cache aggressively or re-scan to re-read.
3. Read the scan in this order
The verdict line is the last thing to read, not the first. Work through the evidence in the order a page actually gets built.
- The redirect chain. Where did you actually end up? A benign-looking shortener, a compromised legitimate host, a traffic distribution system, and the final landing page are four different findings. Block the right layer.
- The TLS certificate. Issuer, subject, age, and any SAN entries. A certificate minted hours ago for a hostname that impersonates a decade-old brand is a strong signal on its own.
- The screenshot. Does it look like the brand it claims? Phishing is a visual crime; your eyes are a good detector and the screenshot is the only artifact you can put in a report that a non-analyst will immediately understand.
- The DOM and forms. Find the form. Read its action attribute. Where the credentials post to is the finding — a login form that posts cross-origin to an unrelated host, a PHP collector, or a Telegram bot API is credential harvesting, not a suspicion of it.
- HTTP transactions, cookies and console. Third-party script origins, tracking and fingerprinting calls, and console errors that reveal the kit’s file layout.
- Extracted IOCs and correlated malware. Hosts, paths and hashes, plus any malware sample in the corpus that references or is hosted by this URL. This is the bridge back to Part 1.
- The verdict and score. Now that you know what the page is, read the platform’s call and see whether it agrees with yours.
ON SCORES URL scores are not a 0–100 confidence percentage and can be negative — a well-established, well-behaved host scores below zero. Treat the score as a relative ranking signal for sorting a queue, and the verdict plus the evidence as the thing you act on. UNKNOWN genuinely means “nothing found either way”, which for a freshly registered domain is itself informative.
4. Confirm brand impersonation instead of assuming it
The scanner flags brand impersonation, homograph and lookalike hostnames, known phishing kits, and credential-harvesting forms, and it states the reason each was flagged. That reason is what turns a hunch into a finding, and the platform is careful about a distinction you should carry into your own writing:
- An evidenced impersonation means the page presents itself as the brand — the kit, the cloned login, the logo, the form target.
- A string-only reference means the brand name merely appears somewhere in the content or a sample’s strings. Malware naming a bank is not malware attacking that bank.
The brand hub keeps these split. GET /v1/brand/{brand}/malware returns malware linked to a brand’s impersonating domains split by evidence — attacks versus string-only references. If you are writing a customer notification, only the first column belongs in it.
The brand-attack directory
Brand attacks (/brands) ranks brands by the number of distinct domains observed impersonating them, with columns for impersonating domains, how many were flagged, total scans, the phishing kits identified, and when each was last observed. Kits are named where they are recognised — for example blackeye, u-admin (uadmin), generic paypal harvester, generic office365 harvester, or a branded crypto-exchange kit.
Two things about this table are easy to get wrong, and the page says both explicitly. The listed domains pretend to be those brands — the brand is the victim, not the operator. And the counts reflect what this platform has scanned, not global prevalence: a brand absent from the list is untracked, not unattacked, and a listed domain may already have been taken down. Point-in-time observation, and absence is not evidence of safety.
Brand data is available programmatically, and the directory endpoint is unmetered and cached:
GET /v1/brands            # ranked directory (public, unmetered)
GET /v1/brand/{brand}Â Â Â Â Â Â Â Â # every impersonating domain, deduped, with kits + verdicts
GET /v1/brand/{brand}/malware    # linked malware, split: attacks vs string-only
GET /v1/brand/{brand}/export/{fmt} Â # csv/json free; stix/misp use the daily allowance, then credits
5. Pivot from one page to the campaign
A single confirmed phishing page is rarely alone. Four moves take you from it to the rest of the set.
| Move | How | What it finds |
|---|---|---|
| Similar scans | POST /v1/urlscan/similar, or the similarity view on the scan | Pages matching on favicon, DOM structure, screenshot, certificate or hosting infrastructure — the same kit deployed elsewhere. |
| Structured search | GET /v1/urlscan/search, or the Search scans tab | Everything matching a facet: impersonates:, kit:, family:, verdict:, or sample:<sha256> for the URLs tied to one binary. |
| Retrohunt | POST /v1/urlscan/retrohunt | Historical scans that match a signature you only just wrote — how long the campaign has actually been running. |
| Standing watch | POST /v1/watches | A brand watch alerts you on each new impersonating domain as it appears, with notifications in-app, by webhook, Slack, Teams or email. |
Search syntax notes
- Results paginate with search_after; add facets=1 to get aggregate counts alongside the hits.
- key:* matches documents where a field simply exists — useful for “every scan that identified any kit at all”.
- An unknown filter is refused with a correction rather than silently ignored, so a query that returns zero results is a real zero, not a typo you did not notice.
Feeds, when you want this continuously
GET /v1/feed/newly-observed  # newly-observed public hostnames
GET /v1/feed/malicious     # detected malicious URLs
                               #  brand= filters on EVIDENCED impersonation; kit= and actor= also supported
6. Scan in bulk
Use the Bulk / file tab, or the batch endpoint, when you have a list — a mail-gateway export, the URLs from an extracted email, a takedown worklist.
curl -X POST https://malwareanalyzer.com/v1/scan/batch \
  -H “X-Api-Key: tl_live_…” -H “content-type: application/json” \
  -d ‘{“urls”:[“https://a.example/login”,”b.example”]}’
- You can submit urls[], or text from an uploaded file and let the endpoint extract them.
- A bare domain is normalised to https://domain/.
- Batch defaults to the fast pass. That is the right trade for triage, but it means no screenshot and no DOM — promote the interesting hits to a Standard or Deep scan individually.
7. Turn the scan into something usable
- Case file: the permalink plus the screenshot. Public scans are linkable by uuid.
- Machine ingest: GET /v1/result/{uuid}/stix returns a STIX 2.1 bundle for a completed public scan.
- Detection: the form target host, the kit fingerprint and the certificate details are better long-lived detections than the landing hostname, which will rotate by tomorrow.
- Blocking: block the layer you evidenced. Blocking a shortener because a phishing page sat behind it once will cost you more than it saves.
- Escalation: if the page harvested credentials and any of your users reached it, the finding is a credential-exposure incident, not a URL verdict. Reset first, document second.
Common mistakes
| Mistake | Why it bites |
|---|---|
| Reading UNKNOWN as clean | It means nothing was found. On a domain registered this morning, that is expected — and not reassuring. |
| Skipping the render on a single reported URL | The fast pass has no screenshot and no DOM, so you cannot see the clone or read the form target. |
| Naming an impersonated brand from a string match | The platform splits evidenced attacks from string-only references for a reason. Get this wrong in a customer email and you have made an accusation you cannot support. |
| Treating a brand’s absence from /brands as safety | The directory reflects what was scanned here, not global prevalence. |
| Blocking the final hostname only | Landing hostnames rotate hourly. Kit fingerprints, form targets and certificates last. |
| Pasting a tokenised URL into a public scan | Auto-scrubbing is a safety net, not a policy. Strip the query string yourself. |
Where this leaves you
Depth first, verdict last: MalwareAnalyzer gives you the evidence to understand what a suspicious URL actually does before you act on the verdict. Read the redirect chain, the certificate, the screenshot and the form target before you look at the score. A verdict without that reading is a guess with a number attached.
The habit worth keeping: don’t call a brand impersonated until the evidence — the cloned kit, the form target, the logo — actually says so. And don’t read UNKNOWN or a brand’s absence from the directory as safety. Both simply mean nothing was found yet. Block the layer you evidenced, not the hostname that happens to be live today.
INTERESTING POSTS
- Polymarket Bot in 2026: What Automation Can Do, and What Still Needs Your Hands
- 5 Ways To Identify Phishing Or Fake Websites
- Smart Home Security Tips That You MUST READ
- Surfshark Vs Ivacy: Which VPN Is The BEST?
- Windows Security Checklist for Installing a Desktop Messaging Client
- How to Verify Safe Messaging App Download Sources on Windows
About the Author:
Daniel Segun is the Founder and CEO of SecureBlitz Cybersecurity Media, with a background in Computer Science and Digital Marketing. When not writing, he's probably busy designing graphics or developing websites.
