在我的職業生涯中，我有幸一睹世界上一些最大組織的面紗。根據我的經驗，大多數垂直行業都依賴企業 Windows 網絡。事實上，我見過去中心化零信任網絡、企業 Linux、macOS 網絡或 Active Directory 替代方案 (FreeIPA) 的次數一只手就能數得過來。

當我瀏覽這些大型且通常很復雜的企業網絡時，經常會發現 Microsoft SQL Server，它們通常被部署來支持業務功能。對于不熟悉 SQL Server 的讀者來說，總而言之，它是一種關系數據庫軟件，通常安裝在 Windows 服務器上。SQL Server 的主要目的是存儲數據并向應用程序或用戶提供數據。

這篇博文將回顧 SQL Server 提供的攻擊面，以及如何使用 X-Force Red 工具濫用錯誤配置和漏洞SQLRecon。此外，將在適用的情況下概述防御性考慮因素。

微軟SQL服務器

SQL Server 中的漏洞和錯誤配置已得到詳細記錄。雖然這些弱點似乎一直存在，但以某種方式強化 SQL Server 仍然經常被防御團隊忽視。我主要指的是強化底層配置并防止對服務的簡單訪問。

這種監督的一個合理理由是，組織需要優先考慮和解決更大的風險。結果，強化 SQL Server 就被擱置了，因為修改生產數據庫配置可能會導致可用性問題，這可能會表現為操作問題并最終影響業務生產力。

常見漏洞和錯誤配置

我在企業網絡中繼續看到的最常見的錯誤配置之一是任何經過身份驗證的域對象都能夠作為低權限帳戶連接到 SQL 服務。這僅需要有效的域上下文。換句話說，域用戶或域計算機帳戶的有效令牌。

舉個例子，如果普通企業用戶的工作站受到威脅，并且存在通往配置錯誤的 SQL Server 的網絡路由，則攻擊者可能會：

• 在遠程 SQL Server 上執行有限的 SQL 命令。
• 確定他們擁有的特權，這可能會通過模擬式攻擊提供升級機會。
• 指示 SQL Server 通過向通用命名約定 (UNC) 路徑發出請求來提供身份驗證材料，這可能會導致獲取散列憑據，進而可以破解或轉發該憑據以執行中繼式攻擊。
• 附帶分配給鏈接到其他 SQL Server 的 SQL Server 的權限，這可能會導致權限升級。

這些只是攻擊者在域上下文中評估配置錯誤的 SQL Server 時可以實現的一些示例。SQL Server 呈現的攻擊面始終取決于您面臨的環境和配置。

為什么現在關注 Microsoft SQL Server 攻擊？

最近，紅隊操作員因各種 Active Directory 濫用而受益匪淺，這些濫用可用于提升 Microsoft 企業網絡中的特權。然而，隨著防御團隊開始設法緩解這些弱點，通過濫用 Active Directory 來提升權限的途徑自然會趨于枯竭。

盡管如此，我們仍然堅持不懈，沿著眾所周知的攻擊清單前進，樂觀地尋求升級路徑，以幫助我們實現我們的目標。我有點不愿意承認，在很長一段時間里，攻擊 SQL Server 對我來說是一個很遙遠的事情。相反，我選擇優先考慮共享存儲空間、內部 Web 應用程序、DevOps 工具或云基礎設施等內容。你大概可以明白我要說的是什么了……

2022 年的某個時候，我正處于交戰狀態，在用盡所有首選升級路徑后，我陷入了停滯點。這主要是由于異常堅固的環境。至少，在我發現一個大型 SQL Server 場之前我是這么想的，那里肯定存在配置錯誤或漏洞。

當時我并不知道，直到寫完這篇博文后，我才發現卡巴斯基發現，2022 年使用 SQL Server 的重復攻擊增加了 56%。這是一個驚人的數字。

攻擊微軟 SQL Server

作為一名紅隊操作員，我經常使用命令和控制 (C2) 框架與我在客戶網絡中受到損害的系統進行交互。我們有幸合作的客戶通常擁有成熟的網絡安全計劃、有能力的防御團隊和現代安全控制，例如端點檢測和響應（EDR）解決方案。

多年來已經開發了多種攻擊 SQL Server 的工具。在我的筆測試期間我總是最終達到的目標是PowerUpSQL. 這是一個由 Scott Sutherland ( @_nullbind )創建的項目，主要在 PowerShell 中開發。

EDR 解決方案可能是一個強大的對手，因為它們在檢測專為攻擊性安全而設計的惡意開源工具方面表現出色，尤其是那些依賴 PowerShell 的工具。這并不是要輕視 PowerShell 后利用工具，它們是有目的的，只是不是為了解決我在所處環境中遇到的問題。

PowerShell 很好，但 C# 更好

我在參與過程中遇到的問題是，我需要找到一種方法來連接到 Microsoft SQL Server 并開始詢問它們以確定是否存在任何錯誤配置或漏洞。然而，使用任何現有的 SQL Server 后利用工具（依賴于 PowerShell）肯定會被防御團隊抓住。這是由于多種原因造成的，我不會詳細說明，但由于AMSI、受限語言模式和各種日志記錄等安全功能，PowerShell 并不是進行后利用攻擊的理想工具。。當 EDR 解決方案以及其他日志記錄和監控控制到位時，這種情況只會進一步復雜化。

作為替代方案，紅隊操作員通常選擇 C# 作為開發后利用工具的語言，因為它提供了一種與 .NET 框架以及 Windows API 交互的簡單方法。

我絕不是 C# 或 .NET 開發人員，但我的知識足以編寫解決我面臨的問題的工具。Queue SQLRecon，一個 C# SQL 工具包，專為進攻性偵察和后期利用而設計。

SQL偵察

SQLRecon通過現代化紅隊操作員在攻擊 SQL Server 時可以采取的方法，幫助解決利用后工具缺口。該工具被設計為模塊化，易于擴展。SQLRecon獨立兼容或在一組不同的 C2 框架內兼容。當使用后者時，可以在進程內SQLRecon執行或通過傳統的fork 和 run執行。

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 System Center Configuration Manager (SCCM) 和 Microsoft Endpoint Configuration Manager (ECM) SQL 數據庫攻擊
• 所有 SQL 查詢都使用System.Data.SqlClientMicrosoft 開發的命名空間

有關每種技術的詳細使用信息，請參閱wiki。

使用 SQLRecon

JSmith為了為即將到來的演示做好準備，我將在企業網絡中屬于 Jeff Smith ( ) 的一臺受感染的 Windows 10 工作站上進行操作kawalabs.local。

Jeff 的工作站有一個到三個 SQL Server 的網絡路由，每個 SQL Server 都運行不同的版本；2016 年、2019 年和 2022 年。

和之間已配置了一條SQL 鏈接， 和之間已配置了另一個 SQL 鏈接。對于不熟悉鏈接 SQL Server 的讀者來說，這實際上允許一個 SQL 實例在另一個 SQL 實例上執行 SQL 語句。例如，可以在 上執行 SQL 語句，可以在 上執行語句，但不能在 上執行語句，反之亦然。在真實的企業網絡中經常可以看到鏈接的 SQL Server。SQL01SQL02SQL02SQL03SQL01SQL02SQL02SQL03SQL01SQL03

此外，域中的主域控制器與Active Directory 服務 (ADSI) 鏈路之間存在。ADSI 鏈接為 SQL Server 提供了一種與 Active Directory 對象交互的方法。SQL03kawalabs.localDC01

最后，該kawalabs.local域已kawalabs.onmicrosoft.com使用Azure AD Connect連接到 Azure Active Directory 域。這允許本地 Active Directory 用戶kawalabs.local訪問 Azure 云中的資源。Azure  kawalabs.onmicrosoft.comAD 租賃包含一個存儲付款數據的 SQL Server ECOM01。

圖1：網絡配置

此外，我將利用Cobalt Strike（一種流行的命令和控制框架）從 Jeff 受感染的工作站 ( DESKTOP-LF8Q3C6) 執行攻擊后任務。在下面的屏幕截圖中，我已經執行了該whoami命令。這只是為了表明 Jeff 不是特權用戶，并且在kawalabs.local域和更廣泛的網絡中擁有基本權限。

圖 2：發出whoami命令

枚舉

在撰寫本文時，SQLRecon有兩個枚舉模塊可用于發現網絡中的 SQL Server，以及獲取有關 SQL Server 實例的一些信息。以下命令將枚舉 Active Directory服務主體名稱 (SPN)并確定是否為 SQL Server 設置了任何 SPN。在kawalabs.local域中，有一個為幾個不同帳戶設置的 SPN，如下面的屏幕截圖所示。

圖 3：通過 SPN 集合發現 SQL Server

該info模塊對于獲取有關服務器的附加信息非常有用。下面的示例演示了從 SQL Server 檢索的信息類型。

圖4：獲取信息SQL02

向 Daniel Duggan ( @_RastaMouse )致敬，感謝他對SQLRecon.

標準模塊

標準模塊針對單個 SQL Server 實例執行。

在以下示例中，我使用AzureAD身份驗證提供程序，它使用 Azure Active Directory 帳戶的用戶名和密碼對ECOM01位于 Azure 云中的 SQL 實例進行身份驗證。然后，我使用該whoami模塊來確定 Jeff 擁有的權限ECOM01。

圖 5：枚舉 SQL 權限jsmith@kawalabs.onmicrosoft.com

默認情況下，SQLRecon將連接到master數據庫，因為該數據庫通常存在于所有 SQL Server 實例上。但是，您可以使用該databases模塊輕松列出 SQL Server 實例上的所有不同數據庫。

圖 6：枚舉數據庫ECOM01

您可以通過使用標志指定數據庫名稱來連接到其他數據庫/database:，并轉發您想要執行的任何模塊。在下面的示例中，我連接到Payments數據庫ECOM01并執行自定義 SQL 查詢，該查詢將從cc表中獲取所有內容。

cc圖7：從數據庫表中Payments獲取虛擬卡數據ECOM01

進入一些更有趣的模塊，SQLRecon支持 UNC 路徑注入，這可以由低權限用戶帳戶執行，例如KAWALABS\JSmith. 這可能會導致獲得散列憑證，而該憑證又可以被破解或轉發以執行中繼式攻擊。在以下示例中，我使用WinToken身份驗證提供程序（它使用用戶帳戶的令牌）KAWALABS\JSmith對SQL02本地服務器進行身份驗證。

圖 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。

圖 10：防止命令執行的護欄演示

如上圖所示，遇到執行護欄，并收到一條錯誤消息，表明該護欄xp_cmdshell已被禁用。這通常是大多數 SQL Server 版本上的默認配置。好處是，SQLRecon有一個enableXp模塊，可以啟用xp_cmdshell配置。SQLRecon還有一個disableXp模塊，以便您可以在執行命令后恢復到原始安全狀態xpCmd。

圖 11：另一個護欄的演示，其中權限不足會阻止命令執行

正如預期的那樣，低權限KAWALABS\JSmith帳戶遇到了執行護欄，并收到一條消息，表明他們沒有啟用或禁用所需的權限xp_cmdshell……是嗎？

濫用冒充行為

SQL 模擬是一種特殊權限，本質上使用戶或組能夠使用另一個用戶的權限以及他們自己的權限進行操作。以下截圖取自后端配置SQL02，演示了BUILTIN\Users可以模擬sa賬戶。

圖12：BUILTIN\Users可以模擬sa賬戶SQL02

SQLRecon有一個impersonate模塊可以幫助確定用戶帳戶是否可以冒充另一個用戶。

如下面的屏幕截圖所示，KAWALABS\JSmith低權限用戶帳戶可以模擬sa上的帳戶SQL02。這演示了使用類似管理員權限在 SQL 實例上執行命令的能力。此外，這意味著我們現在可以在底層服務器上執行系統命令。

圖 13：枚舉可被模擬的帳戶SQL02

為了演示另一個命令執行模塊，可以使用OLE 自動化過程SQLRecon對底層用戶執行命令。這使用程序集與 COM 對象交互，以便可以用來運行任意系統命令。odsole70.dllwscript.shell

模擬模塊始終以字母 開頭i，并且這些模塊將需要要模擬的帳戶的名稱。SQL02在以下示例中，我作為低權限帳戶連接KAWALABS\JSmith并模擬該sa帳戶以在SQL02.

圖 14：使用模擬啟用 OLE 自動化過程

現在，OLE 自動化過程已在 上啟用SQL02，我可以在已啟動 SQL Server 進程的用戶帳戶的上下文中在底層服務器上執行任何任意命令。在以下示例中，我執行一個 PowerShell 子進程，該進程列出了之前用于捕獲 NetNTLMv2 憑據的同一共享的目錄。請記住，這主要是為了演示目的，而不是通常在對手模擬交戰中執行的操作。

圖 15：使用 PowerShell 列出遠程主機上的目錄

如上面的屏幕截圖所示，創建了一個隨機生成的 OLE 對象和方法，然后執行惡意命令，并銷毀 OLE 對象。這是故意的，因為我們不想留下任何我們行為的證據。

KAWALABS\mssql_svc在下面的屏幕截圖中，我們可以看到用戶帳戶通過SQL02我們控制的主機（172.16.10.19）建立的連接。這將導致獲取KAWALABS \mssql_svc計算機帳戶的 NetNTLMv2 哈希值。

圖 16：獲取 NetNTLMv2 哈希值KAWALABS\mssql_svc

以下示例演示了使用模擬來tasklist使用xp_cmdshellon執行命令SQL02。

圖 17：xp_cmdshell使用模擬啟用并執行系統命令SQL02

將配置恢復到原來的狀態始終是一個好習慣。

圖 18：禁用 OLE 自動化過程xp_cmdshell等SQL02

攻擊鏈接的 SQL Server

SQLRecon還可以對鏈接的 SQL Server 實例執行攻擊。以下屏幕截圖取自 的后端配置SQL02，并演示了SQL02具有指向 的鏈接SQL03。根據我的經驗，這是大型企業網絡中的常見配置。

圖 19：SQL02有一個 SQL 鏈接SQL03

配置從一個 SQL Server 實例到另一個 SQL Server 實例的鏈接通常需要一組特權憑據來建立和綁定該鏈接。這對攻擊者來說是有利的，因為它允許在已建立連接的帳戶的上下文中在鏈接的 SQL Server 上執行命令。另一個需要考慮的問題是，鏈接服務器可能與對手正在操作的網絡分開。這可能提供穿越分段邊界并進入安全要求更高的網絡區域的機會。

SQLRecon有一個links模塊可以確定 SQL Server 是否有任何鏈接的 SQL 實例。

圖 20：枚舉鏈接的 SQL 服務器SQL02

鏈接模塊始終以字母 開頭l，并且這些模塊需要您要對其發出命令的鏈接服務器的名稱。SQL02在以下示例中，我作為低權限帳戶連接并對鏈接的實例KAWALABS\JSmith發出命令。lWhoamiSQL03

SQL03圖 21：枚舉我們可以通過以下方式承擔的 SQL 權限SQL02

如上面的屏幕截圖所示，我們正在sa上的帳戶上下文中進行操作SQL03。這是因為該sa帳戶用于建立從SQL02到 的SQL 鏈接SQL03。

SQLRecon鏈接的 SQL Server 完全支持其中的所有執行模塊。在以下示例中，我在SQL02.

圖 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.dllSQL Server CLR 兼容的 .NET 程序集

如果您有興趣了解有關自定義 SQL Server CLR 兼容 .NET 程序集的更多信息，請訪問wiki的ClrSQLRecon部分。可以在此處hollow.dll找到的示例。

在下面的演示中，我已上傳hollow.dll到 Web 服務器并將程序集重命名為favicon.png. 我指示鏈接服務器從 Web 服務器SQL03下載并執行必要的步驟，將自定義程序集導入 SQL Server 存儲過程并執行有效負載。favicon.png這會導致KAWALABS\mssql_svc在 上的用戶上下文中獲得 Cobalt Strike 信標SQL03。

KAWALABS\mssql_svc圖 24：在on的上下文中獲取 Cobalt Stri

當然，前面的示例需要SQL03具有 Internet 訪問權限才能從面向公眾的 Web 服務器下載程序集。在某些情況下，從面向公眾的 Web 服務器下載外部資源是不可能或不可取的。因此，SQLRecon允許直接從受感染主機的文件系統或 SMB 共享加載自定義程序集。在下面的演示中，我已上傳hollow.dll到本地 SMB 服務器并將程序集重命名為Reports.xlsx. 我指示鏈接服務器從 SMB 服務器SQL03下載并執行必要的步驟，將自定義程序集導入 SQL Server 存儲過程并執行有效負載。Reports.xlsx這會導致KAWALABS\mssql_svc在 上的用戶上下文中獲得 Cobalt Strike 信標SQL03。

圖 25：在以下環境中獲取 Cobalt Strike 信標KAWALABS\mssql_svc

攻擊鏈接的 SQL Server – ADSI 濫用

SQLRecon還可以對鏈接的 ADSI 服務器實例執行攻擊，以獲取域帳戶的明文憑據。有關 ADSI tradecraft 的更多信息，請參閱 Tarlogic博客文章。以下屏幕截圖取自后端配置SQL03，演示了到域SQL03中主域控制器的 ADSI 鏈接。此 ADSI 鏈接由對象表示。kawalabs.localDC01linkADSI

圖 26：SQL03有一個 ADSI 鏈接到DC01

配置從 SQL Server 實例到 Active Directory 域控制器的 ADSI 鏈接不一定需要特權憑據。然而，在實際操作中，我見過沒有應用最小特權原則的情況。

在以下示例中，我使用該lLinks模塊首先連接到SQL02，然后查詢SQL03其他鏈接的 SQL Server。您可以將其視為雙鏈接場景。

SQL03圖 27：枚舉from上的鏈接SQL02

現在我們已經驗證了 ADSI 鏈接存在于 上SQL03，我們可以利用該模塊來獲取用于配置從到 的lAdsiADSI 連接的明文域憑據。這涉及將包含LDAP 服務器的自定義 CLR 程序集上載到上的新SQL Server 運行時例程中。然后，LDAP 服務器將在用戶提供的端口（本例中為 49103）上執行并偵聽僅限本地的連接。然后，我們利用 SQL Server 代理作業SQL03DC01SQL03SQL03引導用于配置 ADSI 連接的憑據，以在端口 49103 上向本地 LDAP 服務器請求 LDAP 請求。此臨時 LDAP 身份驗證重定向最終會導致獲取明文域憑據。應該注意的是，Adsi和iAdsi模塊不使用 SQL Server 代理作業來啟動 LDAP 請求過程，而是使用標準 SQL 查詢。

圖 28：雙鏈路 ADSI 憑據收集攻擊

SCCM模塊

最大的擴展之一SQLRecon來自我的同事 Dave Cossa ( @G0ldenGunSec )，他引入了各種可用于濫用 Microsoft System Center Configuration Manager (SCCM) 和 Microsoft Endpoint Configuration Manager (ECM) 的模塊。SCCM 模塊是在現實世界的參與的基礎上開發的，其中濫用 SCCM SQL Server 數據庫有助于進一步推動我們實現目標。在大多數情況下，要與 SCCM 數據庫交互，需要獲取提升的權限上下文，或者需要獲取對 SCCM 服務器的訪問權限。在下面的示例中，我有一個 Cobalt Strike 信標在KAWALABS\mssccm_svcECM 服務器上的帳戶上下文中運行MECM01。

從現在起，我將把 ECM 和 SCCM 簡稱為 SCCM。

在下面的示例中，我使用該databases模塊枚舉 上 SQL Server 實例中存在的數據庫MECM01。

圖 29：枚舉數據庫MECM01

如上面的屏幕截圖所示，CM_KAW數據庫存在，這很可能是為此服務器上的 SCCM 配置的數據庫。

SCCM 模塊始終以字母 開頭s，并且這些模塊需要您要對其發出命令的 SCCM 數據庫的名稱。在以下示例中，我以帳戶身份連接到CM_KAW數據庫并發出命令。此模塊枚舉配置為登錄 SCCM 服務器的所有主體。MECM01KAWALABS\mssccm_svcsUsers

圖 30：枚舉可以通過 SCCM SQL Server 數據庫登錄 SCCM 的所有用戶

還可以使用該sTaskList模塊枚舉 SCCM 中配置的任務。

圖 31：通過 SCCM SQL Server 數據庫枚舉 SCCM 中配置的任務

SCCM 通常需要保管憑證，這些憑證用于對環境中的系統或資源進行身份驗證，以部署軟件包或執行 SCCM 提供的任何其他各種操作。使用該sCredentials模塊，我們可以獲得保管憑證的列表。

圖 32：通過 SCCM SQL Server 數據庫獲取保管憑證

在上面的屏幕截圖中，我們可以看到一個憑證已被保管，這是該KAWALABS\mssccm_svc帳戶的憑證。

使用 Adam Chester ( @_xpn_ )的邏輯，可以解密 SCCM 保管憑證并獲取保管帳戶的明文密碼。這確實需要 SCCM 服務器上的本地管理員權限。在下面的屏幕截圖中，我使用該sDecryptCredentials帳戶來解密該KAWALABS\mssccm_svc帳戶保管的憑據。

圖 33：解密存儲的 SCCM 憑證

防守方面的考慮

為了防止攻擊者濫用 SQL Server，防御者在實施安全控制時可以采取分層方法。首先，我強烈建議您閱讀有關 SQL Server安全最佳實踐的Microsoft 官方指南。

下一站應該是SQLReconwiki中的預防、檢測和緩解指南，其中有一些出色的防御考慮因素。我挑選了一些要實施的更重要的控件，并將它們列在下面。

網絡安全控制

在網絡級別實施時應考慮以下安全控制。

• 確保到 SQL Server 的網絡路由已被考慮并僅限于一組授權的系統或子網。工作站很少需要能夠直接與 SQL Server 通信。如果可行，請考慮阻止對 TCP 1433 的訪問。
• 驗證網絡日志記錄和監視工具是否正在捕獲穿越網絡邊界的 SQL 查詢。工作站將 SQL 查詢發送到 SQL 服務器是不常見的。

端點安全控制

在環境中的工作站和服務器上實施時應考慮以下安全控制。

• 驗證基于主機的安全控制（例如端點檢測和響應解決方案）是否已啟用，以及產品簽名是否定期完全更新。
• 防御者應確保 .NET Framework v4.8 安裝在 Windows 端點上，并且使用的任何基于主機的安全產品都支持 .NET 的 AMSI。這允許掃描內存中的.NET 程序集。
• SQLRecon啟用或配置應用程序白名單解決方案，以防止直接在端點上執行未簽名的二進制文件，例如。

Microsoft SQL Server 安全控制

• 確保底層 Windows Server 操作系統遵循強化準則。考慮僅安裝必要的 SQL 數據庫組件。
• 確保 SQL Server 包含在組織的補丁管理策略中，并且定期對 SQL 服務和 SQL Server 應用補丁。
• 考慮限制或刪除BUILTIN\Users帳戶對 SQL Server 實例進行身份驗證。
• 在用戶帳戶上配置角色時遵循最小權限原則。此原則也應適用于啟動 SQL Server 的服務帳戶。
• 刪除不必要的 SQL 服務主體名稱關聯。
• 對任何本地帳戶（例如sa帳戶）使用強密碼。
• 記錄、集中提取和審核 SQL Server 登錄事件。Netwrix寫了一篇很棒的博客，介紹了如何實現這一目標。
• 加密敏感內容。即使 SQL Server 受到威脅，這也可以保護數據集不被泄露。
• 評估 SQL 服務器之間的鏈接并確定綁定該鏈接的身份驗證類型。如果可能，選擇使用當前的身份驗證安全上下文，而不是使用帳戶的上下文sa。
• 評估已配置的任何模擬并確定其要求。
• 如果使用 Azure SQL 數據庫，請確保啟用 Microsoft 高級威脅防護并將其配置為發送警報。

結論

針對 SQL Server 的攻擊在當今的網絡安全領域仍然具有重要意義。攻擊者不斷發展其技術來逃避防御控制，為此，他們越來越多地利用 SQL Server 等輔助服務。這些攻擊變得更加復雜和隱蔽，通常采用不太常見的技術來繞過傳統的安全措施。

通過濫用 SQL Server，攻擊者可以獲得對敏感數據的未經授權的訪問、操縱數據庫，甚至危及整個系統。此類攻擊的后果可能很嚴重，導致數據泄露、財務損失和組織聲譽受損。

為了降低這些攻擊的風險，組織必須檢查其 SQL Server 配置并采用最佳安全實踐。此外，組織應該投資提供實時監控、異常檢測和行為分析功能的安全解決方案。這些解決方案可以幫助更有效地檢測和響應攻擊，最大限度地減少對關鍵數據和系統的潛在影響。通過采取主動措施來保護 SQL Server 環境，組織可以顯著降低成為這些攻擊受害者的風險并保護其寶貴的數據資產。