Why phishing scanners disagree

Phishing scanners disagree because they are not repeating one identical test. Each service has its own input, collection time, browser environment, data suppliers, thresholds and vocabulary. “No match” usually means that a specific source had no matching record at the recorded time. It does not mean that the site was proven safe.

These states are intentionally separate in PhishDestroy reports. A missing value, a recorded zero and a positive detection are not interchangeable.

No single product sees the whole event. The table below describes the role of the sources used in our domain reports, based on their published documentation.

A phishing page can be deployed, changed and removed faster than every downstream service can collect and publish the same state. One source may hold a screenshot from the live campaign. Another may query the host after it redirects to a parking page. A third may receive the malicious classification hours later from a partner feed.

For that reason, PhishDestroy stores timestamps beside evidence whenever the source provides them. The relevant comparison is not simply “Vendor A says malicious and Vendor B says clean.” It is:

1. Which URL did each source examine?
2. When was the observation collected or last synchronized?
3. Did the request reach the same final URL?
4. Was the page still available at that time?
5. Was the result a browser observation, a list lookup or an aggregate vendor verdict?

A later clean page does not erase an earlier forensic capture. Likewise, an old malicious result does not establish that the current registrant or current content is still malicious. Both statements require timestamps.

example.test/login, secure.example.test and example.test are related, but they are not identical scan targets. A vendor can list one path while another tool checks only the hostname. Redirects add another layer: the submitted URL and the page finally rendered by the browser may differ.

Common scope mismatches

• Path-specific phishing: the malicious form exists only below a deep URL.
• Subdomain abuse: one hostname is malicious while the parent service hosts unrelated users.
• Redirect delivery: the first host is an entry point and the credential form is served elsewhere.
• Registrable-domain checks: a domain-level lookup may not execute or inspect every web page.
• Changed ownership: historical evidence and current control can refer to different periods.

Our public report is organized around a hostname while preserving URLScan identifiers, redirect evidence, screenshots and final-URL fields where available. The report should be read as a timeline of stored observations, not as a promise that every URL under the hostname behaves identically.

Some delivery systems vary content by geography, referrer, user agent, cookies, session state, IP reputation or time. A victim arriving through an advertisement may see a wallet connection prompt, while an automated scanner receives a blank page or a legitimate-looking decoy.

Browser scans help because they preserve what one environment actually received. They still represent one vantage point. Cloudflare's URL Scanner documentation, for example, distinguishes the submitted URL from the final URL and supports location-specific scanning in eligible configurations. URLScan similarly records the final primary request after redirects.

PhishDestroy combines independent evidence layers rather than converting every field into one pretend consensus. Depending on availability, a report may contain:

• first-observed and last-checked timestamps;
• stored screenshots and browser-scan identifiers;
• VirusTotal detections, total scanners and contributing vendor names;
• Google Safe Browsing and public-blocklist observations;
• OTX pulses, URLQuery results and Cloudflare Radar scan links;
• HTTP state, redirects, DNS, IP, TLS, registrar and registration dates;
• page title, favicon, detected brand, kit or drainer labels;
• cloaking indicators and the time of that check;
• notification and stored abuse-report records.

Not every report has every field. “Unknown” means the archive does not have a defensible observation for that field. It must not be translated into “safe,” “absent” or “zero.”

1. Normalize the target. Record the full submitted URL, hostname, registrable domain and final URL.
2. Freeze the time. Save UTC timestamps for each lookup and browser capture.
3. Preserve direct evidence. Keep the screenshot, DOM or response metadata when collection is lawful and safe.
4. Separate observation from inference. “The page requested a seed phrase” is an observation. “The registrant controls another campaign” requires separate support.
5. Check independent layers. Compare browser behavior, list membership, registration data and infrastructure.
6. Re-check safely. A repeat scan can show change, but do not interact with forms, connect a wallet or submit personal data.
7. Document uncertainty. State what was unavailable, not checked or observed only once.

This process does not guarantee a perfect verdict. It makes the reasoning auditable and allows a later reviewer to distinguish a true disagreement from a simple timing or scope mismatch.

Automated systems can miss threats and can produce false positives. Screenshots can be incomplete. Registration data can be absent or stale. A domain can also change content or ownership after the archived observation.

PhishDestroy therefore exposes evidence dates and provides an appeal process. A correction should identify the domain, the disputed field and evidence supporting the requested change. The historical record may remain relevant even when the current status changes, but current and historical statements must be clearly separated.