幾種常見遠程訪問策略詳解

在進行模擬攻擊時，測試員總會試圖隱蔽自己的攻擊行為，通常他們都會先提前列舉一些隱蔽策略，這種提前列舉的辦法不但可以避免在無法獲取的攻擊路徑上浪費時間，而且還在一定程度上降低了被檢測到的風險。

其中一個常用的策略就是獲得本地管理員密碼哈希或純文本憑據，以進行不同安檢環境中的身份驗證，我們通常將其稱為遠程訪問策略。在Windows中就有兩個值得注意的遠程訪問策略，它們都會對隱藏攻擊行為產生影響。這兩個遠程訪問策略分別是用戶帳戶控制(UAC)和用戶許可權分配(URA)。由於它們的配置不同，所以如果操作不當，模擬攻擊就會被檢測到，這種遠程訪問策略可以在本地執行或遠程執行中被用到。

如果你對UAC和URA以及如何利用組策略將其設置映射到特定計算機對象，你可以先找一些資料預熱一下。

遠程訪問策略的用例：UAC和URA

本節會重點介紹一些UAC和URA配置選項，這些選項可以通過組策略設置。另外，我還會介紹它們影響遠程身份驗證的整個過程，我將稍後討論它們的存儲位置以及如何枚舉它們。

UAC的目的是提供一種隔離進程的方法，使其能夠在不同的完整性級別或可信任級別運行。影響UAC行為的設置將被作為註冊表項屬性被存儲在HKEY_LOCAL_MACHINE註冊表配置單元的以下位置：

HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystem

在遠程身份驗證中，有三個顯著的屬性會影響UAC行為，這些設置都決定了如何為本地管理員組內的用戶的遠程連接篩選訪問令牌。在實際操作中，這些設置會控制是否可以執行遠程身份驗證並獲得一個高完整性訪問令牌，或者是否將其過濾為較低的完整性級別。從安全性評估的角度來看，你需要一個高完整性訪問令牌來建立遠程管理訪問。

EnableLUA用於啟用計算機的(1，默認)或禁用(0)「Admin Approval」模式。不夠在目前的安全文獻中，很少誘人提到這種設置的效果，然而，這對於UAC的運行是不可或缺的。如果禁用，所有UAC策略也將被禁用。禁用時，可以使用純文本憑據或密碼哈希對本地管理員組的任何成員執行遠程身份驗證許可權。在遠程身份驗證過程中，本地管理員的所有訪問令牌均會被設置為高完整性。啟用時,享有遠程身份驗證功能許可權是由LocalAccountTokenFilterPolicy和FilterAdministratorToken的設置確定的。

LocalAccountTokenFilterPolicy是用於控制過濾本地管理員組中所有本地用戶的遠程連接訪問令牌的策略。當設置為0(默認值)時，具有高完整性訪問令牌的遠程連接只能使用RID 500本地管理員的純文本憑據或密碼哈希並且僅依賴於filteradminstratortoken的設置。而對於非RID 500本地管理員，可以對遠程連接的訪問令牌進行過濾即中等完整性。如果設置為1，則策略允許使用明文憑據或密碼哈希，從本地管理員組的任何成員獲得高完整性訪問令牌的遠程連接。Will Schroeder（@ harmj0y）在他的博客文章中提供了LocalAccountTokenFilterPolicy角色的進一步細節，闡明了KB2871997對傳遞哈希（passing-the-hash）或缺少哈希的影響。

要注意的是，即使LocalAccountTokenFilterPolicy設置為0，如果EnableLUA被禁用（0），那麼沒有UAC強制過濾，EnableLUA同樣會優先。

filteradminstratortoken用於為RID 500本地管理員啟用（1）或禁用（0，默認）「Admin Approval」模式。啟用後，RID 500本地管理員的訪問令牌將被過濾即中等完整性，此時，明文憑證或密碼哈希就無法使用，這意味著RID 500本地管理員執行遠程身份驗證許可權是不可能的。在標準Windows版本中，LocalAccountTokenFilterPolicy和FilterAdministratorToken的默認設置解釋了為什麼只能使用RID 500本地管理員帳戶來執行特權遠程驗證。雖然默認情況下是禁用的，但也有例外，比如通過黃金映像啟用FilterAdministratorToken，然後通過對特定計算機對象的組策略選擇性地禁用此功能。這種情況下，測試人員就可以在不被檢測到的情況下，使用RID 500本地管理員的任何識別憑證來發起攻擊。

儘管這三個註冊表關鍵屬性都位於Windows註冊表中的同一個位置，但它們通過組策略配置的方式以及它們如何存儲在組策略配置文件中的方式都有所不同，了解其中的區別對於理解如何枚舉是至關重要的。

配置EnableLUA和FilterAdministratorToken

EnableLUA和filteradminstratortoken都在組策略管理編輯器中有明確的配置選項。對於EnableLUA來說，這是「用戶帳戶控制:運行管理審批模式的所有管理員」和filteradministrator的「用戶帳戶控制:內置管理員帳戶的管理審批模式」。這些設置可以在以下位置找到：

->計算機配置

->政策

->窗口設置

->安全設置

->本地政策

->安全選項

->「用戶賬戶控制：內置管理員賬戶管理審批模式」

->「用戶帳戶控制：管理審批模式下的所有管理員」

「安全選項」設置存儲在一個名為「gpttmpl」的INF配置文件中，INF在每個域控制器託管的SYSVOL共享的相關組策略容器中。

\Policies{}MachineMicrosoftWindows NTSecEditGptTmpl.inf

下圖顯示了「EnableLUA」被禁用的情況。

配置LocalAccountTokenFilterPolicy

LocalAccountTokenFilterPolicy不能通過組策略管理編輯器中的顯式配置選項（explicit configuration option ）進行設置。相反，它需要通過自定義註冊表項屬性的定義進行設置。在組策略管理編輯器中，設置可以在以下位置完成：

->計算機配置

->首選項

->窗口設置

->註冊表

->

這樣做的結果是配置存儲在組策略容器內的不同位置，這一次是一個名為Registry.xml的XML文檔。

\SYSVOL\Policies{}MachinePreferencesRegistryRegistry.xml

下圖就是啟用LocalAccountTokenFilterPolicy（1）的Registry.xml配置的範例：

用戶許可權分配：SeDeny* ?

URA在規定了用戶可以對系統進行身份驗證的方式，同時也為用戶使用某些特權提供了一些方法，不過影響URA行為的設置在Windows註冊表中是無法查到的。

有兩個顯著的URA設置會影響遠程身份驗證，且每一個都以SeDeny*前綴開頭，可以通過組策略進行配置。

SeDenyNetworkLogonRight用於拒絕某些用戶或組執行網路身份驗證的功能，例如，通過遠程過程調用(RPC)端點映射器和伺服器消息塊(SMB)服務使用該身份驗證。

SeDenyRemoteInteractiveLogonRight用於拒絕某些用戶或組執行遠程桌面協議（RDP）服務使用的遠程互動式身份驗證的功能。

如果用戶或組與這些設置中的任何一個相關聯，則通過相關協議隨意使用所需的認證將不可能。也就是說，通過將它們與設置關聯起來，它們就不能執行某些類型的身份驗證。

你可能會認為防止本地憑據被濫用的一種方法是將這些設置與內置的「管理員」組相關聯，但其實這是一個被誤解的方法，因為這麼做會影響該組內的所有對象，包括已包含在其中的域用戶和組。例如，在默認情況下，「域管理員」組位於加入域的計算機對象的內置「管理員」組中，儘管其內部具有一些特別許可權，但也不可能通過使用這些帳戶的相關協議進行身份驗證。

除上述URA設置之外，還應該注意的是，還有一些類似的SeDeny *設置可以拒絕用戶或組執行本地身份驗證或直接取消身份驗證的功能。

配置SeDenyNetworkLogonRight和SeDenyRemoteInteractiveLogonRight

SeDenyNetworkLogonRight和SeDenyRemoteInteractiveLogonRight在組策略管理編輯器中有明確的配置選項，對於SeDenyNetworkLogonRight，是「拒絕從網路訪問此計算機」，而對於SeDenyRemoteInteractiveLogonRight則是「拒絕通過遠程桌面服務登錄」。這些設置可以在以下位置找到：

->計算機配置

->政策

->窗口設置

->安全設置

->本地政策

->用戶許可權分配

->「拒絕從網路訪問這台計算機」

->「拒絕通過遠程桌面服務登錄」

可以看出「用戶許可權分配」設置與UAC設置中的「安全選項」所使用的「gpttmpl.inf」SYSVOL文件相同。

\Policies{}MachineMicrosoftWindows NTSecEditGptTmpl.inf

下圖就是SeDenyNetworkLogonRight和SeDenyRemoteInteractiveLogonRight配置為包含內置「管理員」組的情況，該組在配置中是通過其眾所周知的SID「S-1-5-32-544」 自動表示而不是組名稱。

使用PowerView枚舉遠程訪問策略

通過了解UAC和URA策略以及它們是如何影響遠程身份驗證，以及這些策略如何存儲在組策略容器中，我就可以開始枚舉它們了。為此，PowerSploit框架內的PowerView將會被大量使用。此外，我還創建了三個函數來幫助枚舉遠程訪問策略，分別是：Find-ComputersWithRemoteAccessPolicies ，Get-DomainGPORemoteAccessPolicy和Get-RegistryXML。這些函數的代碼可以在MWR Labs的Github找到。

Get-DomainGPORemoteAccessPolicy是包含了許多附加功能的核心功能，並標識建立感興趣的遠程訪問策略的GPO。該功能與現有的Get-DomainGPOLocalGroup非常相似，即使用PowerView的Get-DomainGPO檢索每個GPO的詳細信息，並檢查每個組策略容器的內容以查找GptTmpl.inf和Registry.xml文件。如下圖所示，PowerView通過在每個GPO對象的「gpcfilesyspath」屬性中提供對組策略容器的路徑，來使此過程變得容易。

由於PowerView已經提供了解析Get-GptTmpl中的GptTmpl.inf文件的功能，因此，Get-DomainGPORemoteAccessPolicy只需檢查感興趣的註冊表項的返回對象。但是，Registry.xml不存在這樣的現有函數。儘管如此，所需的功能也會關閉PowerView的Get-GroupsXML。 Get-RegistryXML雖然會對Registry.xml執行類似的操作，但返回的卻是包含經過註冊表修改的PSObjects列表。

以下代碼片段顯示了執行上述操作的Get-DomainGPORemoteAccessPolicy功能的一個子集，即檢索每個GPO，並通過將EnableLUA屬性設置為0來檢查是否禁用UAC。

Get-DomainGPO @SearcherArguments | ForEach-Object {

$GPOdisplayName = $_.displayname

$GPOname = $_.name

$GPOPath = $_.gpcfilesyspath

# EnableLUA and FilterAdministratorToken check via GptTmpl.inf

$ParseArgs = @{ "GptTmplPath" = "$GPOPathMACHINEMicrosoftWindows NTSecEditGptTmpl.inf" }

if ($PSBoundParameters["Credential"]) { $ParseArgs["Credential"] = $Credential }

# parse the GptTmpl.inf file (if it exists) for this GPO

$Inf = Get-GptTmpl @ParseArgs

if($Inf -and ($Inf.psbase.Keys -contains "Registry Values"))

{

$EnableLUA = $Inf["Registry Values"]["MACHINESoftwareMicrosoftWindowsCurrentVersionPoliciesSystemEnableLUA"]

if ($EnableLUA -and ($EnableLUA[0] -eq 4) -and ($EnableLUA[1] -eq 0))

{

Write-Verbose "The following GPO enables pass-the-hash by disabling EnableLUA: $GPOdisplayName - $GPOname"

# append to EnableLUA GPO list if it is not already there

if ($RemoteAccessPolicies.EnableLUA -notcontains $GPOname) { $RemoteAccessPolicies.EnableLUA += $GPOname }

}

Get-DomainGPORemoteAccessPolicy會返回一個哈希表，其中就包含了要搜索的每個屬性的名稱（例如，EnableLUA），並且該哈希值是該屬性被設置為感興趣的值的GPO的列表。

Get-DomainGPORemoteAccessPolicy不是直接調用，而是作為Find-ComputersWithRemoteAccessPolicies的輔助函數。 Find-ComputersWithRemoteAccessPolicies會作為一個封裝器接受Get-DomainGPORemoteAccessPolicy的輸出, 先確定GPO鏈接到的組織單位，然後確定這些組織單位中的計算機對象。PowerView再次將組織單元和GPO之間的鏈接建立起來，因為Get-DomainOU函數返回的對象包含一個「gplink」屬性，該屬性描述了所鏈接的GPO。

下面顯示了Find-ComputersWithRemoteAccessPolicies執行上述過程的代碼片段，它將遠程訪問策略設置的計算機對象添加到哈希表中，其中密鑰為policy，值為DNS主機名列表。

$RemoteAccessPolicies = Get-DomainGPORemoteAccessPolicy @gpoSearchArguments

$RemoteAccessPolicies.PSObject.Properties | ForEach-Object {

$policy = $_.Name # EnableLUA, etc

foreach ($guid in $RemoteAccessPolicies.$policy) {

# set arguments for OU search (readding $SearchBase to limit the scope)

$ouSearchArguments = @{}

$ouSearchArguments = $ouSearchArguments + $SearcherArguments

$ouSearchArguments["GPLink"] = $guid

Get-DomainOU @ouSearchArguments | ForEach-Object {

$compSearchArguments = @{}

$compSearchArguments = $compSearchArguments + $SearcherArguments

$compSearchArguments["SearchBase"] = $_.distinguishedname

$OUComputers = Get-DomainComputer @compSearchArguments

$OUComputers | ForEach-Object {

if ($ComputerObjectsWithRemoteAccessPolicies.$policy -notcontains $_.dnshostname) { $ComputerObjectsWithRemoteAccessPolicies.$policy += $_.dnshostname }

下圖顯示了由Find-ComputersWithRemoteAccessPolicies返回的這個對象，以及如何利用它來識別實施攻擊的目標。

假設所有計算機對象都具有本地管理憑據重用的黃金映像，那麼UAC就已經在三個計算機對象上通過EnableLUA被禁用了，這就為重新使用非rid 500憑據信息創造了機會。但是，由於「管理員」組包含在其中兩台主機（「HR-COMPUTER-1」和「HR-COMPUTER-2」）的SeDenyNetworkLogonRight設置中，所以可防止使用虛假的網路認證發起攻擊，這也將阻止使用RID 500「管理員」帳戶被黑客利用。而對於其餘的計算機對象（「DEV-COMPUTER-1」），則可以通過重用任何本地管理憑證（RID 500和非RID 500）發起攻擊。對於所有計算機對象，如果可以獲得內置「管理員」組中的用戶的明文憑證，則可以將這些憑證用於遠程互動式驗證（例如RDP）。這是因為通過SeDenyRemoteInteractiveLogonRight這樣的身份驗證並沒有被明確地禁止。下圖就是這個攻擊路徑的流程示意圖：

總結

這篇文章描述了為特定策略設置枚舉組策略的過程，並確定了可以應用的計算機對象。具體來說，為了確定計算機對象，由於UAC和URA設置，可以將本地證書資料重新用於遠程認證。為此，我還還製作了一組PowerView擴展，你可以在MWR Labs的Github上找到這些活動。

雖然遠程訪問策略是本文的重點，但通過簡單的例子介紹，你也知道了如何將相同的方法應用到任何其他策略設置中。例如，如果通過組策略強制執行設置，則攻擊者就可以使用它來識別正在運行的計算機對象。因為攻擊者可以檢測到與SYSVOL交互的合法流量的數量，這樣的攻擊方法對於安全防護人員來說無疑是一種挑戰。 SYSVOL是指存儲域公共文件伺服器副本的共享文件夾，它們在域中所有的域控制器之間複製。 Sysvol文件夾是安裝AD時創建的，它用來存放GPO、Script等信息。同時，存放在Sysvol文件夾中的信息，會複製到域中所有DC上。

目前通過 GPO 枚舉遠程訪問策略的主要限制有兩個:

1. 組織單元和GPO之間的關聯是一個簡單的關聯關係，而不是PowerShell重新實現的策略的結果集 (Resultant Set of Policy, RSoP)，如果能實現RSoP，則允許黑客查看目標用戶或計算機應用組策略後產生的效果。因此，就不會考慮到組策略層次結構（例如，一個GPO覆蓋另一個GPO的設置）。另外，這還意味著無法機芯有針對性的搜索（例如通過-SearchBase 」）不會捕獲在其他組織單元中建立的設置。

2.不會考慮對GPO進行安全性過濾。

儘管存在這些限制，但這種方法確實提供了一種有趣的遠程訪問策略來快速地對潛在的計算機對象進行攻擊。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！