Public methodology

How the public numbers are made.

This page explains what PhishNet collects, what it refuses to publish, how public counts are computed, how indicators are defanged, and how corrections are handled.

1

What we collect

PhishNet collects public, submitted, trusted, partner or explicitly authorized evidence and metadata. The public dashboard summarizes source families rather than exposing raw operational rows.

Phishing and infrastructureURLs, domains, DNS, TLS, RDAP, HTTP redirects, screenshots, page hashes and source/run provenance.
Malware and ransomware contextPublic feed metadata, hashes, families, group names, victim-sector metadata and lawful public leak-site references.
Fraud routesPhone, IBAN, wallet, handle, shortlink and messaging-route metadata where public, submitted or authorized.
Advisory and regulator sourcesRegulator warnings, vendor advisories, CVEs, public safety notices and open intelligence feeds.
2

What we do not collect

Public publication is intentionally conservative. The dashboard is not a place to expose victims, private communications, or attacker-enabling details.

No payment dataWe do not collect or publish card numbers, bank-login secrets or contents of payment sessions.
No private communicationsCitizen submissions are processed as evidence reports; identifying citizen information is not shown publicly.
No raw leak publicationRaw sensitive ransomware, credential or archive material is restricted and redacted by policy.
No active case detailsTakedown status, victim identity, subscriber names and law-enforcement handoffs remain authenticated.
3

How we count

Live evidence checks means an item was technically observed or corroborated in the current public-safe cut. All-time stored findings is a high-water corpus counter. Active campaign means related indicators share campaign-like structure, source overlap, timing, infrastructure or kit features.

Worked example: three defanged domains sharing certificate hash, page hash and source-run timing may count as three indicators and one campaign-like cluster. The public view shows the sector and country pattern, not the real brand target.

4

Time windows

Live threat board windows are computed in UTC. Live intake counters can update more frequently than the public daily board because they are public-safe movement indicators. Citable cuts are materialized separately so journalists and researchers can quote a stable number.

5

Defanging policy

Public examples replace dots with [.], remove protocols, and mask portions of domains when the visible string would help locate a working kit. Examples are illustrative and safe to copy into an article.

Example: secure-login-xx[.]eu shows the impersonation pattern without distributing a working phishing destination.

6

Withholding policy

We never publish specific brand names, victim identities, active case details, subscriber names, sanctions matches, unrestricted raw evidence, or fresh operational takedown state on the public dashboard.

The rationale is simple: public intelligence should inform citizens, journalists and decision-makers without helping attackers identify detection methods or live response activity.

7

Confidence and uncertainty

Confidence comes from source reputation, technical corroboration, recency, evidence depth and cross-source agreement. When confidence is not strong enough for public publication, the item may appear only as an aggregate review candidate or stay fully withheld.

8

Update cadence

Live intake counters are snapshot-first and can update throughout the day. The public dashboard is a citable daily cut. Research notes and quarterly reports are narrative layers built from the same public-safe data.

9

Corrections

Correction requests can be sent to stijn@galacticautomation.com. We review source provenance, public wording, counts and safety redactions, then update the affected public page or report with a correction note where needed.

PhishNet methodology · public-safe intelligence Live threat board · Embed · Reports · API