Skip to main content

Phishing & URL Scanner

Overview​

Use Dralvia to scan a URL or domain and receive a risk score, signals, and evidence you can share with your team. The scanner focuses on web‑2 phishing and fraud indicators without active exploitation.

What it checks​

  • WHOIS age and registrar signals
  • DNS, MX, and SPF configuration
  • TLS certificate and security header posture
  • Redirect chains and landing behavior
  • Known threat feeds (when configured)
  • Visual/brand impersonation heuristics

How to run a scan​

  • UI: Open the URL & Phishing Scanner screen and submit a URL or domain.
  • API: Use POST /scan or POST /unified/scan with { "domain": "example.com" }.

Scan timing​

  • Fast scan returns the initial verdict first and typically finishes in tens of seconds.
  • Full deep scan waits for browser, replay, and visual review before returning the final score. Typical wait is 2-4 minutes and queue pressure can push that longer.
  • POST /unified/scan with a URL or domain runs the scan on the queue and waits briefly for the fast initial verdict. When it lands in time you get it in one 200 response (with analysis.result_state initial and the deeper browser, visual, and replay checks finishing in the background). If the first verdict is not ready within the short wait window, you get a 202 with a scan_id (and, for anonymous requests, a scan_token); poll GET /scan_status/<scan_id> until it reports a verdict, exactly like the async POST /scan flow. Either way the heavy scan never blocks your request.
  • Repeat scans of the same full URL can return a cached verdict during the freshness window. Safe, stable verdicts normally stay reusable for up to 30 days unless you explicitly request a fresh scan. Higher-risk, degraded, or redirected results use shorter freshness windows so stale evidence is not kept longer than needed.

The UI now uses queue-aware language so the pre-scan estimate and the in-progress estimate stay aligned.

Outputs​

  • Risk score + risk level
  • Flags for failed checks (e.g., missing HSTS)
  • Redirect timeline and HTTP header snapshot
  • EvidencePack (Dralvia's exportable evidence report) (when enabled)
  • Transparency log entry (when enabled)

Public research blog​

Dralvia also publishes public daily and weekly phishing research at https://blog.dralvia.tech when the autonomous digest has enough evidence. Blog posts are generated from the same scanner fact bundle used by the threat pipeline.

The digest facts are assembled by fixed software first. Dralvia may then use a small language model that runs on Dralvia servers to make the lead narrative read more naturally. That model can only rewrite the verified story. If it drops a number, changes a number, adds a number, times out, or returns unsafe wording, Dralvia discards the rewrite and publishes the deterministic wording instead. Because the model runs locally, a digest can appear later than the scheduled publish hour while the rewrite finishes or falls back.

Each published digest page has its own canonical URL, article metadata, social preview metadata, and sitemap entry. Daily and weekly posts focus on defender context such as impersonated brands, common lures, teams to brief, attack paths, and observed scan volume. Brand names describe copied trust cues or impersonation targets; they do not mean the real organization was breached.

If the lightweight render pass times out without producing a safe screenshot, Dralvia still attempts the deeper browser-capture pass before falling back to a generated safe placeholder preview. This keeps visual impersonation and replay surfaces populated more reliably on slow or unstable targets.

When earlier scan evidence already shows that a deeper browser review is needed, Dralvia skips the extra lightweight page visit and performs the deeper review directly. The result still exposes the same browser evidence fields, but risky pages are opened fewer times and deep scans spend less time repeating the same navigation.

If the deeper browser runtime itself degrades, for example because navigation fails before a trustworthy screenshot can be captured, Dralvia now attaches a safe remote preview mirror instead of leaving the visual impersonation surface empty. The replay and runtime notes still preserve that the isolated browser degraded, including cases such as proxy failures that end on about:blank.

Redirect interpretation​

Dralvia now treats redirect risk more narrowly:

  • redirect scoring increases when a chain crosses the registrable-domain boundary
  • same-site routing across the same registrable domain does not count as a phishing redirect by itself
  • pages that decode a hidden off-site destination in browser script can raise scripted-redirect evidence even when the first HTTP response is a normal 200
  • pages that decode a hidden meta-refresh document, wrap it in a Blob, and auto-click it are treated as scripted redirect wrappers
  • pages that fingerprint the visitor before a timed redirect can raise redirect-gate evidence, even when the first browser-side hop stays on the same domain
  • WordPress pages that execute JavaScript returned by a custom REST/admin-ajax endpoint can raise dynamic script-injection evidence
  • full IPFS gateway payload paths such as /ipfs/<CID> are treated as hosted-payload infrastructure; the bare gateway route is not

Example:

  • marketing.dralvia.tech -> blog.dralvia.tech stays within dralvia.tech
  • that hop can still appear in the timeline, but it should not gain suspicious redirect score just for moving between first-party subdomains

This reduces false positives for legitimate multi-subdomain product flows while still flagging redirectors that bounce users onto a different site.

Public dashboard threat surfaces​

The public dashboard is meant to stay useful between full workspace logins, so Dralvia now keeps the guest analytics lighter and more current:

  • Top Risky Domains is ranked from recent public high-risk activity instead of relying only on all-time counts.
  • Predicted Campaigns for guest mode uses recent public suspicious-signal and clustering data so the card stays populated even when workspace-style historical momentum is sparse.
  • Redirect Timeline can render both rich redirect hop traces and simple redirect-chain captures, so a valid redirect path is not dropped just because the lighter structure was stored.
  • Threat Graph now defaults to a smaller recent window and a narrower scan budget so interactive exploration does not degrade into proxy timeout errors as easily.

History retention behavior​

  • Recent scans keep the full result payload for replay and debugging during a short evidence window.
  • Long-term scan history is preserved even after raw payload compaction.
  • The default live-service target is a daily trim cycle with approximately a one-day raw-payload window before older scan_json / result_json blobs are removed from durable history.
  • Before raw payloads are compacted, Dralvia extracts scanner-learning signals, including detector-gap candidates such as redirect behavior that looks stronger than the final verdict.
  • If a backlog develops, Dralvia still trims stale raw payloads in bounded daily slices instead of waiting forever for a full historical re-extraction pass.
  • Older duplicate scans may keep a compact history payload instead of the full nested response. Score, risk, flags, host/target, and summarized check history stay available, but large screenshots and replay-heavy nested details are not retained forever.
  • Local database backups keep the scan-history metadata rows but do not preserve the raw nested scanner payloads.
  • Operators are alerted through the configured monitoring channel if the daily retention cycle stops succeeding or the autonomous scheduler heartbeat goes stale.

Campaign tagging (upcoming)​

Dralvia is rolling out autonomous campaign tagging, opt-in per workspace and off by default. When a workspace is opted in:

  • Campaign tags require at least two corroborating signals that are not a forbidden pair (registrar-only overlap, provider-default wildcard SAN certificate reuse, and infra + WHOIS overlap on a shared-hosting ASN do not qualify).
  • Domains on the workspace's allowlist are never tagged as campaign-related. Allowlist entries expire after 180 days by default and require an owner, reason, and actor. All changes are append-only audit events.
  • dralvia.tech and its registered subdomains are system-protected and cannot be tagged or removed through the workspace API.
  • Same-registrable-domain redirects (resolved via the Public Suffix List, so *.github.io and similar multi-workspace hosts are handled correctly) do not count as campaign activity.
  • Each tag carries a provenance stamp (pipeline_version, visual_model_version, classifier_version) visible in the analyst export.
  • When the autonomous pipeline is unreachable, campaign tagging is skipped and the result carries a "Campaign tagging degraded" banner rather than falling back to the legacy heuristic.
  • Historical scan rows that carry the pre-autonomous tags campaign:active_cluster or campaign:related_cluster remain visible but are marked legacy_heuristic in API exports and visually demoted in the Analyst Console. Autonomous-pipeline tags export as autonomous_pipeline_v1; degraded scans export as autonomous_pipeline_degraded.

The legacy links and websites heuristic no longer appends new campaign:active_cluster or campaign:related_cluster flags to fresh scan results. Historical rows keep those tags for export compatibility and analyst review, but new scans only receive campaign tags from the autonomous pipeline. While tagging is off for a workspace, campaign_tagging.shadow_mode stays true and autonomous tags are not merged into the live flags array.

Rollback and drill procedures are maintained by Dralvia support. If you need a rollback drill or evidence export for this feature, contact support with your workspace ID and the campaign/tagging window.

Autonomous campaign tagging is validated against a curated truth set before it is enabled for a workspace, so precision and recall stay within target and the workspace allowlist is never bypassed.

Scan responses now include two additive fields:

  • campaign_tagging: a provenance-stamped block describing the tagger's decision for the scan (feature_flag_enabled, shadow_mode, degraded, suppressed_reason, autonomous_tags, decorated_tags, primary_tags, demoted_tags, corroboration_score). The provenance sub-block stamps pipeline_version, visual_model_version, and classifier_version so downstream tooling can pin which model produced a tag.
  • campaign_tagging_degraded: a top-level boolean the Analyst Console uses to render the "Campaign tagging degraded" banner when the autonomous pipeline is unreachable.

Until a workspace is opted in, campaign_tagging.shadow_mode is true: the tagger computes the payload, preserves decorated legacy-history metadata, and never merges autonomous tags into the live flag list.

The autonomous tagger evaluates a fixed signal vocabulary derived from the existing scan enrichment (visual impersonation, brand/template flags, cross-registrable redirect chains, TLS certificate, WHOIS, DNS infrastructure, registrar). Provider-default wildcard certificates and recognized multi-workspace ASN markers are excluded from corroboration so shared-hosting overlap (Cloudflare, Vercel, Netlify, GitHub Pages, common CDNs) cannot, on its own, justify a campaign tag.

Limits and ethics​

Drill‑downs are passive (no exploitation). Only scan assets you own or are authorized to assess.