Hackers Abuse Shared CDN Edge IPs to Bypass Protective DNS Filtering

Attackers are abusing shared CDN and hosting infrastructure to make malicious traffic look like it belongs to trusted websites. The technique, called Underminr, can bypass protective DNS filtering when security tools allow one domain but fail to verify that the later TLS connection, SNI value, HTTP Host header, and CDN routing target still match.

ADAMnetworks’ technical write-up says the gap appears when an endpoint first resolves an allowed domain, then connects to the returned shared CDN edge IP while presenting a different hostname that the same edge can route. That lets traffic appear linked to a trusted domain while the real destination can be a malicious site on the same shared infrastructure.

The finding matters because many companies rely on protective DNS as a first line of defense. If DNS logs show only a permitted domain, defenders may miss the fact that the encrypted connection reached another tenant on the same CDN edge.

How Underminr Bypasses DNS-Based Security

Protective DNS works by blocking lookups for domains known to be malicious and allowing domains considered safe. Underminr attacks the assumption that the domain resolved through DNS is the same destination later used in the encrypted connection.

In a simple example, a system resolves a trusted domain and receives a CDN edge IP. The malicious client then connects to that same IP but uses a different SNI and Host value associated with a malicious domain also accepted by the CDN edge.

The SecurityWeek report describes Underminr as a variant of domain-fronting-style abuse, but with a different path. Instead of relying on the old SNI and Host mismatch pattern, it forces traffic to the IP address of one tenant while presenting another hosted name on the same shared edge.

Underminr Attack Modes at a Glance

Mode	How It Works	Defensive Blind Spot
Simple Mode	The endpoint resolves an allowed domain, then connects to the shared edge IP using a deceptive SNI for another domain.	DNS filtering sees the allowed lookup, but the connection can reach another CDN tenant.
Split Mode	The client first opens a benign TLS connection, then makes a second connection to the same edge IP with a deceptive SNI.	First-packet-only SNI inspection may approve the first flow and miss the switch.
ECH Mode	Encrypted Client Hello hides the inner SNI from passive inspection.	Security tools cannot compare visible DNS activity with the effective hidden TLS destination.
Direct-to-IP Mode	The client connects directly to a CDN edge IP and uses a deceptive SNI or Host value.	No DNS query for the hidden malicious domain appears in resolver logs.

Why Shared CDN Edge IPs Create the Risk

CDNs and reverse proxies often host many customer domains on the same edge IP addresses. This design saves IPv4 space, improves performance, and makes large-scale hosting practical.

The problem appears when routing decisions on the shared edge do not bind the DNS-resolved domain, SNI, Host header, and tenant identity tightly enough. In that situation, the edge may serve a different hosted domain than the one a security stack approved through DNS.

ADAMnetworks’ impact report says 1,971,670 domains in its reviewed reporting population mapped to CDN or shared-edge providers, and 88.1% of those mapped to providers or ASNs that produced a vulnerable SNI deception result.

Why This Is Not the Same as Old Domain Fronting

Domain fronting became widely discussed years ago because it let attackers or censorship-circumvention tools place a trusted domain in one layer of a request and a hidden destination in another. Major providers largely curtailed that old pattern around 2018.

Underminr differs because it focuses on the relationship between a DNS-resolved edge IP and another tenant accepted by the same shared edge. The attacker does not need the old fronting pattern if the security stack fails to correlate the allowed DNS event with the final SNI, Host, and CDN routing target.

The ADAMnetworks technical page says the method can support command-and-control traffic, VPN or proxy connections, payload delivery, data exfiltration, and network egress policy circumvention.

Potential Scale of the Problem

Measurement	Reported Figure
Broadly referenced potential exposure	Roughly 88 million domains
Reviewed domains mapped to CDN or shared-edge providers	1,971,670
Share of reviewed shared-edge domains on providers with vulnerable SNI deception results	88.1%
Vulnerable provider or ASN results	33 ASNs
Top vulnerable provider in ADAMnetworks’ table	Cloudflare, 1,281,217 reviewed vulnerable domains in the provider row

The scale figures need careful reading. They do not mean every domain has been attacked or compromised. They show how many domains may sit in hosting environments where this class of cross-tenant routing abuse can matter.

ADAMnetworks’ announcement described Underminr as a shared-hosting vulnerability that can let attackers bypass security protections and compromise websites. The company also warned that AI-assisted malware could make this technique easier to scale if defenders do not correlate network events more tightly.

What Attackers Can Do With Underminr

Underminr can give attackers a stealthier channel after they already control code on an endpoint. That code could come from malware, a malicious script, a user-installed circumvention tool, or a ClickFix-style social engineering attack that tricks a user into running a command.

Once the attacker has execution, the technique can help hide outbound communication. The endpoint can appear to contact a trusted or allowed domain, while the actual traffic routes to infrastructure controlled by the attacker.

The behavior overlaps with MITRE ATT&CK’s Protocol Tunneling technique, where attackers encapsulate communications inside another protocol to evade detection and maintain access. In Underminr’s case, the abuse relies on CDN routing, TLS metadata, and DNS visibility gaps rather than only a traditional tunnel.

Why Protective DNS Alone Is Not Enough

Protective DNS remains useful, but Underminr shows why it cannot work alone in every environment. DNS tells defenders what name a device requested. It does not always prove what hostname the TLS session later used or what tenant the CDN edge ultimately routed to.

This gap matters most in environments that rely on DNS filtering without DNS enforcement, full proxying, or connection-level correlation. Direct-to-IP mode creates an even larger blind spot because the hidden destination may never appear in DNS telemetry.

The SecurityWeek coverage notes that Underminr can hide command-and-control, VPN, and proxy traffic behind trusted domains and that it can affect roughly 88 million domains at the broader infrastructure level.

Defense Requires Correlation, Not Just Blocklists

Defenders should compare DNS activity with connection metadata. A device that resolved a trusted domain should not later use the returned CDN edge IP to present an unrelated SNI or Host value unless that pattern has a clear business reason.

Security teams should also separate “resolved domains” from “deceptive destinations.” Blocking the trusted domain alone may create major business disruption, while blocking only the hidden destination may miss the way attackers reach it.

The Underminr impact report also shows that vulnerable and non-vulnerable provider results vary by CDN or hosting provider. That means organizations need environment-specific testing instead of assuming all shared CDN infrastructure behaves the same way.

Practical Steps for Network Defenders

• Correlate DNS resolver logs with destination IPs, SNI values, HTTP Host headers, and timing.
• Flag CDN edge connections where the SNI or Host value does not match a recent approved DNS resolution.
• Detect direct-to-IP connections to CDN infrastructure when no related DNS lookup exists.
• Inspect or restrict ECH where policy and privacy requirements allow it.
• Separate allowlists for domains from allowlists for CDN edge IP behavior.
• Use full proxying or strong egress controls for high-risk environments.
• Work with CDN providers to bind SNI, Host, account, and routing behavior more tightly.

The MITRE Protocol Tunneling entry is useful for defenders building detections because it frames the broader tactic: attackers hide traffic in protocols or services that defenders may allow by default.

Underminr also gives domain owners a reputational problem. A trusted domain can appear in DNS logs tied to suspicious activity even if the domain owner did not host malware, because its CDN edge IP may have helped route traffic to another tenant.

What Domain Owners Should Check

Domain owners using shared CDN or reverse proxy infrastructure should test whether their domains can become part of an Underminr path. If a domain returns a positive result, the owner may need help from the CDN provider because the weakness often sits in edge routing behavior.

ADAMnetworks has launched a public checking tool and a threat intelligence-sharing effort for defenders and domain owners. The tool classifies domains based on whether current provider-specific checks return an Underminr result and whether the domain appears in known abuse data.

The company’s public announcement says the issue affects internet infrastructure at scale because shared hosting and CDN edge reuse have become common across the modern web.

Why This Matters Now

IPv4 scarcity has pushed more services onto shared infrastructure. That trend makes CDN edge reuse normal, but it also increases the chance that one tenant’s trusted domain can sit beside another tenant’s malicious or compromised domain on the same edge address.

Underminr does not make DNS filtering useless. It shows that DNS filtering must connect to broader network telemetry. DNS allow decisions need follow-up checks against the actual TLS and HTTP destination behavior.

For security teams, the message is clear: trusted domains, shared edge IPs, and encrypted traffic need stronger correlation. Attackers will keep looking for places where one security control sees only part of the connection.

FAQ