Newly registered phishing domains

In PhishDestroy analysis, a newly registered phishing domain is a registrable domain with a reliable registration timestamp that was first observed in a phishing evidence stream soon after registration. The phishing classification comes from the evidence. The age calculation only describes timing.

There is no universal number of days that turns a domain into a threat. Operational teams commonly create age bands because they help prioritize review, but the boundary is a policy choice. PhishDestroy uses the difference between the stored registration date and the first detection date, then shows that age alongside the underlying report.

The report uses two distinct clocks:

• creation_date: the registration event returned by registration-data collection, where available;
• detected_at: the timestamp when the domain entered the PhishDestroy threat record.

The operational calculation is:

The current public report also rejects a creation timestamp that falls after the detection timestamp. This guards against a common data-quality problem in which an update, transfer or renewal event is mistaken for the original registration event.

Why use age at detection?

A domain that is one year old today may have been only one day old when its phishing page was discovered. Measuring against today's date destroys that context. The evidence question is how much time elapsed between registration and the observed campaign.

Registration age belongs to the registrable domain, not automatically to every hostname beneath it. For example, a user-created hostname on a hosting platform can be new even though the platform's parent domain was registered years earlier.

This distinction also affects attribution. A malicious page on a shared platform does not make the platform the registrar of that user's hostname. Reports should separately identify the registrable domain, hosting platform, network provider and any independent registrar data that can be verified.

Age becomes valuable when it helps explain other observations. A defensible review can combine several independent layers:

High-value combinations

• A recent registration plus a browser capture of a copied wallet or exchange login.
• A new domain plus a redirect chain that ends on a credential or seed-phrase form.
• A new registration plus a reused phishing-kit title, favicon, DOM hash or infrastructure cluster.
• A domain created shortly before discovery plus independent threat-feed or vendor detections.

None of these combinations should replace review of the captured content. They prioritize and corroborate the case.

1. Using “last changed” as “registration.” RDAP defines multiple event actions, including registration, re-registration, transfer, expiration and last changed. They are not interchangeable.
2. Calling every subdomain newly registered. A platform hostname may have no independent registration event.
3. Treating missing registration data as age zero. Unknown is not new.
4. Measuring age against the review date. This conceals how young the domain was when first detected.
5. Using age as the verdict. Legitimate projects register new domains every day. Malicious actors also compromise old domains.

1. Resolve the registrable domain. Separate it from subdomains and URL paths.
2. Collect the registration event. Prefer structured RDAP data and retain the raw event type.
3. Record first observation. Keep the UTC time and source that introduced the threat record.
4. Validate the page safely. Use an isolated browser scanner and preserve the final URL, screenshot and relevant response metadata.
5. Check corroboration. Compare threat lists, brand indicators, infrastructure and repeated kit artifacts.
6. Classify confidence. Separate confirmed phishing behavior from suspicious registration patterns.
7. Revisit state without rewriting history. Record takedown, parking, ownership or content changes as later events.

The output should explain both why the domain was classified and how the registration age affected triage. That is more useful than a hidden risk score.

The public report renderer can use stored registration, detection and enrichment fields including:

• domain, detection timestamp and source record;
• registration and expiration timestamps;
• registrar, registrar country, nameservers and available abuse contacts;
• URLScan evidence, screenshot, redirect and final URL;
• VirusTotal, Safe Browsing, blocklist, OTX and URLQuery observations;
• target brand, kit, drainer, favicon and page-title indicators;
• DNS, IP, ASN, TLS, HTTP state and cloaking checks;
• reporting and later availability timestamps.

Not all fields are available for every record. Public copy should state the coverage boundary instead of filling gaps with generated assumptions.

Registration data can be unavailable, redacted or misinterpreted. A timestamp may describe re-registration rather than the first lifetime of a name. Detection time is also not campaign start time; it is the first observation available to the project.

The dataset is threat-focused and cannot provide a denominator for all newly registered domains on the Internet. It therefore cannot establish a global probability that any randomly selected new domain is malicious. That question requires a defined population, consistent sampling and comparable benign-domain data.