On the morning of 13 August (UTC), someone submitted a link to my URL shortener tg.pe. The destination was validationreq.top, a domain I had never seen before. My automated checks flagged it the moment it came in, for a simple reason: the domain was too new.

Note: There’s also a Mandarin version of this post. 台灣朋友歡迎左轉 中文版。

75 minutes from registration to abuse

How new? RDAP, the public lookup protocol for domain registration data, settles it:

$ rdap validationreq.top
registration: 2026-08-13 02:12 UTC

# my own logs
submitted to tg.pe: 2026-08-13 03:29 UTC

This is the standard phishing playbook: disposable domains, registered and put to work immediately, burned and replaced. But newness is one of the easiest signals there is. Legitimate services rarely send out links on a domain registered less than two hours ago, so tg.pe distrusts very new domains by default. The link was flagged and contained automatically at submission, and within the hour it was returning nothing but 404s.

Cleaning up my own doorstep is the bare minimum, though. The phishing page itself was still alive, and copies of the link spreading through SMS, email or other shorteners would still hurt people. The real work starts here.

One button, and the scanners see nothing

The page impersonated flatmates.com.au, an Australian flatshare marketplace that bills itself as the country’s biggest: right branding, right layout, and nothing on it but a “Verify” button. Click it, and a form asks for your card details.

Everything an automated scanner sees: a brand mock-up and a verify button. urlscan’s verdict: score 0, no classification.

Here is the catch: the scanners in this chain do not click buttons. urlscan’s capture shows exactly that button and comes back with no classification at all; the page serves every visitor the same thing, it does not cloak for scanners, it simply keeps the payload one click away. I have no screenshot of the card form, and no scan I could find has one either; that page only appears after the click. This is how pages like this slip past automated detection, and why a pair of human eyes is still needed at the end. I clicked, saw the form, and classified it as phishing.

Reporting it to the right people

Next it went out to everyone who could act on it.

CIRCL MISP: MISP is the open-source threat-intelligence sharing platform; this instance is run by CIRCL, the CERT for Luxembourg’s private sector, communes and non-governmental entities. CERTs, SOCs and security vendors exchange indicators there as structured events that correlate automatically against other members’ data. I published the domain as a full event: registration time, behaviour, evidence, and later the takedown outcome. The community is not open to the public, so here is a screenshot.

The event on CIRCL MISP: indicators, taxonomy tags, and the takedown timeline added afterwards.

The registration layer: two parties can act on a domain itself. The registrar is the shop that sold the name; the registry runs the whole .top zone. I reported to the registrar via NetBeacon, the DNS abuse reporting relay, and emailed the .TOP registry’s abuse desk directly.

Infrastructure and browsers: the site sat behind Cloudflare, so their abuse form; Google Safe Browsing and Microsoft SmartScreen, which between them power the warning pages in every major browser; and Netcraft, whose phishing feed and takedown service reach a lot of places I cannot. I also emailed the impersonated brand’s security team.

Then the responses came in. Cloudflare moved fastest, blocking the reported URL in under half an hour. But every time I visited, this phishing page handed out a fresh random path, so blocking a single URL cannot keep up. That is not on Cloudflare; URL-level blocking is the wrong granularity for a site that changes paths on demand.

The kill came from the registry. At 09:46 UTC, about 3 hours 20 minutes after the report, the .TOP registry replied:

We have reviewed the provided domains and applied the serverHold status, effectively suspending their resolution.

serverHold is a registry-level freeze: the registry stops publishing the domain’s delegation, so the name drops out of the .top zone and stops resolving. The registration record still exists and the registry can lift the status, but for as long as it is set, the name is dead on the network. Not one URL, not one server. The whole domain.

$ rdap validationreq.top | grep status
status: client transfer prohibited, server hold

$ dig +short validationreq.top
(no answer)

.top has a certain reputation in the security community, usually associated with cheap bulk registrations and heavy abuse. This time its abuse desk replied and acted the same day, and that deserves to be said in public. For the record, the registrar-path report relayed via NetBeacon had drawn no reply by the time the registry acted. No reply is not the same as no action: a report that travels through a relay and then into a registrar’s own queue has more steps between me and whoever ends up handling it. It is one data point.

The timeline

All in one day, times in UTC:

• 02:12 validationreq.top registered
• 03:29 link submitted to tg.pe; flagged at submission
• 05:57 threat-intel event published on MISP
• 06:25 reports filed (NetBeacon, .TOP registry, Cloudflare, Google Safe Browsing, Microsoft SmartScreen, Netcraft)
• 06:47 Cloudflare URL-level block confirmed
• 09:46 .TOP registry confirms serverHold; the domain stops resolving

From registration to confirmed removal from DNS: 7 hours and 34 minutes.

Two months ago, I said I wanted to do this

In June, at TWIGF (the Taiwan Internet Governance Forum), I gave a lightning talk and told a story: a stranger in Germany emailed me about a fake parcel-delivery link on my service, and I verified it, removed it, and replied within 50 minutes. He was surprised, because in his experience the same report to a big platform disappears into a void. And I said what I wanted to do next: spot brand-new phishing domains the moment they are first used on my service, verify them by hand, and report them to the right people.

Two months later, it happened, end to end.

URL shorteners occupy a strange position in the reporting chain: attackers hand you their freshest links themselves. Scanners have to comb the entire internet for phishing pages; I only have to watch my own submission queue. This domain went from registered to flagged in 75 minutes, not because I scan faster than anyone, but because the attacker brought it to me.

The honest disclaimer, as always: this is one case, not a statistic. The previous loop like this took eight days to close, and some reports sink without a trace. Killing one domain in a single day does not prove that reporting usually works. It proves the path exists, and that sometimes it is astonishingly fast. The full reporting record and numbers are in tg.pe’s transparency report.

Appendix: how tg.pe screens every link

tg.pe is a free URL shortener run by one person. Every submitted link passes through these gates:

• Before it goes live: the destination is checked against local blocklists and a high-risk list; its domain age is looked up, and very new domains are distrusted by default; it is screened against Google Safe Browsing; and suspicious ad-redirect patterns are held for observation.
• After it goes live: a background VirusTotal scan can restrict the link automatically; suspicious destinations get evidence captured automatically (screenshot and redirect chain); and links that have not been checked for a while are re-checked on their next click.
• Always: abuse@tg.pe takes external reports, triaged by hand; destinations confirmed malicious are reported onward to the parties that can act, exactly as this post describes.

The design, the numbers and the limitations are all in the same transparency report, including the parts that do not work yet.