Phishing kits rarely sit on one clean hostname anymore. The whole point is to keep moving.
Two tricks show up over and over:
- wildcard subdomain routing
- fast domain churn
Put those together and the attacker can keep the same kit running while swapping out the public URL faster than most teams can react.
Wildcard routing lets one kit wear a lot of masks
A wildcard DNS or routing setup means one back end can answer a pile of hostnames. That makes it easy to spin up:
- campaign-specific subdomains
- one-off hostnames for individual targets
- brand-flavored variants
- different destinations based on region or referrer
From the attacker's side, it is cheap and flexible. From the defender's side, it means blocking one host may barely matter.
Domain churn resets the clock
The second move is simple. Burn through domains quickly.
That buys the operator a few things:
- fresh reputation
- temporary gaps in block coverage
- recovery after complaints or takedowns
- fallback options when one cluster gets burned
This is why fast replacement patterns matter. They are not random noise. They tell you somebody is actively maintaining the operation.
Hosted subdomains make this even easier
Attackers do not only use domains they bought themselves. They also lean on hosted subdomains from big platforms, especially when setup is fast or free.
Common examples include:
-
*.vercel.app -
*.workers.dev -
*.pages.dev -
*.netlify.app -
*.github.io -
*.web.app
You can see the appeal. No need to buy a fresh domain for every lure. Deployment is quick. The parent domain looks familiar. Rotation is cheap when one project or route gets removed.
Sometimes operators mix these hosted subdomains with their own domains in the same flow. A suspicious link starts on one host, bounces through another, then lands on a free hosting platform. That can fool teams that only look at the first hostname and think, "well, the platform is legitimate."
The platform is not the verdict. The path, redirects, page behavior, and credential flow still matter.
Log the overlap, not just the hostname
If a suspicious URL looks like it came from wildcard routing, log more than the host:
- the full path
- wildcard-like routing artifacts
- certificate SAN overlap
- DNS answer patterns
- shared asset paths
- shared JavaScript, CSS, or image fingerprints
- repeated form actions across domains
The goal is to identify the kit family, not just today's front door.
Exact-match blocking only gets you so far
This is the real shift:
- weak systems block exact hosts
- better systems cluster infrastructure
Once you can tie domains together through shared assets, cert patterns, form targets, analytics IDs, or exfil endpoints, the attacker has to do a lot more work to keep moving.
The useful question
Infrastructure on its own is not enough. Some wildcard setups are normal. Some fast-changing domains are harmless.
What matters is the overlap between infrastructure and behavior:
- brand impersonation
- credential prompts
- redirect weirdness
- hostile or evasive page behavior
That is when the picture gets clear.
The thing to remember
Many "different" phishing URLs are not different at all. They are the same kit wearing another mask.
LinkShield helps teams connect those dots so blocking decisions are based on clusters, not one-off strings. That is a much better way to deal with campaigns built to keep resurfacing.
