2022 年 10 月，奧義智慧資深資安威脅研究員姜尚德 (John Jiang) 與資安軟體工程師孫維崗 (Gary Sun) 遠赴美國參加 SANS Blue Team Summit，以「Don’t Relay Me: Empirically Diagnose Privilege Escalation via Active Directory Account Sighting」為題發表演說。
SANS Blue Team Summit 是一年一度環繞在藍隊相關技術的研討會，「SANS」一詞包含了系統管理、稽核、網路和安全 (SysAdmin, Audit, Network, Security) 等項目，旨在聚集業界領先的藍隊專家們，分享他們針對相關議題的獨特見解、實務經驗等。
在這場演講之中，兩位講師帶領聽眾深入探討了 Active Directory 上身分驗證的重送攻擊 (Relay Attack) 技術與成因，並且借鑒奧義智慧科技在實務上進行 AD 調查的經驗，進一步討論究竟該如何使用 PsExec、RDP 等遠端管理工具，才能擁有較高的安全性。而在演講的最後，他們也針對企業的應用需求，提出了相應的操作建議與緩解措施。
本文將統整該篇演講的研究內容，並向讀者說明其中所利用的各項技術。
Active Directory (AD) 是由微軟所開發的集中化驗證服務，主要用於管理網路中的資源和使用者資訊。想像一下，AD 在網路中所扮演的角色，其實就類似於一個巨大的電話簿或者地圖，能夠幫助公司內的電腦、伺服器和使用者們找到彼此，同時也控制著哪些使用者可以訪問、存取哪些資源，例如允許員工 A 可以訪問文件夾 X 等。
除此之外，AD 另一個具有強大功能的工具，則是「群組管理原則」(Group Policy Object, GPO)。GPO 是用於管理使用者和電腦設定的一種機制，系統管理員可以經由 GPO，一次性地完成多台電腦的配置設定，諸如軟體安裝、安全性措施或者網絡設定等。而這也意味著，企業的 IT 人員並不需要逐一為每台電腦設定防火牆或者更新軟體，只需要在 AD 中設定一次 GPO，便能夠一併派送應用到組織中的許多台機器之上。
正因為 Active Directory 和 GPO 能夠集中管理如此多的設定和權限，它們在資訊安全方面扮演著極其重要的角色，一旦 AD 或 GPO 設定不當導致了弱點產生，攻擊者便可能獲取他們理應無法得到的訪問權限、或者利用配置上的弱點展開攻擊和惡意利用。因此，妥善地配置和維護 AD 與 GPO 不僅能讓企業營運更有效，也是確保網絡安全的基礎。
奧義智慧透過我們研發的 AD Attack Path Assessment 攻擊路徑模擬評估服務，為許多客戶檢視過網路場域的安全性，其中，最常見的 AD 安全問題不外乎是錯誤設定與權限設定問題，這些設定上的問題大多都是靜態資料，但人為操作導致的憑證外洩等動態資料，也仍然至關重要。
在這場 Blue Team Summit 的演講中，我們便以上圖舉例說明，假設圖上紅點為各個使用者或電腦，從臺灣最北部要移動到最南端，只能透過東部或是西部這兩條既知路徑，除非你強行開路橫跨中央山脈；這就好比針對 AD 物件，一個使用者可能要透過各種權限來存取網域控制站，而實際上這兩條就是最需要注意的。
然而，由於使用者憑證可能會被竊取、或遭遇 NTLM Relay 攻擊，使用者登入到不同端點有可能導致更多的攻擊路徑產生，以上圖為例，隨著登入資訊 (Logon Signing) 增加，潛在攻擊路徑便呈現了幾何成長，其中，網域控制站曾登入到其中一台電腦，使得攻擊路徑中出現了新的端點，該端點在靜態路徑分析時並未被觀察到，這也使得防守方需要照顧的防禦邊界隨之增加。
針對駭客如何獲取與利用 Logon Signing，實務上對應了四種常見的攻擊工具：
在實際應用情境中，防守方必須要應對這些攻擊模式，下圖為攻防技術的對應圖表，我們將攻擊手法主要分為 Cached Credentials 與 Relay Auth 兩種類型，其中又再詳細劃分出不同攻擊手法、以及相應的不同緩解方式。然而，其中有些緩解方式並不能完全緩解問題，只能改善部分的問題，這也使得防守方的資安人員相當困擾。
本篇文章中，我們將暫時把 Cached Credentials 的緩解放到一邊，專注在探討 Relay Auth 的部分，深入了解 Relay Auth 的攻擊手法與其相關的防守技術。
Relay Auth 的特別之處在於，有一些攻擊手法可以攻擊 Computer Account，一般來說，我們在竊取憑證時大多關注和嘗試竊取使用者登入資訊，但對 Relay Auth 的攻擊而言，電腦登入其實也可能被竊取且轉送到其他服務。
若是更深入一點仔細看 NTLM Relay 後指向的緩解方式「Use Kerberos」，對 NTLM Relay 相對熟悉的人可能會認為，使用 Kerberos 確實就不會遭受到 NTLM 攻擊，但現實中就算使用者覺得自己在使用 Kerberos 進行驗證，也可能驗證過程被攻擊者 downgrade 成了 NTLM，這就是本篇文章將深入討論的觀點。
若是對於 NTLM Relay 攻擊尚不熟悉，建議您可先閱讀 Pixis 寫的這篇關於 NTLM Relay 的介紹：https://en.hackndo.com/ntlm-relay/。
想了解攻擊者如何做到 Downgrade Kerberos to NTLM，首先我們必須先了解，針對使用 NTLM 或使用 Kerberos 這一點上，Windows Authentication process 是怎麼決定的。
事實上，要使用這兩者之中哪一種協定，主要取決於軟體的實作。其中，若直接使用 NTLM 就代表使用 SSP (Security Support Provider) Layer 的 msv1.0.dll；而如果想在軟體中使用 Kerberos，則必須使用到本文將探討的重點－－spengo.dll。
後者有著明顯的優點，除了可以支援 Kerberos 之外，使用 spengo 也使得應用程式能夠在 Kerberos 無法建立連線時改走 NTLM，但於此同時，這也造就了更多被攻擊的可能性。
在前述關於驗證的段落中，我們提到了需要使用 spengo.dll，這是一種替 GSS-API 提供的協商機制。SPNEGO 為參與身份驗證的雙方提供了一個框架，讓雙方進行協商、並從中選出兩邊都能接受的驗證方式。
如同下方簡單的流程圖所示，Client 端要與 Server 進行連線時，首先會送出 NegoTokenInit 表明自己支援的驗證方式，這是一份有優先順序的清單，而 Server 會從這個支援驗證方式的優先序清單中，挑出自己同樣支援且優先權在比較前面的驗證方式，並透過 NegoTokenResponse 回傳支援的驗證方式，完成這段來回協商的過程後，最後 Client 端便會用雙方取得共識的這項驗證方式，將驗證資訊傳送給 Server。
從上述的說明中不難發現到，倘若被連線的 Server 端遭受攻擊與 Compromise 的話，攻擊者有機會可控制在這次的連線中，要使用 Kerberos 還是 NTLM 來進行驗證，而這也正中攻擊者的下懷，因為如此一來，攻擊者便有機會能竊取到 Client 端的憑證。
緊接著在這個章節，我們將開始說明攻擊工具與架構。在開始說明前，首先我們想要感謝 @_EthicalChaos，能達成此攻擊多虧了他所開發的 PoC 工具 Lsarelayx。
Lsarelayx 透過對 msv1.0.dll、lsasrv.dll、spnego.dll 做 hook 以攔截驗證封包，並對 spnego.dll 強制任何連線都優先採用 NTLM，而 hook msv1.0.dll 則是為了取得 NTLM 驗證內容，舉例來說，是在 NTLM Relay 中我們要移除 signing 或是轉送封包到 RAW Server (ntlmrelayx)，ntlmrelayx 是 impacket 專案底下的一個攻擊工具，基本上支援所有 NTLM relay 後要做到所有攻擊。
緊接著，就要開始探討攻擊情境了。下表中我們整理出了一些可以被 Relay 的 Service，撇開在 NTLM Relay 文章中常見的，透過 PSEXEC 或存取 CIFS 等網路分享資源來進行 Relay 等方式，我們整理出如下表中這些較為不同、但都常在真實場域中見到的服務。本文中，我們會針對其中比較特殊的 SCCM、Microsoft SQL 與第三方弱點掃描工具，以這三項案例進行探討，讓大家更加了解使用上述工具時應如何加以留意防範。
微軟系統中心配置管理器 (Microsoft System Center Configuration Manager, SCCM) 是一款由 Microsoft 開發的系統管理軟體，方便系統管理員有效地管理各個作業系統，其本身能夠與 Active Directory 結合，達到遠端安裝 Agent、遠端控制、系統更新、佈署軟體等功能。而在我們的實測中，驗證部分事實上分為兩種：
MSSQL 是微軟的資料庫系統，同時也是許多人會採用的 SQL 之一，其本身支援遠端存取 SMB 資源，因此本質上也是透過 CIFS，也就是說，利用到 MSSQL 的這段過程也是能夠被 Relay 的；而除了這個普通的情境之外，更重要的問題是如果 SQL Server 被 Compromised，駭客是否能夠 Relay 到管理人員的登入資訊呢？這個問題的答案，是可能的。
以下是 MSSQL 在執行驗證時，會如何決定走 Kerberos 或 NTLM 的流程示意圖，對於不同版本的 MSSQL 或許會有些微差別。雖然 MSSQL 在做 Kerberos 登入驗證時也是採用 SPENGO，但此處的軟體設計的很好，因為 MSSQL 在這個地方僅僅支援 Kerberos。
所以，只有當遠端連線且 MSSQL 在 Active Directory 中 Service Principal Name (SPN) 不存在時，才會選擇採用 NTLM，但由於我們的攻擊情境中假設前提是 SQL Server 已被 Compromised，所以要移除 MSSQL 的 SPN 事實上相當容易，並且管理人員在連線 SQL 時，甚是可能完全無法察覺出變化。
最後一個攻擊情境，是某個知名的第三方弱點掃描工具，但在本文中我們將不會提到軟體的名稱，同時我們也相信，這個攻擊手法其實通用於所有概念類似的產品，所以這只是其中一個例子。許多企業組織都會定期對端點做自動化的弱點掃描，然而，要能做到弱點掃描自動化、或者盤點端點上是否裝有未更新的軟體，這類工具通常都會支援所謂的「無 Agent」模式，而要利用此模式，勢必需要提供一個可以登入到端點的高權限帳號，並且往往會是通用的高權限帳號，只要能獲得一次就能登入到許多台電腦。
而我們調查了弱點掃描工具後，發現到這類工具在提供高權限帳號時的實作方式並不安全。如附圖中所示，在提供高權限帳號時雖然可以從 Kerberos、NTLM、Password 之中選擇驗證方式，但事實上調整的是掃描工具向連線目標端點所提供的支援驗證清單順序，這也就是說，即便在弱點掃描工具上選擇 Kerberos，依舊有可能遭到 Relay，而這也大幅增加了連線到已被 Comproised 的端點時，高權限帳號被 NTLM Relay 的風險。
在這篇文章中，我們介紹了許多種攻擊可能性，那麼於此同時，企業防守方要如何防止遭遇這些攻擊、並因此而承受損失呢？實務上，我們很難完全禁止 NTLM 在 Active Directory 的使用，因此，我們提供下方這些建議的緩解措施：
Protected Accounts 群組中，便可以達到一定程度的保護，細節敬請參考這篇 Microsoft 所發表的文件：https://learn.microsoft.com/en-us/windows-server/security/windows-authentication/how-to-configure-protected-accounts。
NTLM Relay 仍存在於許多地方，由於場域兼容性與軟體相容性，很多場域都還是相當容易遭受這類攻擊，是一項絕對不應忽視的潛在風險；此外，即便是 Exchange 相關議題，在近年來都有許多漏洞與 NTLM Relay 有所關聯，由此可知，類似於 NTLM Relay 這樣的實作問題，並不只因第三方軟體開發商未能注意而發生，還可能有更多潛藏未被發覺的危險實作，企業應多加留意並謹慎以對。