無需登錄域控服務器也能抓 HASH 的方法

Active Directory 幫助 IT 團隊在整個網絡中集中管理系統、用戶、策略等。因為它是組織不可分割的一部分，所以這給攻擊者提供了機會，利用 Active Directory 的功能來做一些惡意的操作。在這篇文章中，我們可以了解到 DCSync 的原理及檢測方法。

關于 Active Directory 復制

域控制器 (DC) 是 Active Directory (AD) 環境的核心。企業通常有多個域控制器作為 Active Directory 的備份，或者在每個區域都有不同的域控制器，方便本地身份驗證和策略下發。

由于組織中有多個域控制器，所以每一次域內配置的更改，都要同步到其他域控制器。此更改需通過 Microsoft 目錄復制服務遠程協議 (MS-DRSR)與每個域控制器同步. AD 使用多個計數器和表來確保每個 DC 都具有全部屬性和對象的最新信息，并防止任何無休止的循環復制。

AD 使用命名上下文 (NC)（也稱為目錄分區）來分段復制。每個域林至少有三個 NC：域 NC、配置 NC 和模式 NC。AD 還支持特殊的 NC，通常稱為應用程序分區或非域命名上下文 (NDNC)。DNS 使用 NDNC（例如，DomainDnsZones、ForestDnsZones）。每個 NC 或 NDNC 都相互獨立地復制。

關于 DCSync 攻擊

DCSync 是一種用于從域控制器中提取憑據的技術。在此我們模擬域控制器并利用 (MS-DRSR) 協議并使用 GetNCChanges 函數請求復制。作為對此的響應，域控制器將返回包含密碼哈希的復制數據。Benjamin Delpy 以及 Vincent Le Toux 于 2015 年 8 月在 Mimikatz 工具中添加了這項技術。

要執行 DCSync 攻擊，我們需要對域對象具有以下權限：

1）復制目錄更改（DS-Replication-Get-Changes）

2）全部復制目錄更改 ( DS-Replication-Get-Changes-All )

3）在過濾集中復制目錄更改（DS-Replication-Get-Changes-In-Filtered-Set）（不一定用，但是為了以防萬一將其開啟）

通常管理員、域管理員或企業管理員以及域控制器計算機賬戶的成員默認具有上述權限：

DCSync 攻擊場景

我們將在這篇博文中查看 2 個場景（注意：您可以想到執行 DCSync 攻擊的更多場景）：

1）假設我們已經有了一個域管理員的賬號權限

2）假設我們擁有對域有 WriteDACL 權限的用戶憑據

1) 第一個場景

假設我們已經獲得了屬于 Domain Admins 組成員的用戶賬戶。在我們的實驗室中，我們有一個名為 storagesvc 的用戶，它是 Domain Admins 組的成員，如下面的屏幕截圖所示。

所以我們現在可以使用 Invoke-Mimikatz PowerShell 腳本執行 OverPass-The-Hash 攻擊，并使用 storagesvc 用戶的權限啟動一個新的 PowerShell 控制臺:

在 New PowerShell 控制臺中，我們可以加載 Invoke-Mimikatz PowerShell 腳本并執行 DCSync 攻擊:

正如我們在上面的屏幕截圖中看到的，我們能夠成功執行 DCSync 攻擊并檢索 KRBTGT 賬戶哈希。

2) 第二個場景

假設我們已經找到了對域對象具有 WriteDACL 權限的用戶的明文憑據。在我們的實驗室中，我們有一個名為 sharepointmaster 的用戶，他對域對象具有 WriteDACL 權限，如下面的屏幕截圖所示。

我們將利用 PowerView 腳本將 DCSync 權限授予我們擁有的另一個用戶（對手）。

注意：- 我們也可以將 DCSync 權限授予 sharepointmaster 用戶。

我們將枚舉并確認對手用戶是否具有 DCSync 權限。

正如我們在上面的屏幕截圖中看到的那樣，我們能夠成功地將 DCSync 權限授予對手用戶。

現在，我們將加載 Invoke-Mimikatz PowerShell 腳本并執行 DCSync 攻擊:

正如我們在上面的屏幕截圖中看到的，我們能夠成功執行 DCSync 攻擊并檢索 KRBTGT 賬戶哈希。注意：還有其他工具也可以執行 DCSync 攻擊，例如 Impacket Library & DSInternals 等。

檢測

為了檢測 OverPass-The-Hash 攻擊、基于 ACL 的攻擊和 DCSync 攻擊，我們需要在模擬攻擊之前在域控制器上啟用少量日志。在我們的實驗中，我們已經啟用了這些日志。但是您可以按照下面提到的步驟在您的環境中啟用日志。

我們還在實驗室中部署了 Sysmon 以進行額外的日志記錄。您還可以在您的環境中使用 Sysmon 模塊化配置部署:

https://github.com/olafhartong/sysmon-modular

要捕獲登錄事件，我們需要啟用“審核登錄”日志。按照以下步驟啟用日志:

1. 登錄域控制器
2. 打開組策略管理控制臺
3. 展開域對象
4. 展開組策略對象
5. 右鍵單擊默認域策略并單擊編輯（應用于所有域計算機的策略。它可能在您的環境中有所不同）
6. 按照以下路徑啟用審核登錄事件: 計算機配置 --> Windows 設置 --> 安全設置 --> 高級審核策略配置 --> 審核策略 --> 登錄/注銷 --> 審核登錄
7. 選擇“配置以下審計事件：”復選框
8. 選擇成功和失敗復選框

要捕獲目錄服務訪問事件，我們需要啟用“審核目錄服務訪問”日志。按照以下步驟啟用日志:

1. 登錄域控制器
2. 打開組策略管理控制臺
3. 展開域對象
4. 展開組策略對象
5. 右鍵單擊默認域策略并單擊編輯（應用于所有域計算機的策略。它可能在您的環境中有所不同）
6. 按照以下路徑啟用審核登錄事件: 計算機配置 --> Windows 設置 --> 安全設置 --> 高級審計策略配置 --> 審計策略 --> DS 訪問 --> 審計目錄服務訪問
7. 選擇“配置以下審計事件：”、“成功”和“失敗”復選框

要捕獲目錄服務更改事件，我們需要啟用“審核目錄服務更改”日志。按照以下步驟啟用日志。

1. 登錄域控制器
2. 打開組策略管理控制臺
3. 展開域對象
4. 展開組策略對象
5. 右鍵單擊默認域策略并單擊編輯（應用于所有域計算機的策略。它可能在您的環境中有所不同）
6. 按照以下路徑啟用審核登錄事件: 計算機配置 --> Windows 設置 --> 安全設置 --> 高級審核策略配置 --> 審核策略 --> DS 訪問 --> 審核目錄服務更改
7. 選擇“配置以下審計事件：”、“成功”和“失敗”復選框

在我們的實驗室中，我們使用HELK設置來解析和查詢日志，并使用winlogbeat將日志從各個系統推送到HELK實例。

檢測 OverPass-The-Hash

現在讓我們運行以下查詢來檢測在執行 OverPass-The-Hash 攻擊時生成的登錄事件。

event_id ：4624

logon_type ：9

logon_process_name ：seclogo

在上述查詢中，我們可以搜索包含 logon_type 9 和 logon_process_name seclogo 的事件 ID 4624 日志。

事件 ID 4624 - 創建登錄會話時生成此事件。

登錄類型 9 - 調用者克隆了其當前令牌并為出站連接指定了新憑據。新的登錄會話具有相同的本地身份，但對其他網絡連接使用不同的憑據。當我們執行 OverPass-The-Hash 攻擊時，登錄類型為 9。

登錄進程 - 用于登錄的可信登錄進程的名稱。當我們執行 OverPass-The-Hash 攻擊時，一個名為“seclogo”的登錄進程。

在執行 OverPass-The-Hash 攻擊時，Mimikatz 嘗試訪問 LSASS 進程。運行以下查詢以檢測是否以某些特權訪問 LSASS 進程，這些特權在機器上運行 Mimikatz 以提取憑據或執行 OverPass-The-Hash 攻擊時很常見。

host_name ：“oil-attacker.oil.crude.corp”

event_id ：10

process_granted_access_orig ：（“ 0x1010”或“0x1038” ） 

在上述查詢中，我們在“oil-attacker”機器上搜索事件 ID 10 日志，該機器已授予對 LSASS 進程的特定訪問權限。我們可以在這里查找特定進程的訪問權限: 

這種攻擊也可以通過 ATA 檢測為“異常協議實現”

檢測 DCSync

我們可以運行以下查詢來確定是否執行了 DCSync 攻擊。

event_id : 4662

log_name : "Security"

object_properties : ( "1131f6aa-9c07-11d1-f79f-00c04fc2dcd2"或"1131f6ad-9c07-11d1-f79f-00c04fc2dcd2"或"89e95b76-444d-4c62-9901a ) - 

上述查詢中提到的 GUID 是執行 DCSync 攻擊所需的 Replication 權限的 GUID。

我們還可以利用網絡流量來檢測 DCSync 攻擊。需要在域控制器上安裝一個工具 DCSYNCMonitor 來監控網絡流量:

https://github.com/shellster/DCSYNCMonitor

當通過網絡執行任何復制時，此工具會觸發警報。當真正的域控制器請求復制時，這可能會觸發誤報警報。因此，建議使用 DCSYNCMonitor 工具和配置文件，我們在其中指定網絡中域控制器的 IP 地址，以避免誤報警報。

我們可以運行以下查詢來識別由 DCSYNCMonitor 工具觸發的警報: 

event_id ：1

source_name ：“DCSYNCALERT”

在上面的屏幕截圖中，我們可以看到 IP: 172.16.1.2 地址的誤報警報，因為它是真實的域控制器。這是為了在使用 DCSYNCMonitor工具時突出配置文件的重要性。

這種攻擊也可以通過 ATA 檢測為“目錄服務的惡意復制”。

檢測 ACL 修改

我們可以運行以下查詢來識別我們授予對手用戶 DCSync 權限的 ACL 修改。

event_id ：5136

log_name ：“Security”

dsobject_class ：“domainDNS” 

修改 ACL 時會生成多個事件。

事件日志計數將始終為偶數，因為單個 ACL 修改始終有 2 個事件。同樣可以通過使用“相關 ID”過濾來驗證。一個事件是“Value Deleted”（ACL 刪除/刪除），第二個事件是“Value Added”（ACL 添加/修改）。

我們還可以使用 PowerShell 命令:“ConvertFrom-SddlString”轉換“nTSecurityDescriptor”值，以獲取有關所做更改的更多詳細信息。

注意：- 此命令無法檢索 DCSync 權限的值，我們將始終將值視為“WriteAttributes”，我們需要從加入域的機器上運行此命令。

建議

建議定期審核有風險的基于 ACL 的錯誤配置，因為這可能會導致整個域環境受到損害。