
Underminr Detection: DNS Says One Thing, TLS Says Another
The detection story for Underminr is actually pretty simple, which is why it is so annoying.
You are not looking for some magic evil packet. You are looking for the layers of the connection telling different stories.
Normal web traffic looks something like this:
DNS: I want goodsite.comDNS answer: goodsite.com is at 104.x.x.xTLS: I am connecting to 104.x.x.xSNI: goodsite.comHTTP Host: goodsite.com
Everything lines up. Boring. Fine.
Underminr-style traffic looks more like this:
DNS: I want goodsite.comDNS answer: goodsite.com is at 104.x.x.xTLS: I am connecting to 104.x.x.xSNI: sketchy-domain.aiHTTP Host: sketchy-domain.ai
That is the trick.
The machine uses an allowed domain to get a perfectly valid CDN IP, then reuses that IP to talk to some other tenant living behind the same CDN.
DNSSEC does not really save you here, because the DNS answer can be totally legitimate. DNSSEC can prove that the DNS answer was authentic. Great. Congratulations. The lie happens later, at the TLS / HTTP / CDN routing layer.
So the detector has to correlate things across layers:
What DNS name did this endpoint ask for?What IP did DNS return?What IP did the endpoint connect to?What SNI did it present?What HTTP Host header did it use?Did that hostname ever get resolved normally?
In other words, you are looking for this mismatch:
Resolved: harmless-site.com -> CDN edge IPConnected to: CDN edge IPClaimed SNI: evil-site.com
That is the “oh come on” moment.
The really cursed version is when the attacker splits it into steps. First they make a clean-looking connection to the allowed domain, then they come back to the same CDN edge IP and swap the SNI / Host header to the real target.
So detection has to remember recent DNS answers and recent CDN connections per machine. It is not enough to look at one packet in isolation.
The direct-to-IP version is even more annoying because there may be no DNS lookup for the bad domain at all. Then the question becomes:
Why is this machine connecting directly to a shared CDN IPwhile presenting an SNI / Host name that it never resolved?
That is suspicious as hell.
And with ECH, because of course we needed one more layer of pain, the real SNI can be encrypted. At that point you need endpoint visibility, controlled DNS, policy around HTTPS / SVCB records, or some way to block or strip ECH in managed environments.
So the whole thing boils down to this:
DNS says one thing. TLS / HTTP says another. The CDN accepts both because shared edge infrastructure is a haunted house.
Honestly, it feels like Dan Kaminsky may have faked his own death and come back on the dark side.
Obviously joking. Mostly.
But this is exactly the kind of DNS-adjacent, “everything technically works as designed and that is the problem” nonsense that makes the internet beautiful and horrible at the same time.
The practical detection rule is basically:
For each endpoint: remember recent DNS answers: allowed-domain.com -> CDN_IP watch outbound TLS / HTTP: endpoint -> CDN_IP:443 SNI / Host = some-other-domain.com alert if: the CDN IP came from a recent allowed DNS answer but the SNI / Host does not match that DNS name and the SNI / Host name was not separately resolved in a normal allowed way
That is Underminr detection.
Not “block the IP,” because the IP is probably Cloudflare, Akamai, Fastly, or some other giant shared CDN edge.
Not “DNSSEC fixes it,” because DNSSEC only proves the DNS answer was real.
The actual problem is that the trust decision was made on one name, and the connection was later used for another name.
It is a cross-layer trust bug.
The internet has a lot of those.
Because apparently we enjoy pain.
