高級域滲透技術之傳遞哈希已死-LocalAccountTokenFilterPolicy萬歲

大約三年前，我寫了一篇名為"傳遞哈希已死: 長久的哈希傳遞方法介紹"的文章，詳細闡述了微軟 KB2871997補丁的一些操作含義。 在安全建議中有一句特別的話,"這個功能的改變包括: 防止網路登錄和使用本地帳戶遠程交互登錄到加入域的機器... ..."使我相信(在過去3年中)補丁修改了 Windows 7和 Server 2008的行為，以防止通過非 rid 500的本地管理員帳戶傳遞哈希的能力。 我的同事Lee Christensen最近指出，儘管微軟的措辭如此，但這種說法實際上是不正確的，而且情況比我們最初認為的要微妙得多。 值得注意的是，pwnag3的開創性文章"微軟剛剛發布的KB2871997和 KB2928120打破了什麼？"也遭受了和我最初發表的文章一樣的誤解。

我們現在對這些話題有了更好的理解，並希望儘可能地澄清事實。 這是我對最終認識到 KB2871997在大多數情況下與阻止 Windows 企業使用 pass-the-hash"複雜化"毫無關係的道歉。 對於近3年來傳播錯誤信息的道歉-我希望彌補我的過錯:)一如既往，如果在這篇文章中有錯誤，請讓我知道，我會更新！

澄清 KB2871997 補丁的誤解

那麼，如果這個補丁不能自動"防止網路登錄和遠程互動式登錄到使用本地帳戶加入域的機器"，那它實際上做了什麼呢？ 正如 Aaron Margosis 所描述的，該補丁引入了兩個新的安全標識符(sid) : S-1-5-113(NT AUTHORITY Local account)和 S-1-5-114(NT AUTHORITY Administrators 用戶組的本地賬戶和成員)。 正如 微軟官方的文章中詳細介紹的那樣，可以通過組策略使用這些 sid 來有效地阻止遠程登錄使用所有本地管理帳戶。 請注意，雖然 KB2871997將這些 sid 反向移植到 Windows 7和 Server 2008 / 2012，但它們在 Windows 8.1和 Server 2012 R2 的操作系統中默認合併了。 這是Sean Metcalf 之前提到過的，Araon在微軟文章的評論中特別闡明了這一點。

旁註: 幸運的是，這也意味著在域上經過身份驗證的任何用戶都可以枚舉這些策略並查看哪些機器設置了這些限制。 我將在以後的文章中介紹如何執行這種類型的枚舉和相關性。

我錯誤地認為，這個補丁修改了 Windows 7機器上的現有行為。 自從 Windows Vista 以來，攻擊者一直無法將哈希傳遞給非內置的 RID 500 Administrator 的本地管理員帳戶(在大多數情況下，請參閱下面給出的更多內容)。 在這裡我們可以看到 KB2871997沒有安裝在基本的 Windows 7上:

然而，使用本地管理員成員的非 rid 500的admin帳戶執行 哈希傳遞攻擊會失敗:

因此，這種行為甚至在 KB2871997發布之前就存在了。 造成這種混淆的部分原因是安全警告中使用的語言，但我對沒有經過充分測試情況和轉達正確的信息負有責任。 雖然我們強烈推薦 Aaron 的建議，即在這些新的 sid 中部署 gpo，以幫助緩解內網滲透，但我們仍然對保留了KB的原始標題的權利感到得意;)

遠程訪問和用戶帳戶控制

那麼，如果補丁不影響這種行為，那又是什麼阻止了我們使用本地管理員帳戶傳遞哈希呢？ 為什麼 RID 500帳戶可以作為特殊情況運作？ 此外，為什麼作為本地管理員用戶組成員的域帳戶也不受這種阻止行為的影響？ 此外，在過去的幾年中，我們還注意到在一些約定，傳遞-哈希攻擊仍然可以在非 rid 500的本地管理員帳戶上工作，儘管補丁正在應用。 這種行為一直困擾著我們，但我們認為我們最終可以解釋所有這些矛盾。

所有這些問題的真正罪魁禍首是遠程訪問上下文中的用戶帳戶控制(UAC)令牌過濾。 我一般總是在本地主機操作的上下文中會考慮 UAC，但是這對於遠程情況也有各種各樣的含義。 微軟官方的"Windows Vista 應用程序開發對用戶帳戶控制兼容性的要求"文檔中的"用戶帳戶控制和遠程場景"部分以及"Windows Vista 中用戶帳戶控制和遠程限制的描述"部分都多次解釋了這種行為，並為我個人澄清了幾點。

對於任何非 rid 500的本地管理員帳戶遠程連接到 Windows Vista 的計算機，無論是通過 WMI、 PSEXEC 還是其他方法，返回的令牌都是"已過濾的"(即中等完整性) ，即使用戶是本地管理員。 由於沒有方法可以遠程升級到高完整性的上下文，除非通過 RDP (除非啟用"受限管理"模式，否則需要明文密碼) ，令牌才會保持中等完整性。 因此，當用戶試圖遠程訪問一個特權資源(例如 admin$)時，他們會收到一條"Access is Denied"消息，儘管從技術上講他們確實擁有管理訪問許可權。 不過，我馬上就會得到 RID 500的例外案例;)

對於本地"管理員"組中的本地用戶帳戶,"Windows Vista 用戶帳戶控制兼容性應用程序開發要求"文檔描述了以下行為:

在 Windows Vista 計算機的本地安全帳戶管理器(SAM)資料庫中擁有管理員帳戶的用戶遠程連接到 Windows Vista 計算機時，該用戶在遠程計算機上沒有特權提升的潛力，不能執行管理任務。

微軟官方發布的"描述 Windows Vista 中的用戶帳戶控制和遠程限制"的文章中用另一種方式描述了這一點:

當目標遠程計算機上的本地管理員用戶組的成員的用戶建立遠程管理連接時... ... 他們將不會以完全的管理員身份連接。 用戶在遠程計算機上沒有特權提升潛力，並且用戶無法執行管理任務。 如果用戶希望使用安全帳戶管理器(SAM)帳戶管理工作站，則用戶必須互動式地登錄到要使用遠程協助或遠程桌面管理的計算機。

對於本地"管理員"用戶組中的域用戶帳戶，文檔中有如下聲明:

當擁有域用戶帳戶的用戶遠程登錄到 Windows Vista 計算機，並且該用戶是 Administrators 用戶組的成員時，域用戶將使用遠程計算機上的完全管理員訪問令牌運行，並且遠程計算機上的用戶在該會話期間會禁用 UAC。

這就解釋了為什麼本地管理帳戶在遠程訪問時會失敗(除了通過 RDP) ，以及為什麼域帳戶卻是成功的。 但是，為什麼內置的500 RID 管理員帳戶會作為一個特殊情況呢？ 因為默認情況下，內置管理員帳戶(即使重命名)使用了完全的管理特權("完全令牌模式")運行了所有的應用程序，這意味著用戶帳戶控制沒有得到有效應用。 因此，當使用此帳戶啟動遠程操作時，將授予完全高完整性(即未過濾的)的令牌，允許正確的管理訪問！

只有一個例外——"管理批准模式"。 指定此選項的註冊表鍵位於 HKLMSOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystemFilterAdministratorToken，默認情況下是禁用的。 但是，如果啟用此密鑰，RID 500帳戶(即使已重命名)將被註冊為 UAC 保護。 這意味著使用該帳戶的機器的遠程 PTH 將會失敗。 但是對於攻擊者來說，還有一線希望——這個密鑰通常是通過組策略設置的，這意味著任何經過域身份驗證的用戶都可以通過 GPO應用程序枚舉機器所做的事情以及不設置 FilterAdministratorToken鍵值。 雖然這會忽略在標準"gold"鏡像上設置鍵值的情況，但是從攻擊者登陸的初始機器上執行這個鍵值枚舉，結合 GPO 枚舉，應該可以覆蓋大多數情況。

請記住，儘管 Windows 默認禁用了內置的500 Administrator 帳戶，但在企業中啟用該帳戶的情況仍然相當普遍。 我最初發表的關於 pass-the-hash 的文章涵蓋了這些信息的基本遠程枚舉，這篇文章將進一步詳細介紹這些信息。

LocalAccountTokenFilterPolicy

對於我們攻擊者來說，還有一線希望，還有一些比我們最初意識到的更具防禦意義的東西。 Jonathan Renard 在他的"*Puff* *Puff* PSExec"的文章中提到了其中一些東西(以及管理員批准模式) ，但是我想擴展一下關於整個 pass-the-hash 討論的內容。

如果 HKLMSOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystemLocalAccountTokenFilterPolicy 鍵存在(默認情況下不存在)並設置為了1，那麼在協商期間，管理員用戶組的所有本地成員的遠程連接都被授予完全高完整性的令牌。 這意味著非 rid 500帳戶連接不會被過濾，並且可以成功地傳遞哈希！

那麼為什麼要設置這個註冊表條目呢？ 在谷歌上搜索這個關鍵名稱會出現不同的情況。在我們現在所說的這種情況下，這是一種解決方案，但有一個常見的功能: Windows Remoting。 有大量的微軟文檔建議將 LocalAccountTokenFilterPolicy 設置為1，來作為解決各種問題的方法或解決方案:

·「不建議通過更改控制遠程 UAC 的註冊表項來禁用遠程 UAC，但可能有必要..」

·「Set-ItemProperty –Path HKLM:SOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystem –Name LocalAccountTokenFilterPolicy –Value 1 –Type DWord」

·「用戶帳戶控制(UAC)會影響對 WinRM 服務的訪問」

·「... 你可以使用 LocalAccountTokenFilterPolicy 註冊表項來更改默認行為，並允許管理員用戶組的成員的遠程用戶使用 Administrator 特權運行」

·「如何禁用 UAC 遠程限制」

此外，我相信在某些情況下，WinRM 的quickconfig 命令甚至可以自動設置這個鍵，但是我不能可靠地重新創建這個場景。在微軟的"從遠程計算機獲取數據"的文檔中做了進一步的詳細解釋:

由於使用了用戶帳戶控制(UAC) ，遠程帳戶必須是域帳戶和遠程計算機 Administrators 用戶組的成員。 如果帳戶是 Administrators 用戶組的本地計算機成員，則 UAC 不允許訪問 WinRM 服務。 要訪問工作組中的遠程 WinRM 服務，必須通過創建以下 DWORD 註冊表項並將其值設置為1來禁用針對本地帳戶的 UAC 過濾: [HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystem] LocalAccountTokenFilterPolicy。

這是個壞建議，壞壞壞壞壞透了的建議！ 我意識到可能需要這個設置來幫助一些特定的 WinRM 部署場景，但是一旦 LocalAccountTokenFilterPolicy 被設置為1，那麼就可以使用機器上的 任何（注意是任何！）本地管理員帳戶來向目標傳遞-哈希。 我覺得大多數人，包括我自己，還沒有意識到這個修改所隱含的實際安全含義。 我在所有的微軟文檔中看到的唯一真正的警告是"注意: LocalAccountTokenFilterPolicy 條目將禁用所有受影響的計算機的所有用戶的用戶帳戶控制(UAC)遠程限制。 在改變策略之前，要仔細考慮這種背景的影響。"。 由於這種設置會給企業環境帶來巨大的風險，因此我希望從微軟那裡得到更好的明確指導和警告，而不僅僅是"考慮其影響"，但是ˉ\_(ツ)_/ˉ

從操作角度來說(從攻擊性的角度來看) ，最好檢查一下你的跳板機器上是否將 LocalAccountTokenFilterPolicy 鍵設置為了1，因為同一子網或OU中的其他機器也可能具有相同的設置。 你還可以列舉組策略設置，看看這個註冊表鍵是否是通過 GPO 設置的，這也是我將在以後的文章中討論的內容。 最後，你可以使用 PowerView 列舉任何啟用了 Windows Remoting 的 Windows 7和 Service 2008機器，希望它們運行的 Windows Remoting 沒有正確設置:

Get-DomainComputer -LDAPFilter "(|(operatingsystem=*7*)(operatingsystem=*2008*))" -SPN "wsman*" -Properties dnshostname,serviceprincipalname,operatingsystem,distinguishedname | fl

同樣值得注意的是，微軟的 LAPS 實際上讓這裡的一切都變得毫無意義。 由於 LAPS 定期為計算機隨機設置本地管理員密碼，所以傳遞哈希仍然可以有效地工作，但它極大地限制了恢復和重用本地密鑰的能力。 這使得傳統的 PTH 攻擊(至少是本地賬戶)基本上變得無效。

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