1. 靶机初探从MSSQL弱口令到NTLMv2 Hash捕获大家好我是老张在安全圈里摸爬滚打了十几年今天想和大家聊聊一次非常有意思的渗透测试实战。这次的目标是HTB平台上一个名为“Signed”的靶机整个过程就像剥洋葱一层层深入最终触及到Active Directory域的核心。如果你对Windows域渗透、Kerberos协议特别是那些听起来很酷的“银票”Silver Ticket攻击感兴趣那这篇分享应该能给你不少启发。整个过程我会尽量用大白话和实际操作的例子来讲清楚保证你就算刚入门也能跟上思路。咱们先说说起点。拿到一个靶机第一步肯定是信息收集。对“Signed”进行端口扫描后我发现它开放了标准的MSSQL服务端口通常是1433。这立刻引起了我的注意因为数据库服务往往是进入内网的一扇“后门”。尝试用一些常见的弱口令去碰碰运气结果还真让我给碰上了——使用凭证scott:Sm230#C5NatH成功连接上了MSSQL服务。这里插一句在真实环境中弱口令依然是导致安全事件的最常见原因之一定期审计和强化口令策略永远不过时。登录进去之后我并没有急着去执行什么高权限命令。多年的经验告诉我先摸清环境比盲目行动更重要。我查看了当前用户的权限发现这个scott用户只是个普通用户并非sysadmin服务器角色成员。这意味着很多“大杀器”功能比如开启xp_cmdshell来执行系统命令暂时是无法使用的。但这没关系渗透测试就像侦探破案一条路走不通就换一条。我的目光转向了另一种经典的攻击手法NTLM中继或Hash捕获。MSSQL服务运行在一个域账户mssqlsvc下。如果我能诱使这个服务账户向我的攻击机发起身份验证我就能捕获到它的NTLMv2 Hash。这里我用到了一个老牌但极其好用的工具——Responder。我把它部署在我的Kali攻击机上配置好监听网卡然后就需要想办法触发MSSQL服务对我的机器进行身份验证。一个常用的技巧是利用MSSQL的“链接服务器”功能或者某些需要访问网络路径的存储过程。但在当前权限下直接操作可能受限。另一种更通用的方法是如果我能让服务器尝试访问一个位于我攻击机上的UNC路径比如\\我的IP\共享文件夹那么Windows就会尝试用当前服务的账户身份进行NTLM认证。具体到这次实战我通过执行一个特定的查询诱使SQL Server去解析一个指向我Responder服务的UNC路径。命令执行后回到Responder的终端我立刻看到了令人兴奋的输出——它成功捕获到了SIGNED\mssqlsvc这个账户的NTLMv2挑战-响应散列值。这个NTLMv2 Hash看起来是一长串字符像是“mssqlsvc::SIGNED:1122334455667788:2F3A...后面很长”。捕获到Hash只是第一步我们还需要把它“翻译”成能用的明文密码。我把它保存到一个文件里然后交给了Hashcat配合一个强大的密码字典进行离线破解。运气不错经过一段时间的跑字典密码被成功破解出来purPLE9795!。现在我们手握一个域用户mssqlsvc的明文密码这相当于拿到了进入域环境的一张普通门禁卡。但这离我们的最终目标——域管理员权限还有一段距离。2. 权限迷雾非sysadmin的困境与发现用新获得的mssqlsvc域账户凭证重新登录MSSQL服务后我第一时间检查了当前权限。执行查询SELECT IS_SRVROLEMEMBER(sysadmin);返回结果是0。这证实了我的猜测mssqlsvc这个服务账户本身也不是sysadmin。这有点意思说明靶机的配置有一定安全性没有让数据库服务账户拥有过高的本地权限。不能直接执行系统命令我们就得继续横向探索。我使用了enum_logins脚本来枚举数据库服务器上已知的登录名及其所属的服务器角色。这个脚本比如PowerUpSQL工具包里的能帮我们快速理清权限结构。查询结果给了我一个关键信息属于SIGNED\IT这个域组的成员被授予了sysadmin服务器角色。这是一个非常重要的突破口它意味着只要我能以SIGNED\IT组内成员的身份连接到MSSQL我就能获得完整的sysadmin权限从而为所欲为。但我们目前只有mssqlsvc这个普通域用户的密码它并不在IT组里。直接提权或添加用户到IT组没有域管理员权限这几乎不可能。这时候Kerberos协议和它的一个著名弱点进入了我的视野票据伪造。在Kerberos认证体系中有一种针对服务账户的攻击叫Silver Ticket银票攻击。简单类比一下Kerberos协议就像一场高级宴会有门票Ticket才能进入不同的厅服务。金票Golden Ticket是伪造域管理员权限的万能门票而银票Silver Ticket则是伪造针对某个特定服务比如这里的MSSQL服务的访问门票。银票攻击之所以可行是因为服务在验证客户端提供的服务票据Service Ticket时只依赖它自己与KDC域控制器共享的一个密钥而不会去域控制器那里二次验证这张票的真伪。要伪造一张能让我们以IT组成员身份访问MSSQL服务的银票我们需要准备以下几样“原材料”服务账户的密钥也就是mssqlsvc账户的密码哈希NT-Hash或AES密钥。我们有明文密码purPLE9795!可以轻松计算出来。目标服务的SPN服务主体名称这是服务的唯一标识符。对于MSSQL服务格式通常是MSSQLSvc/主机名.域名:端口。通过扫描或信息收集我确定了目标SPN是MSSQLSvc/DC01.SIGNED.HTB。域的SID安全标识符这是整个域的唯一标识符。我们需要知道域SID以及我们想要加入的组这里是IT组RID 1105的完整SID。我们想要伪造的组显然我们需要把SIGNED\IT组RID 1105放进票据的权限数据PAC里。原材料齐备下一步就是动手制作这张“银票”了。3. 锻造银票关键参数详解与票据生成实战制作银票就像配一把精密的钥匙每个参数都不能出错。我们一步步来。首先计算服务账户mssqlsvc的NT-Hash。这个哈希是RC4加密的密钥基础。在Linux下用openssl可以很方便地计算echo -n purPLE9795! | iconv -f UTF-8 -t UTF-16LE | openssl md4输出ef699384c3285c54128a3ee1ddb1a0cc就是我们要的NT-Hash。记下它我们叫它$NT_HASH。接下来获取域的SID和IT组的RID。我们已经知道IT组的完整SID是S-1-5-21-4088429403-1159899800-2753317549-1105。最后一段-1105就是相对标识符RID。去掉RID前面的S-1-5-21-4088429403-1159899800-2753317549就是域的SID。记作$DomainSID。在MSSQL里你可以用SELECT SUSER_SID(SIGNED\IT);查询得到的是二进制形式需要转换一下。我通常用个小Python脚本转换更直观。然后确定我们要伪造的用户和组。最初的想法很简单伪造一个属于IT组RID 1105的任意用户比如就叫Administratot注意拼写故意和Administrator区别开避免冲突。这样我们就能获得sysadmin权限了。使用Impacket套件中的ticketer.py工具来生成票据impacket-ticketer -nthash ef699384c3285c54128a3ee1ddb1a0cc \ -domain-sid S-1-5-21-4088429403-1159899800-2753317549 \ -domain SIGNED.HTB \ -spn MSSQLSvc/DC01.SIGNED.HTB \ -groups 1105 \ Administratot命令执行后会生成一个名为Administratot.ccache的Kerberos票据缓存文件。我们通过设置环境变量export KRB5CCNAME/path/to/Administratot.ccache来告诉系统使用这个票据。现在以这个伪造的身份使用Impacket的mssqlclient.py连接数据库impacket-mssqlclient -k -no-pass SIGNED.HTB/AdministratotDC01.SIGNED.HTB参数-k表示使用Kerberos认证-no-pass表示不需要密码。连接成功后立刻验证权限SELECT IS_SRVROLEMEMBER(sysadmin);。返回结果是1成功了我们现在在MSSQL眼里就是拥有sysadmin权限的“IT组成员”了。常规思路这时候可以开启xp_cmdshell执行命令了。我照做了也成功在mssqlsvc用户的桌面上找到了user.txt标志文件。但是当我尝试访问域管理员目录比如\\DC01\C$\Users\Administrator时却被拒绝了访问。这说明我们虽然骗过了MSSQL服务获得了数据库层面的最高权限但我们的进程令牌在操作系统层面并没有域管理员权限。这是因为我们伪造的票据里只包含了IT组1105没有包含域管理员组如RID 512。4. 权限跃升注入域管组与令牌模拟的精妙调整要想访问域管理员目录我们必须让Windows系统认为我们的令牌具有域管理员权限。这意味着我们需要在伪造的银票中除了IT组1105还要加入域管理员组。但这里有一个非常关键的细节也是这次实战最精妙的地方。如果我们只加入域管理员组比如-groups 512那么虽然系统令牌有了域管权限但MSSQL服务在检查我们的数据库登录权限时会发现我们不属于SIGNED\IT组因此不会授予我们sysadmin角色。没有sysadmin权限很多高级操作比如我们后面要用到的OPENROWSET(BULK)就无法执行。所以我们必须同时指定两个组-groups 512,1105。这样Kerberos票据的PAC里就会声明我们同时是“Domain Admins”和“IT”组的成员。MSSQL看到IT组给我们sysadminWindows看到Domain Admins组给我们访问管理员目录的权限。还有另一个致命细节用户名。服务票据Silver Ticket是针对特定服务SPN和特定用户主体即用户名加密的。SPN我们已经指定为MSSQLSvc/DC01.SIGNED.HTB这个服务运行在mssqlsvc账户下。如果我们伪造的用户名比如之前的Administratot与mssqlsvc不符那么当SQL Server进程以mssqlsvc身份运行尝试使用我们提供的票据来模拟用户时会因为用户名与票据不匹配而导致模拟失败。后续操作也会因为安全上下文错误而失败。因此我们必须将伪造的用户名也设置为mssqlsvc。我们需要知道mssqlsvc这个用户在域里的RID。通过查询或之前的枚举假设我们得知其RID是1103。那么最终的票据生成命令需要更新impacket-ticketer -nthash ef699384c3285c54128a3ee1ddb1a0cc \ -domain-sid S-1-5-21-4088429403-1159899800-2753317549 \ -domain SIGNED.HTB \ -spn MSSQLSvc/DC01.SIGNED.HTB \ -user-id 1103 \ -groups 512,1105 \ mssqlsvc注意我们指定了-user-id 1103和用户名mssqlsvc确保票据主体是服务账户本身同时-groups包含了域管组(512)和IT组(1105)。生成新的票据比如mssqlsvc.ccache设置环境变量然后再次使用Kerberos方式连接MSSQL。这次连接后你不仅拥有sysadmin权限其背后的进程令牌也包含了域管理员权限。我们可以验证一下虽然查询SELECT IS_SRVROLEMEMBER(sysadmin);依然返回1但更重要的是我们现在可以尝试访问那些需要域管权限的资源了。5. 技术深潜为何xp_cmdshell折戟而OPENROWSET(BULK)成功这是一个非常经典且容易混淆的问题。我们已经伪造了包含域管权限的票据并且以mssqlsvc用户成功连接那为什么通过xp_cmdshell执行dir \\dc01\c$\Users\Administrator会失败而使用OPENROWSET(BULK)读取\\dc01\c$\Users\Administrator\Desktop\root.txt却能成功呢这背后是Windows安全模型中进程创建与令牌继承的机制在起作用。当我们使用Kerberos票据成功认证到MSSQL服务后SQL Server进程sqlservr.exe以mssqlsvc账户运行会为我们的连接会话创建一个模拟令牌Impersonation Token。这个令牌是基于我们提供的Kerberos票据中的PAC信息生成的。因为我们伪造的票据里包含了Domain Admins组所以这个模拟令牌也拥有域管理员权限。只要操作是在SQL Server进程内部、且在当前线程的模拟上下文中执行就会使用这个高权限令牌。OPENROWSET(BULK)的工作原理这是一个SQL Server内置的、用于批量导入数据的函数。当它执行文件操作如读取网络路径文件时是在SQL Server进程的内部直接使用当前连接线程的模拟令牌去访问文件系统。因此它顺利地使用了我们伪造的、包含域管权限的令牌成功读取了管理员目录下的文件。xp_cmdshell的工作原理这是一个扩展存储过程用于执行操作系统命令。它的执行流程是SQL Server进程接收到命令后会创建一个新的外部进程默认是cmd.exe。创建新进程时Windows会为其分配一个主令牌Primary Token。关键点在于默认情况下新进程的主令牌继承自创建者进程即sqlservr.exe的主令牌而不是我们连接会话的模拟令牌。sqlservr.exe进程是以mssqlsvc账户的身份启动的它的主令牌只包含mssqlsvc账户本身的权限普通域用户。虽然我们的会话有高权限模拟令牌但xp_cmdshell创建出的cmd.exe进程使用的是mssqlsvc的低权限主令牌因此无法访问需要域管权限的资源。我们可以通过一个查询来验证这个进程链EXEC xp_cmdshell wmic process where namecmd.exe get processid,parentprocessid,commandline,executablepath;输出会显示cmd.exe的父进程ID正是sqlservr.exe的进程ID。这证实了cmd.exe是SQL Server创建的子进程。所以核心区别在于OPENROWSET(BULK)是“内部函数”沿用当前线程令牌xp_cmdshell是“外部进程创建”使用服务账户主令牌。理解了这一点就能明白在类似需要利用进程令牌权限的场景下选择正确的技术路径有多么重要。6. 实战收官利用OPENROWSET(BULK)完成最终提权与思考既然我们知道了OPENROWSET(BULK)能利用上我们伪造的高权限令牌那么最后的攻击路径就清晰了。我们的目标是读取域控制器上管理员桌面下的root.txt标志文件。首先确保你已经用包含了正确参数-user-id 1103 -groups 512,1105生成的银票以Kerberos方式连接到了MSSQL并且拥有sysadmin权限。接下来使用OPENROWSET(BULK)来读取远程文件。其基本语法是将其作为一个表来查询SELECT * FROM OPENROWSET(BULK N\\DC01.SIGNED.HTB\C$\Users\Administrator\Desktop\root.txt, SINGLE_CLOB) AS Contents;这条查询会尝试以单字符大对象SINGLE_CLOB的形式读取指定路径的文件内容。如果文件存在且我们有权限访问文件内容就会作为查询结果返回。执行这条语句后我成功地在结果集中看到了root.txt文件的内容也就是最终的标志。至此从最初的一个MSSQL弱口令到捕获服务账户Hash再到利用Silver Ticket伪造技术结合对Windows令牌机制的深入理解我们最终完成了权限提升拿到了域环境中的最高权限凭证所能访问的关键信息。回顾整个流程有几点实战心得想分享第一信息收集和权限分析要细致。发现IT组是sysadmin这个信息是整个攻击链的转折点。第二对Kerberos协议和Windows认证机制的理解至关重要。知道银票需要哪些要素SPN、SID、Hash、Groups才能正确地伪造。第三也是我最想强调的理解工具背后的原理。知道xp_cmdshell和OPENROWSET(BULK)在令牌使用上的本质区别才能在被xp_cmdshell阻挡时迅速找到OPENROWSET(BULK)这条替代路径。这种对底层原理的把握往往能在看似走投无路时为你打开另一扇门。这种攻击手法在HTB的另一台机器“Escape”上也有类似体现多打靶机多总结模式你的内网渗透思路会开阔很多。