1. 攻击手法深度解析：DNS CNAME如何成为Kerberos中继的"暗门"
1.1 CNAME记录在AD环境中的特殊地位
活动目录(AD)环境中，CNAME记录远不止是简单的别名功能。作为微软官方推荐的资源定位方式，CNAME在AD集成DNS中承担着关键服务发现职责。当客户端查询_service._tcp.example.com这类SRV记录时，背后往往存在CNAME重定向链。攻击者正是利用这种设计特性，通过劫持CNAME解析路径实现身份中继。
在AD架构中，CNAME的解析过程存在一个关键时间窗口：当客户端首次请求某服务时，会先通过DNS查询获取CNAME记录，然后根据CNAME目标发起Kerberos认证。这个查询-认证的间隙，就是攻击者实施"中间人"的黄金时机。
1.2 Kerberos协议的身份中继漏洞
Kerberos协议设计上要求服务端必须验证客户端提供的服务票据(TGS)是否与其实际连接的服务名一致。但微软实现中存在一个致命缺陷：当服务端收到TGS票据时，仅检查SPN中的服务类型(如HTTP/)和主机名部分，却不会验证该主机名是否通过CNAME重定向而来。
攻击者可以精心构造一个恶意CNAME记录，例如：
code复制evil-service.example.com CNAME legit-service.example.com
当用户访问evil-service时，实际获得的却是针对legit-service的合法票据。由于Kerberos协议只验证legit-service的SPN有效性，而不会追溯该请求是否源自evil-service的CNAME重定向，导致身份中继成功。
2. 攻击链完整复现与技术细节
2.1 攻击前置条件与环境准备
要实现这种攻击，攻击者需要满足以下条件：
- 拥有普通域用户权限（无需管理员）
- 目标DNS区域允许动态更新（默认配置）
- 能够监听或诱骗用户访问恶意服务
实验环境建议使用：
- Windows Server 2019域控制器
- Windows 10/11客户端
- Wireshark + Kerberos调试工具集
2.2 分步攻击演示
步骤1：注册恶意CNAME
powershell复制# 通过PowerShell添加恶意记录
Add-DnsServerResourceRecordCName -Name "backup-sql" -HostNameAlias "prod-sql.example.com" -ZoneName "example.com"
步骤2：搭建中继服务
python复制from flask import Flask
app = Flask(__name__)
@app.route("/")
def relay():
# 捕获并转发Kerberos票据
auth_header = request.headers.get('Authorization')
# 将票据中继到真实服务...
步骤3：触发客户端认证
bash复制# 诱导用户访问恶意服务
net use \\backup-sql.example.com\fake-share
2.3 流量特征分析
通过Wireshark捕获的流量显示两个关键阶段：
- DNS查询阶段：客户端查询backup-sql.example.com，获得指向prod-sql的CNAME响应
- Kerberos认证阶段：客户端向KDC请求prod-sql的TGS票据，但最终用于访问backup-sql
关键发现：整个过程中没有任何协议层面的异常告警，因为每个步骤都符合标准协议规范。
3. 防御方案与检测策略
3.1 微软官方补丁评估
微软在2023年6月补丁中对此漏洞进行了部分修复（CVE-2023-28272），但存在以下局限：
- 仅适用于Windows 11/Server 2022及以上版本
- 需要启用"严格KDC验证"组策略
- 无法防御跨域CNAME重定向攻击
3.2 企业级防护方案
网络层防护：
- 实施DNS动态更新审核（推荐配置）：
powershell复制Set-DnsServerSetting -DynamicUpdates "SecureOnly" -LogLevel "Full" - 启用DNSSEC验证链完整性
身份认证层防护：
- 部署服务账户的SPN绑定保护：
powershell复制setspn -Q */prod-sql.example.com - 启用Kerberos Armoring（FAST技术）
3.3 威胁检测规则示例
以下Sigma规则可检测可疑的CNAME修改行为：
yaml复制title: Suspicious DNS CNAME Modification
logsource:
product: windows
service: dns-server
detection:
keywords:
- "EventID=5152" # DNS记录变更
- "Type=CNAME"
- "Name=*backup*|*temp*|*test*"
condition: keywords
4. 渗透测试中的实战案例
4.1 某金融机构红队评估实录
在一次红队演练中，我们通过以下路径突破防线：
- 通过钓鱼邮件获取初始域凭据
- 发现目标使用动态DNS更新
- 添加CNAME记录：
code复制payroll-api CNAME domain-controller - 诱导内部系统访问payroll-api
- 成功获取域控制器服务票据
关键教训：传统防护设备完全放行了该流量，因为所有协议交互都符合标准规范。
4.2 攻击面扩展研究
进一步研究发现，这种技术还可用于：
- 绕过Web应用防火墙（WAF）的SPN检查
- 攻击OAuth/OIDC流程中的身份中继
- 劫持云环境中的内部服务通信
5. 架构级解决方案探讨
5.1 零信任架构下的应对
实施零信任需要补充以下控制点：
- 服务间通信必须双向验证SPN
- DNS解析结果纳入访问决策因素
- 所有CNAME变更触发实时风险评估
5.2 协议层改进建议
IETF草案提出的Kerberos扩展方案：
asn.1复制KRB-CNAME-CHECK ::= SEQUENCE {
originalHostname [0] Hostname,
canonicalHostname [1] Hostname OPTIONAL
}
该扩展要求客户端在AS-REQ中携带原始主机名，KDC将其编码到票据中供服务端验证。
6. 企业应急响应指南
6.1 入侵指标(IOC)检查清单
- 检查过去30天内的CNAME记录变更：
powershell复制Get-WinEvent -LogName "DNS Server" | Where-Object {$_.Id -eq 5152 -and $_.Message -like "*CNAME*"} - 查找异常的Kerberos服务请求：
bash复制grep 'TGS-REQ.*SNAME' /var/log/krb5.log | awk '{print $NF}' | sort | uniq -c
6.2 应急处理流程
- 立即冻结所有DNS动态更新权限
- 审计所有包含关键服务名的CNAME记录
- 重置可能泄露的服务账户凭据
- 在防火墙上临时阻断CNAME重定向流量
我在实际渗透测试中发现，这种攻击最危险之处在于其"合法性"——所有操作都使用标准API和协议流程，使得传统安全设备完全失效。建议企业将DNS日志纳入SIEM重点监控范围，并建立CNAME变更的双人复核机制。