Last week one of us went to install Tailscale and stumbled into a phishing campaign that has been running for nine months, uses Binance Smart Chain's testnet as its command-and-control layer, hosts its malicious JavaScript on a public smart contract, and rotates infrastructure every few hours across multiple registrars and Cloudflare accounts. We spent four days mapping the campaign before publishing.

The user-facing story and the full technical write-up with IOCs are over on PerezBox and NOC respectively. This piece is about something narrower and, for security teams making defensive architecture decisions, more important: why protective DNS is the single highest-leverage intervention against this class of campaign, and why it has become the new front line of organizational security.

We will use the campaign as a worked example. But the argument is general.

What Every Defender Is Up Against

Most of the security stack defends against attacks the way it always has: identify malicious things, block them. Antivirus signatures, threat-intel feeds, browser warnings, email gateways, EDR rules. All of these depend on a defender first identifying that something is bad, then propagating that judgment to the products that enforce it.

This model worked when "bad things" were stable. A specific malicious binary had a hash that didn't change. A specific phishing domain stayed up for weeks. A specific C2 server had a known IP.

That world is gone.

The campaign we documented illustrates the new reality:

• Lure infrastructure rotates every few days. Old typosquats get taken down by registrars; new ones come up within hours.
• Payload infrastructure rotates every few hours. When one Windows payload host got suspended, the actor registered a replacement at a different registrar within 22 hours.
• The malicious content varies by visitor. Datacenter IPs see a clean editorial article; residential desktop browsers see the lure. Same URL, same minute.
• The authorization layer is on a blockchain. The actor approves individual victim IPs in real time via on-chain transactions. The list of approved victims is updated every two to three minutes. Defenders cannot take down a public smart contract.
• Researchers are filtered out by design. Cloudflare Turnstile, IP-reputation routing, headless-browser detection, and per-IP authorization mean the same researcher who finds the lure URL cannot easily observe its malicious behavior without already being on the actor's allowlist.

The defensive tools that rely on "identify bad, then block bad" are structurally outpaced.

Antivirus does not catch ClickFix because there is no malicious binary; the entire chain uses signed Microsoft and Apple utilities (rundll32.exe, cmd.exe, bash). Browser warnings do not catch fresh typosquats because the warning lists update on a delay measured in days, while the campaign measured in hours. Threat-intel feeds catch the IOCs eventually, but the actor has moved on. URL scanners cannot see the lure content because they run from datacenter IPs and get the decoy page.

Every layer of the conventional defense stack has its visibility deliberately limited by the campaign's architecture. The campaign is designed to defeat the existing toolset.

Where the Attack Actually Fails

Here is the thing that changes the picture: every single step of the attack chain depends on one prerequisite. The victim's browser must be able to resolve the lure domain. Without that lookup returning an IP, none of the rest of the attack happens.

• No DNS resolution → no TCP connection → no TLS handshake → no Cloudflare interstitial
• No Cloudflare interstitial → no Turnstile check → no lure HTML
• No lure HTML → no JavaScript execution → no fetch of the blockchain-hosted payload code
• No payload code → no clipboard injection → no malicious command planted on user's clipboard
• No clipboard injection → no Run dialog paste → no compromise

A single failed DNS lookup at the very front of the chain prevents everything downstream. The entire elaborate operation — the Cloudflare Turnstile cloaking, the blockchain authorization layer, the obfuscated JavaScript, the per-victim IP allowlist, the registrar-rotation tooling — is moot if the victim's device never resolves the lure domain in the first place.

This is what protective DNS does. It refuses to resolve domains that fit the pattern of a phishing operation, even when those specific domains have never been seen before by any blocklist.

What "Behavior-Based" DNS Protection Actually Means

The conventional model of DNS protection is blocklist-based: a list of known-bad domains is maintained centrally, and the resolver refuses to resolve anything on the list. This is the same "identify bad, then block bad" model that fails against the campaign we documented. New typosquats register, the blocklist doesn't have them yet, the resolution succeeds, the attack proceeds.

Behavior-based protective DNS doesn't ask "is this specific domain on a bad list?" It asks "does this domain look like a phishing operation, based on observable signals?" Among those signals:

Age of registration. A domain registered in the past 24 hours, attempting to impersonate a major software brand, is almost never legitimate. Real companies do not stand up their infrastructure on day-old domains. Attackers do, constantly, because their domain lifecycle is measured in hours, not years.

TLD reputation. The campaign we documented operates on .work, .us, .lat, .digital, .pics, and .co — TLDs chosen for low registration cost and lax abuse enforcement. Legitimate enterprises rarely use these TLDs for their primary infrastructure. A user trying to resolve tailsacle.work is statistically more likely to be the victim of a typosquat than the customer of a legitimate .work-using business.

Typosquatting distance. A domain that differs from a major brand's domain by one character transposition or replacement (tailsacle vs tailscale) is, by definition, a typosquat. Real brand owners do not register typosquats of their own domain as user-facing infrastructure.

Nameserver patterns. The campaign operates across at least three separate Cloudflare accounts. Each account is identified by the specific pair of nameservers Cloudflare assigns. Once a defensive resolver knows that jillian.ns.cloudflare.com + rick.ns.cloudflare.com are an active malicious operator's nameservers, any newly-registered domain that gets assigned those same nameservers is suspect by association.

Resolution behavior. Domains that recently rotated through suspicious infrastructure (suspended-domain nameservers, frequent IP changes, very low reputation hosting ranges) carry an elevated risk score.

A behavior-based resolver synthesizes these signals into a verdict at lookup time. The verdict can be "block" even if the specific domain has never been seen before. The lookup is denied at the network's edge, before any of the rest of the attack can fire. The user never sees the captcha. The browser never makes the request. The clipboard never gets injected.

This is what protective DNS does well that other defensive layers cannot do at all.

How It Fits Into a Layered Defense

Protective DNS is not a replacement for the rest of the security stack. It complements it. Different layers fail in different ways. Different layers catch different attacks. A complete defense stack uses several:

Layer	What it catches	What it misses against this campaign
Email gateway	Phishing email delivery	Search-result phishing doesn't go through email
Browser safe-browsing	Known-malicious URLs	New typosquats aren't on the list yet
EDR / antivirus	Malicious file execution	No malicious files; signed Windows utilities only
Network firewall	Known-bad IPs, port restrictions	Cloudflare-fronted; outbound to legitimate IP ranges
Threat intelligence	Known IOCs	Rotation faster than IOC propagation
Protective DNS	Suspicious domains at lookup time	(this is the layer that catches the campaign)

The argument is not that protective DNS replaces any of these. It is that protective DNS is the cheapest, earliest layer in the stack at which this specific class of attack can be reliably interrupted.

By "cheapest" we mean: the cost of running protective DNS is essentially a small fraction of any other layer's deployment cost, and the impact on user experience is minimal (a blocked lookup feels like a connection failure, not a security warning).

By "earliest" we mean: DNS is the first interaction the victim's device has with the attacker's infrastructure. Blocking at DNS prevents every subsequent interaction. Every other layer fires later in the chain, after the device has already begun engaging with the attack.

By "most reliable for this class" we mean: behavior-based DNS verdicts hold even when the specific IOCs are unknown, which is the case for all rotation-fast campaigns.

What Organizations Should Look for in a Protective DNS Provider

Protective DNS is now a meaningfully differentiated product category. When evaluating providers, several criteria separate the useful from the ornamental:

Behavior-based scoring, not just blocklists. A provider whose protection relies entirely on known-bad domain lists is functionally equivalent to a free public threat-intel feed. The differentiation is in pattern-based detection at lookup time — newly-registered domain heuristics, typosquatting detection, TLD reputation, NS-pair fingerprinting, infrastructure clustering.

Visibility into query logs. When a malicious lookup is blocked, your security team needs to know about it. Log retention, query attribution to specific endpoints, and integration with the rest of your security pipeline (SIEM, incident response workflows) matter.

Coverage of mobile, remote, and BYOD endpoints. Most organizations have devices outside their corporate network most of the time. Protective DNS that only works on the corporate network protects only a fraction of the attack surface. DNS-over-HTTPS or DNS-over-TLS resolvers configurable on the endpoint, with policy enforcement, are necessary.

Customization and override. Different organizations have different risk tolerances. The ability to whitelist specific domains, adjust category-level blocking, and tune the aggressiveness of behavior-based scoring is important for managing false-positive friction.

Privacy posture. The provider sees every DNS query your organization makes. Their data practices, log retention, and data-sharing agreements (especially with third parties or government) deserve scrutiny. Self-hosted or on-prem options exist for organizations with the highest sensitivity.

At CleanBrowsing, our protective DNS product is designed around exactly these principles. Behavior-based detection is the core technology. Newly-registered domain detection, typosquat scoring, TLD reputation, NS-pair fingerprinting, and several other heuristics run at every lookup. The campaign we documented would have been blocked at the DNS layer from the moment its lure infrastructure was registered — well before our threat-research team had ever seen the specific domain, much less added it to a blocklist.

We have free tiers for individuals and families, and paid tiers for organizations. We mention this here because we built it for exactly the threat model this campaign exemplifies. But the architectural argument stands independent of the product: any well-implemented behavior-based protective DNS would defeat this attack chain at its first step.

The Economic Asymmetry

Here is the final consideration. The campaign we documented costs the operator roughly ten dollars and ten minutes per domain rotation. Every time their infrastructure gets taken down, they spin up a replacement and resume operations.

Conventional defenses cost orders of magnitude more per increment of protection. New IOCs must be discovered by researchers, propagated to vendor products, tested for false positives, deployed to customer environments. The defender's cost-per-detection is high. The attacker's cost-per-rotation is trivial. The asymmetry favors the attacker.

Protective DNS inverts this. Once the heuristics are in place, every new typosquat the actor registers is automatically blocked without any incremental defender effort. The actor's rotation cost is the same as before, but the defender's incremental cost per new actor-infrastructure piece is zero. Whatever new domain comes up at NameCheap or Porkbun tomorrow, on whatever Cloudflare account, with whatever NS pair, gets the same evaluation against the same heuristics, and either gets blocked or doesn't. The economics now favor the defender.

This is the only place in the stack where the cost structure works in the defender's favor against high-rotation campaigns. It is also the layer at which the cost of being wrong is minimal: a false-positive blocked domain is annoying, not catastrophic. The user retries with the correct domain. By contrast, a missed detection on an endpoint detection product can mean a fully compromised machine.

Verifying DNS-Layer Protection Against This Campaign

To demonstrate how protective DNS handles the domains used in this campaign, here are live nslookup queries against CleanBrowsing's DNS resolvers (185.228.168.168). Each domain from the campaign is blocked at the DNS layer, preventing the attack chain from ever initiating:

% nslookup tailsacle.work 185.228.168.168
Server:    185.228.168.168
Address:   185.228.168.168#53

** server can't find tailsacle.work: NXDOMAIN

% nslookup tailsacle.us 185.228.168.168
Server:    185.228.168.168
Address:   185.228.168.168#53

** server can't find tailsacle.us: NXDOMAIN

% nslookup glokchapigui.co 185.228.168.168
Server:    185.228.168.168
Address:   185.228.168.168#53

** server can't find glokchapigui.co: NXDOMAIN

% nslookup herald5eventy.lat 185.228.168.168
Server:    185.228.168.168
Address:   185.228.168.168#53

** server can't find herald5eventy.lat: NXDOMAIN

% nslookup devharbor.pics 185.228.168.168
Server:    185.228.168.168
Address:   185.228.168.168#53

** server can't find devharbor.pics: NXDOMAIN

% nslookup mel2vrax.digital 185.228.168.168
Server:    185.228.168.168
Address:   185.228.168.168#53

** server can't find mel2vrax.digital: NXDOMAIN

Every domain in the campaign, whether the lure infrastructure, the Windows payload hosts, or the macOS payload host, returns NXDOMAIN through CleanBrowsing's protective DNS. The lookup fails at the front door. The browser never connects. The Cloudflare interstitial never loads. The clipboard never gets injected. The attack chain is broken at its very first step.

For organizations evaluating protective DNS, this is the simplest test you can run: point an nslookup at your DNS provider and query the known-bad domains from any active campaign. If they resolve, your DNS layer is not protecting you. If they return NXDOMAIN, the entire attack chain downstream is moot.

What to Take Away

The campaign we documented is not unusual in its sophistication anymore. It is approximately representative of what mid-sophistication phishing operations look like in 2026. Multiple infrastructure tiers, fast rotation, scanner evasion, multi-brand impersonation, blockchain-based persistence layers. These are not state-actor tradecraft. These are general-availability techniques being adopted across the criminal ecosystem.

The defensive stack that handled the previous decade of phishing — signature-based AV, IOC feeds, blocklists, email gateways — will continue to be necessary but is no longer sufficient. Without a behavior-based intervention point as early in the attack chain as possible, defenders are reduced to chasing IOCs across an exponentially expanding rotation graph.

Protective DNS is the cheapest, earliest, most architecturally clean intervention point. For most organizations, deploying it is a one-day project with negligible ongoing operational cost. For the campaign we documented — and for the next dozen like it that will emerge over the coming year — protective DNS is the difference between users encountering the attack and being protected by it.

If you read the user-facing story of how this campaign almost caught a security researcher mid-investigation, and you read the technical deep dive of how it operates, the natural question is "how do we stop the next one?" The answer most likely to scale across all your endpoints, all your remote workers, and all your BYOD reality is to make sure the malicious domain never resolves in the first place.

That is the simplest, most reliable, most cost-effective intervention available to defenders right now. It is what we build at CleanBrowsing. It is what we recommend organizations evaluate. It is the layer of the stack that is becoming, by structural necessity, the most important one.