Technical Details

Terms

About the term Underminr

Conceptually inspired by a fictional supervillain who operates underground to tunnel beneath cities, rob banks, cause structural collapse, and generally sow chaos and destruction. Undermining is a military term tracing back to medieval times, when attackers would tunnel beneath castle walls and ignite fires or explosives to cause a structural collapse. This conceptually describes the intent of any adversary using the techniques detailed here.

Underminr Adversarial Impact

The Underminr vulnerability could be used for any or all of the following reasons in adversarial campaigns:

• ●Effective defense evasion of PDNS-based security
• ●Effective detection evasion (including when PDNS+Microsoft ZTDNS are both in use)
• ●Effective Persistence with impunity
• ●Unrestricted access to C2 connections for additional payloads, encryption, or destruction
• ●Data exfiltration for espionage, extortion, or intellectual property theft
• ●Greatly reduced efforts and resources required for launching adversarial campaigns
• ●AI-generated malware can easily defeat hardened security environments
• ●AI-orchestrated attacks can execute and scale to overwhelm security worldwide

Technical Background

About Domain Fronting

Domain Fronting is a circumvention technique that exploits how HTTPS connections and content delivery networks (CDNs) handle domain names in different protocol layers. In a standard HTTPS request, the Server Name Indication (SNI) extension in the TLS handshake and the visible connection target typically match the domain being accessed, allowing censors to block based on that name; however, domain fronting deliberately mismatches them by placing an allowed "front" domain (such as a popular CDN-hosted service like google.com or cloudflare.com) in the SNI and TLS certificate validation fields while embedding the true, potentially blocked target domain in the encrypted HTTP Host header inside the TLS tunnel. Because many CDNs used to route requests internally based on the Host header rather than the outer SNI, the request reached the intended hidden destination, while passive network observers – including censors – see only traffic to the reputable front domain, making indiscriminate blocking costly due to collateral damage to legitimate services.

By way of an illustration, here's how Domain Fronting used to work and is largely mitigated now:

Major providers largely curtailed this legacy technique by 2018, which significantly reduced its viability. The shared-edge routing issue tested by Underminr is a different abuse path.

How Domain Fronting differs from Underminr

Underminr circumvention differs from legacy Domain Fronting by forcing a request to the IP address resolved for one domain while presenting the SNI and HTTP Host of another tenant on the same shared edge. The operative mismatch is between the DNS-resolved destination and the hostname the edge actually routes:

Underminr TTPs

While measures taken by CDNs have made domain-fronting mostly ineffective today, the Underminr vulnerability leverages four distinct strategies to circumvent PDNS as a security layer.

The attack is launched by a malicious application or even a simple shell script on an endpoint that is within a secured network. This could include (but is not limited to):

• User sanctioned application for purposeful circumvention
• Clickfix attack (user is social engineered to paste a script and run it on their endpoint)
• Intentional Malware

By utilizing any single method, or a strategic combination of the following 4 Underminr methods the adversarial application can adapt to effectively defeat any of the following security configurations:

Let's explore the various modes.

1. Simple Mode

With this approach, detection depends on correlating the DNS answer for the allowed domain with the later connection tuple: destination IP, SNI, Host header, and timing.

1. Malicious Application on Endpoint does a DNS type A query for whatismyipaddress.com
2. Answer returned protective DNS resolver and cached as 104.19.223.79
3. Malicious Application on Endpoint makes TCP connection to 104.19.223.79 port 443 but uses a deceptive SNI of evilsite.ai which is also hosted & accepted by the same CDN.
4. Malicious content is served back to endpoint from evilsite.ai
5. Unrestricted connectivity for C2, malware payload. Policy circumvention etc between endpoint and server at evilsite.ai

2. Split Mode

In split mode, the client first opens a TLS connection using the trusted SNI to satisfy first-packet SNI inspection. It then opens a subsequent connection to the same CDN edge IP using the deceptive SNI:

1. Malicious Application on Endpoint does a DNS type A query for whatismyipaddress.com
2. Answer returned protective DNS resolver and cached as 104.19.223.79
3. Malicious Application on Endpoint makes TCP connection to 104.19.223.79 port 443 but uses the SNI of whatismyipaddress.com which passes DPI that does first-packet-only check
4. Malicious Application makes subsequent TCP connection to 104.19.223.79 port 443 but substitutes a deceptive SNI of evilsite.ai which is also hosted & accepted by the same CDN
5. Malicious content is served back to endpoint from evilsite.ai
6. Unrestricted connectivity for C2, malware payload or policy circumvention etc. between endpoint and server at evilsite.ai

With Split mode, the CDN provider could potentially detect this abuse.

3. ECH Mode

In traditional Deep Packet Inspection (DPI), the SNI header is used to identify the hostname in clear text without decrypting the TLS payload. ECH is not a DNS bypass by itself. Its effect is narrower: it removes the inner SNI from passive network inspection. If a DNS event is allowed, missed, or obtained outside the approved resolver path, defenders cannot rely on visible SNI to verify that the resolved name and final TLS destination still match.

1. The client obtains an HTTPS/SVCB answer containing ECH configuration for a name that is allowed, uncategorized, or obtained outside the approved resolver path.
2. The client connects to the returned CDN edge IP.
3. The outer ClientHello exposes the ECH public name, while the inner SNI carrying the effective destination is encrypted.
4. If controls depend on cleartext SNI, they cannot compare the resolved name to the effective TLS destination.
5. The connection can then proceed without exposing the inner SNI to passive inspection.

4. Direct to IP Mode

This is useful to the adversary when the endpoint relies on PDNS only without a DNS enforcement element (ZT DNS or DTTS) but relying on blocklisting malicious IPs (well-used CDN IPs are rarely blocked). This mode targets environments where DNS policy exists but clients can still connect directly to IP addresses. No resolver event is created for the hidden destination; detection depends on identifying CDN-edge connections whose SNI or Host value is not backed by a recent allowed DNS resolution.

1. Malicious Application on Endpoint operates in stealth mode because it never makes a DNS query visible to the PDNS resolver
2. Malicious Application on Endpoint makes TCP connection to 104.19.223.79 port 443 but uses a deceptive SNI of evilsite.ai which is also hosted & accepted by the same CDN.
3. Malicious content is served back to endpoint from evilsite.ai
4. Unrestricted connectivity for C2, malware payload. Policy circumvention etc between endpoint and server at evilsite.ai

Impact

Mitigation

By Technology Providers

By Domain Owners

Network defenders of mission-critical operations will be forced to deny access to domains that could be abused as part of Underminr circumvention attacks. This will deny access to legitimate use of such trusted domains and erode the reputation of these domains.

The abuse of trust for well-recognized domains will harm brand reputation for brand owners.

DNS resolution forensics that are done post breach that used an Underminr attack as part of the attack chain will name the trusted domain as part of the attack.

Inspecting an owned domain on the Online Application https://underminr.ai will yield one of the following 3 results in public view:

• Green: The current public check did not return a positive Underminr result for the domain.
• Yellow: The domain returned a positive Underminr test result, but is not in the known abused list.
• Red: The domain returned a positive Underminr test result and is in the known abused list.

If their website is in the yellow or red list, as a domain owner, you have the option of either:

• have the CDN operator remove the vulnerability
• move the web/app hosting to another environment

By Network Defenders

The focus on this section is for Sovereign Data Custody environments, expecting a strong security posture regarding egress control without the use of a proxy.

• 1. Designate a network tapMonitor for connections to CDN or shared-hosting IPs where the SNI or Host value is absent from the approved resolver cache, differs from the resolved domain, or appears outside the approved DNS path. For the benefit of the entire industry, ADAMnetworks is offering a tool and data exchange protocol to identify domain names that are being used by underminers as well as actual threat connections. This allows participants to make decisions on how to maximize the practicality of such rules. To use the example above, the tool produces two lists:

  Resolved Domains

  e.g.: whatismyipaddress.com

  Deceptive Destinations

  e.g.: evilsite.ai

• 2. Treat resolved domains and deceptive destinations separatelyUse the resolved-domain list to identify domains being used as the allowed DNS path. Use SNI or Host inspection to identify deceptive destination domains. These are different artifacts and should not be collapsed into one blocklist.
• 3. Strip ECHStrip ECH from domain HTTPS and SVCB answers.
• 4. Block known ECH SNI domainsIn the event the ECH key is obtained elsewhere then designated DNS server, block connections to known SNI domains used for ECH (e.g. cloudflare-ech.com).