当你以为域前置技术已经被各大 CDN 厂商彻底封堵时,一种更隐蔽、更危险的规避技术正在悄然兴起。ADAMnetworks 安全团队近期发现了一种被命名为 Underminr 的新型攻击手段,它能够绕过绝大多数基于防护性 DNS 的安全控制,让恶意流量伪装成通往可信域名的正常通信,为网络攻击打开了一扇新的后门。
什么是 Underminr 技术
Underminr 这个名字源自军事术语 "undermining",原指中世纪战争中攻击者在城堡城墙下挖掘隧道并引爆炸药导致城墙坍塌的战术。在网络安全领域,它形象地描述了攻击者如何在看似坚固的安全防线之下挖掘 "隧道",绕过防御体系直达目标。
从技术本质来看,Underminr 是一种利用共享托管生态系统特别是 CDN 共享边缘节点的流量滥用技术。它允许一个看起来指向可信域名的连接,实际上却连接到另一个完全不同的恶意域名。这种技术可以被用于命令与控制通信、虚拟专用网络、代理服务或者绕过网络出口策略,除非采取专门的缓解措施否则很难被检测到。
检测漏洞的核心在于,当 DNS 解析决策、边缘节点 IP、SNI (服务器名称指示)、HTTP Host 头以及 CDN 租户路由这几个关键要素没有被关联验证时,就会出现安全缺口。终端设备看到的是一个被允许的 DNS 查询结果,但实际建立的连接却指向了同一个共享边缘节点上的另一个托管域名。
Underminr 与传统域前置的区别
虽然两者最终效果相似,都能实现流量伪装,但它们采用的战术、技术和程序有着本质区别。
域前置通过在 TLS 握手的 SNI 字段中放置一个被允许的 "前端" 域名,同时在加密的 HTTP Host 头中嵌入真正的目标域名来实现伪装。由于早期许多 CDN 基于内部的 Host 头而不是外部的 SNI 进行路由,请求能够到达隐藏的目标,而网络观察者只能看到通往可信前端域名的流量。
关于域前置

Underminr 则采用了完全不同的欺骗逻辑。它强制客户端连接到从一个可信域名解析得到的 IP 地址,但在 TLS 握手时却发送同一个共享边缘节点所接受的另一个域名的 SNI 和 HTTP Host 头。关键的不匹配发生在 DNS 解析的目标地址与边缘节点实际路由的主机名之间。
协议层 | 域前置使用的域名 | Underminr 使用的域名 |
|---|---|---|
DNS | allowed-domain.cdn.com | allowed-domain.cdn.com |
SNI | allowed-domain.cdn.com | hidden-domain.cdn.com |
HTTP Host 头 | hidden-domain.cdn.com | hidden-domain.cdn.com |
值得注意的是,主流 CDN 提供商在 2018 年左右已经基本封堵了传统的域前置技术,大幅降低了其可用性。而 Underminr 利用的是共享边缘路由的另一个完全不同的滥用路径,目前尚未被广泛识别和缓解。

Underminr 的四种攻击模式
ADAMnetworks 团队已经观察到攻击者使用四种不同的 Underminr 攻击模式,这些模式可以单独使用也可以组合使用,能够有效绕过当前绝大多数安全配置。
- 简单模式
这种模式针对仅部署了 Protective DNS 和 DNS 强制策略的环境。攻击流程非常直接:
这种模式的检测依赖于将可信域名的 DNS 应答与后续连接的五元组、SNI、Host 头以及时间戳进行关联验证。

终端上的恶意应用程序对一个可信域名如whatismyipaddress.com发起 DNS A 类型查询
防护性 DNS 解析器返回该域名的 IP 地址如 [104.19.223.79](104.19.223.79) 并被终端缓存
恶意应用程序向这个 IP 地址的 443 端口发起 TCP 连接,但在 TLS 握手时使用欺骗性的 SNI 如 [evilsite.ai](evilsite.ai),而这个恶意域名恰好也托管在同一个 CDN 上并被该边缘节点接受
恶意内容从 [evilsite.ai](evilsite.ai) 返回给终端
终端与恶意服务器之间建立不受限制的连接,用于命令与控制、恶意载荷下载等活动
- 分离模式
这种模式专门用于绕过同时部署了 Protective DNS 和基于首包的 DPI (深度包检测) SNI 检查的环境。它通过分两步建立连接来欺骗检测系统:
由于大多数 DPI 设备只检查每个流的第一个数据包,第二个连接的欺骗性 SNI 往往能够绕过检测。理论上 CDN 提供商可以通过检测同一 IP 短时间内的多个不同 SNI 连接来发现这种滥用行为。

恶意应用程序首先对可信域名发起 DNS 查询并获得 IP 地址
它先向该 IP 地址发起一个使用可信域名 SNI 的 TLS 连接,通过只检查首包 SNI 的 DPI 设备
紧接着它向同一个 CDN 边缘 IP 发起第二个 TCP 连接,这次使用欺骗性的恶意域名 SNI
恶意内容通过第二个连接返回给终端
- ECH 模式
这种模式利用了 TLS 1.3 中的 ECH (Encrypted Client Hello) 扩展特性。ECH 原本是为了增强隐私保护而设计的,它将原本明文传输的 SNI 字段进行了加密。
当 ECH 被启用时,传统的 DPI 设备无法再从 TLS 握手中提取到明文的 SNI 信息。如果安全控制依赖于明文 SNI 来验证连接目标与 DNS 解析结果是否一致,那么这种控制就会完全失效。
攻击流程如下:
ADAMnetworks 已经在野外观察到利用 ECH 的 Underminr 攻击实例,包括通过社会工程学诱导用户粘贴并运行脚本的 ClickFix 攻击。

客户端获得一个包含 ECH 配置的 HTTPS/SVCB DNS 应答,这个应答可能来自被允许的域名或者绕过了官方解析器路径
客户端连接到返回的 CDN 边缘 IP 地址
外层的 ClientHello 只暴露 ECH 公共名称,而携带实际目标的内层 SNI 被完全加密
依赖明文 SNI 的安全控制无法比较解析名称与实际 TLS 目标是否匹配
连接在不暴露内层 SNI 的情况下顺利完成
- 直连 IP 模式
这种模式针对那些仅依赖 Protective DNS 而没有部署 DNS 强制策略,同时依靠 IP 黑名单进行防护的环境。由于主流 CDN 的 IP 地址几乎不会被加入黑名单,这种模式在很多企业网络中都能有效工作。
攻击流程最为简单:
在这种模式下,安全团队在事后调查中根本找不到任何关于恶意域名的 DNS 解析记录,大大增加了攻击溯源的难度。

恶意应用程序完全不进行任何可见的 DNS 查询,因此不会在 Protective DNS 日志中留下任何痕迹
它直接向已知的 CDN 边缘 IP 地址发起 TCP 连接,并使用欺骗性的恶意域名 SNI
恶意内容从该 SNI 对应的域名返回给终端
Underminr 技术的实际威胁
ADAMnetworks 已经在回收的恶意软件配置中观察到 Underminr 技术的实际使用。这种技术已经被多个APT组织采用。
这些组织将 Underminr 技术与 SoftEtherVPN 等工具结合使用,创建了难以检测的加密隧道。
Underminr 技术的广泛应用带来了多方面的严重威胁:
能够有效绕过基于 Protective DNS 的安全防护,包括同时使用 Protective DNS 和 Microsoft ZTDNS 的环境
提供了几乎不受限制的命令与控制连接能力,用于下载额外载荷、执行加密操作或者破坏活动
支持大规模的数据窃取,用于间谍活动、勒索或者知识产权盗窃
大幅降低了发起网络攻击所需的资源和技术门槛
特别危险的是,AI 生成的恶意软件可以轻松利用这种技术突破强化的安全环境
AI 编排的攻击可以大规模执行这种技术,在全球范围内 overwhelm 防御体系
Underminr 漏洞影响互联网生态系统中的多个参与方,没有任何一方能够完全置身事外。网络防御者精心构建的安全堆栈可能存在巨大的隐形漏洞;域名所有者的声誉会受到其所在共享基础设施上其他租户的影响;CDN 提供商的安全架构面临新的挑战;安全技术提供商的防护性 DNS 过滤功能可能被完全绕过。
针对 Underminr 技术的威胁,对于需要保持强安全态势的环境,推荐四项核心缓解措施:
部署网络分流器,监控所有指向 CDN 或共享托管 IP 的连接。特别关注那些 SNI 或 Host 值不在已批准解析器缓存中、与解析域名不匹配或者出现在批准 DNS 路径之外的连接。
将解析域名和欺骗性目标分开处理。使用解析域名列表识别被用作允许 DNS 路径的域名,使用 SNI 或 Host 检查识别实际的欺骗性目标域名。这是两个不同的安全工件,不应该合并到同一个黑名单中。
从域名的 HTTPS 和 SVCB 应答中剥离 ECH 扩展。这可以防止攻击者利用加密 SNI 绕过检测。
阻止已知的 ECH SNI 域名。如果 ECH 密钥通过官方 DNS 服务器之外的途径获得,阻止连接到已知用于 ECH 的 SNI 域名如cloudflare-ech.com。
IPv4 地址枯竭是一个无法回避的现实,这使得 CDN 不可能为每个公共服务提供专用 IP 地址。现实的解决方案是 CDN 提供商需要提供基于风险因素的客户隔离方案。Underminr 漏洞的曝光可能会成为推动整个行业改进共享边缘安全架构的重要动力。
参考:ADAMnetworks的《underminr》
声明:本文来自黑鸟,版权归作者所有。文章内容仅代表作者独立观点,不代表安全内参立场,转载目的在于传递更多信息。如有侵权,请联系 anquanneican@163.com。