因此，這個想法很簡單，你可以登錄到你的混合 Azure AD 加入的 Windows 10 設備并自動訪問云和本地資源,。FIDO2 安全密鑰成為進入云和本地資源的途徑,。

　　Microsoft 之前僅針對加入 Azure AD 的設備發(fā)布了相同的功能，但現(xiàn)在范圍已擴展到混合環(huán)境,。

　　一個新的證書收集攻擊向量涉及只讀域控制器服務器,，讓我們看看從研究新功能到實現(xiàn)對Impacket的新攻擊的所有方法。

　　Azure 中的無密碼體驗

　　如上所述,，Microsoft 通過 Azure Active Directory 將無密碼體驗擴展到本地資源,。既然我們談論的是本地資源的 SSO 功能，那就要先了解一下 Kerberos,。

　　Kerberos 是主要的身份驗證協(xié)議,，用于驗證 Windows 域中的安全對象（用戶或主機）的身份。它基于對稱密碼學（共享秘鑰）并使用票據(jù)的概念來驗證這些身份,。粗略地說,，Kerberos 發(fā)出兩種票據(jù)，一種是驗證對象身份的票據(jù)授予票據(jù) （TGT）,，另一種是對象用于對域中的其他服務進行身份驗證的服務票據(jù),。

　　假設我想訪問在服務器 A 中運行的服務 1。身份驗證流程如下：

　　Kerberos 身份驗證

　　很清楚,、很簡單?，F(xiàn)在讓我們把事情弄得更復雜一點。讓我們將這種情況轉(zhuǎn)移到混合環(huán)境,。使用安全密鑰的身份驗證流程如下：

　　無密碼身份驗證

　　可以看到部分 TGT 交換完整的TGT,，以及在云中復制的 Kerberos 服務器密鑰。這是怎么回事,？讓我們開始深入研究這個問題,。到目前為止，只有位于域控制器上的密鑰發(fā)布中心 （KDC） 服務有權(quán)發(fā)布 TGT,。但是,，這種新的無密碼體驗的引入使事情發(fā)生了一些變化：正如我們在之前的流程中看到的那樣，Azure AD 現(xiàn)在可以為一個或多個域發(fā)出 Kerberos TGT,！這讓我想到了另一個問題,，krbtgt 帳戶呢？

　　KDC 在任何域中使用的安全對象是 krbtgt 帳戶。這是一個無法刪除,，也無法更改名稱的特殊帳戶,，其密碼用于派生密鑰，用于加密 KDC 發(fā)布的 TGT,。出于顯而易見的原因,，此帳戶不會離開 AD 服務器。那么,，Azure AD 如何在沒有這個特殊帳戶的情況下發(fā)布 TGT,？以下是 Azure AD Kerberos 服務器對象圖出現(xiàn)的位置。

　　Kerberos 服務器對象屬性

　　Azure AD Kerberos 服務器是在本地 AD 中創(chuàng)建的對象,，它在Azure AD中復制,，不與任何物理服務器相關(guān)聯(lián)（它是虛擬的）。它由遵循命名格式“krbtgt_######”的禁用用戶帳戶對象和關(guān)聯(lián)的計算機帳戶“AzureADKerberos”組成,。

　　Azure AD 使用此對象為域生成部分 TGT,。這樣，用戶帳戶擁有 Azure AD Kerberos 服務器 TGT 加密密鑰,。這是在身份驗證流程的第二步中用于加密部分票據(jù)的 Kerberos 服務器密鑰,。

　　但問題只解決了一半，我們域名的 krbtgt 密鑰不需要發(fā)布到云端,，而是使用這個新的 krbtgt_###### 帳戶的密鑰,。因此，Azure 現(xiàn)在可以發(fā)行票據(jù),，但是服務票據(jù)和授權(quán)呢,？

　　服務票據(jù)和授權(quán)繼續(xù)由本地 AD 域控制器控制。Azure AD 沒有將特權(quán)屬性證書 （PAC） 包含到票據(jù)中所需的所有信息,，這就是為什么它只簽發(fā)部分票據(jù)的原因,。

　　流量如何繼續(xù)？一旦我們獲得了部分票據(jù),，就必須將它（針對本地 AD）換成包含所有所需授權(quán)信息的完整票據(jù),，最后，使用它來請求不同的服務票據(jù)以訪問本地資源,。至此,，我們獲得了 Kerberos SSO 功能，并完成了無密碼體驗,。

　　至此,，只剩下一個問題，這個 Kerberos Server 對象到底是什么,？為什么我們的本地 AD 信任它的密鑰,？只需查看與對象相關(guān)的設備帳戶的屬性,，就很容易獲得答案：

　　計算機屬性

　　我們談論的是只讀域控制器 （RODC）。Microsoft 重用 RODC 的概念來實現(xiàn) Kerberos 的“云”版本,，允許 Azure AD 提供 SSO 功能,。

　　還記得只讀域控制器嗎？

　　在繼續(xù)之前,，需要回顧一些關(guān)于 RODC 的基本概念。如果想了解更多信息,，請點此了解,。

　　簡而言之，RODC 是一種域控制器,，它承載 Active Directory 數(shù)據(jù)庫的只讀分區(qū),。除帳戶密碼外，它保存可寫域控制器保存的所有 AD 對象和屬性,。但是,，無法對存儲在 RODC 上的數(shù)據(jù)庫進行更改。它主要被設計用于部署在遠程或分支機構(gòu)環(huán)境中,，這些環(huán)境通常具有相對較少的用戶,、較差的物理安全性或到中心站點的網(wǎng)絡帶寬較差。

　　我想回顧的主要概念是憑據(jù)緩存,，它將非常有用,。正如我之前提到的，默認情況下,，帳戶密碼不會保存到RODC中（出于安全目的）,，因此分支站點中的身份驗證過程略有不同：

　　1.用戶向其站點的 RODC 發(fā)送 一個TGT 請求；

　　2.RODC 服務器檢查用戶憑據(jù)是否已緩存：

　　2.1如果沒有,，RODC 將請求轉(zhuǎn)發(fā)到可寫 DC,；

　　2.3如果憑據(jù)已緩存，則身份驗證由 RODC 解析,；

　　3.可寫 DC 對用戶進行身份驗證,，簽署 TGT，并將響應發(fā)送回 RODC,；

　　4.RODC 將檢查用戶是否允許緩存其憑據(jù)：

　　4.1如果用戶包含在 Allowed RODC Password Replication中,，則他們的憑據(jù)存儲在服務器中，并且 RODC 的 msDS-RevealedList 屬性填充有用戶名,。后續(xù)的身份驗證請求將由 RODC 管理,；

　　4.2如果用戶包含在Denied RODC Password Replication中，則不會存儲他們的憑據(jù),，后續(xù)的身份驗證請求將轉(zhuǎn)發(fā)到可寫 DC,。

　　5.RODC 將 TGT 轉(zhuǎn)發(fā)給用戶,，用戶可以使用它來請求服務票據(jù)。

　　因此,，當可寫DC不可訪問且RODC無法將請求轉(zhuǎn)發(fā)給它時,，緩存對于確保用戶和計算機可以向RODC進行身份驗證非常有用。然而,，這可能是一把雙刃劍,。沒有緩存憑據(jù)的原因是為了防止當RODC服務器被破壞時整個域處于危險之中。正如上所述,，這些分支站點的安全性級別較低,。因此，憑據(jù)緩存背后的主要思想只是保持在站點上操作所需的最少密碼數(shù)量,。

　　回到無密碼場景,，我們看到了 Microsoft 如何使用 Kerberos 在混合環(huán)境中支持 SSO 到本地資源。但是,，對使用 NTLM 等舊協(xié)議的資源的訪問發(fā)生了什么,？

　　分析這種情況的簡單方法是檢查 Wireshark 捕獲的無密碼身份驗證。我們最感興趣分析的身份驗證部分是圖 2 的第 4 步和第 5 步,，即部分票據(jù)和完整票據(jù)之間的交換,。

　　完整的TGT是通過向KDC （krbtgt服務）發(fā)送一個TGS-REQ（packet n°577）獲得的：

　　TGS-REQ 包括兩個預認證數(shù)據(jù) （PA-DATA）。帶有部分 TGT 和未知 PA-DATA 類型編號 161 的 PA-TGS-REQ,。

　　未知類型是一個明顯的跡象,，表明那里正在發(fā)生某些事情。如果 Wireshark 沒有定義該數(shù)據(jù)類型,，那是因為該數(shù)據(jù)相對較新,。因此，首先要做的是查看 [MS-KILE]：Kerberos 協(xié)議擴展,，并檢查此 PA-DATA 類型,。第一個結(jié)果是一種新型的 TGS-REQ：

　　3.3.5.7.8 密鑰列表請求

　　當密鑰發(fā)布中心 （KDC） 收到包含 aKERB-KEY-LIST-REQ[161] padata 類型的 krbtgt 服務名稱 （sname） 的 TGS-REQ 消息時，KDC應該包括長期秘鑰的客戶端請求的加密類型,？KERB-KEY-LIST-REP?[162]響應消息,，并將其插入到 EncKDCRepPart 結(jié)構(gòu)的加密數(shù)據(jù)中，如 [RFC6806] 中所定義：

　　2.2.11 KERB-KEY-LIST-REQ

　　KERB-KEY-LIST-REQ 結(jié)構(gòu)用于請求 KDC 可以提供給客戶端的密鑰類型列表,，以支持舊協(xié)議中的單點登錄功能,。它的結(jié)構(gòu)是使用 ASN.1 符號定義的。語法如下：

　　KERB-KEY-LIST-REQ ::= SEQUENCE OF Int32 — encryption type —

　　KERB-KEY-LIST-REQ 的結(jié)構(gòu)用于支持舊協(xié)議的 SSO 功能,。只需檢查請求的加密類型以及響應,。捕獲的內(nèi)容如下：

　　PA-DATA 的內(nèi)容是編碼值 3003020117，代表加密類型 23 或 RC4-HMAC,。這代表我們正在請求用戶的 NT 哈希,！

　　確認后,，我開始查看響應（packet n°583）：

　　在 TGS-REP 的加密部分（用會話密鑰解密）中，我們可以找到 PA-DATA 類型 162,，即 KERB-KEY-LIST-REP：

　　回到MS-KILE,，我檢查了結(jié)構(gòu)的編碼以解碼數(shù)據(jù)并獲取密鑰：

　　2.2.12 KERB-KEY-LIST-REP

　　KERB-KEY-LIST-REP 結(jié)構(gòu)包含 KDC 提供給客戶端的密鑰類型列表，以支持舊協(xié)議中的單點登錄功能,。它的結(jié)構(gòu)是使用 ASN.1 符號定義的,。語法如下：

　　?KERB-KEY-LIST-REP ::= SEQUENCE OF EncryptionKey

　　編碼后的 PA-DATA 被解碼為：

　　用戶現(xiàn)在可以使用其 NT-Hash 與 NTLM 進行身份驗證。

　　密鑰列表攻擊

　　現(xiàn)在,，我們發(fā)現(xiàn)了 Windows 使用舊協(xié)議實現(xiàn) SSO 的方式,。在檢查之后，反應是立竿見影的,，我們還發(fā)現(xiàn)了一種新的潛在方法來轉(zhuǎn)儲要求較低的憑據(jù)！

　　這種新技術(shù)背后的想法很簡單,。如果我們能夠用新的 PA-DATA 重現(xiàn)之前的 TGS-REQ,，我們將擁有用戶所有長期秘鑰的列表。

　　因此,，第一次嘗試是將 TGS-REQ 復制到 krbtgt 服務,，并使用普通用戶添加 KERB-KEY-LIST-REQ 結(jié)構(gòu)。這意味著包含的 TGT 是由 KDC 頒發(fā)給該普通用戶的,，無需知道 krbtgt 憑據(jù)即可輕松獲取,。響應是正常的 TGS-REP，沒有新數(shù)據(jù)（不包括 KERB-KEY-LIST-REP）,。第二次嘗試是管理員用戶的新 TGS-REQ,。同樣的過程，同樣的結(jié)果,，答案中沒有關(guān)鍵字,。這個想法并不是那么簡單。

　　如果該過程適用于 RODC,，讓我們嘗試將由此服務器簽名的部分 TGT 包含到 TGS-REQ 中,。復制由 RODC 簽名并頒發(fā)給特定用戶的部分 TGT，將其包含到 TGS-REQ 中,，解密響應并獲取密鑰,，可以對我們想要的任何用戶重復。

　　經(jīng)過幾次嘗試,，漏洞開始顯現(xiàn)：KDC_ERR_TGT_REVOKED（TGT 已被撤銷）,。為什么？這些用戶包含在拒絕 RODC 密碼復制組中,，因此,，此新 Kerberos 功能受到限制,。默認情況下，拒絕管理員等用戶復制其密碼,。

　　不過,，我們可以攻擊物理 RODC 服務器和虛擬服務器（Azure AD Kerberos 服務器對象包含在我們的攻擊面中！）,。同樣重要的是,，目標用戶不需要緩存在 RODC 中！這是以前針對這類域控制器的攻擊所需要的,。

　　總而言之：

　　我們必須知道RODC （-rodcKey）的krbtgt憑據(jù),，因為我們需要創(chuàng)建帶有一些特殊條件的部分票據(jù)和TGS-REQ。我們有幾種獲取憑據(jù)的方法,，例如,，如果我們獲得RODC的本地管理員權(quán)限，就可以用Mimikatz轉(zhuǎn)儲SAM數(shù)據(jù)庫,。如果我們討論的是虛擬RODC,，可以針對Azure AD連接服務器；

　　我們必須有RODC的krbtgt帳戶的ID （-rodcNo）,；

　　我們必須針對在拒絕組中未明確詳細說明的用戶,；

　　有了這些要求，我打開了一個PR,，其中包含一個新的示例腳本（keylistattack.py）和secretsdump.py中的一個新選項（-use-keylist）,，以演示這種攻擊。

　　基本上,，攻擊有兩個主要部分：用戶列表和票據(jù)請求：

　　首先,，我們需要知道我們的目標是什么，可以通過參數(shù)（LIST 選項）定義目標用戶名（-t 標志）或定義具有目標用戶名列表（-tf 標志）的文件,，或者我們可以進行枚舉（例如,，SAMR 用戶枚舉） ）。對于最后一個選項,，我們需要一個低憑據(jù)用戶,，我們有兩個選項。默認選項,，過濾包含在拒絕組中的域用戶,，以及完整的一個（-full 標志）。

　　一旦我們知道要攻擊誰,，我們就會請求票據(jù),、處理響應并獲取密鑰！

　　keylistattack.py 使用沒有過濾的 SAMR 用戶枚舉（-full 標志）

　　keylistattack.py 使用 SAMR 用戶枚舉和過濾（默認攻擊）

　　keylistattack.py 定義目標用戶名（-t 標志）

　　使用 Kerberos 密鑰列表攻擊選項 （-use-keylist） 的 secretsdump.py

　　如何檢測,？

　　提出了新的攻擊,，我們?nèi)绾螜z測它,？由于攻擊實施了有效的密鑰列表請求，該請求可能出現(xiàn)在啟用了無密碼的環(huán)境的正常操作中,，因此選項并不多：

　　1.審計枚舉操作：

　　SAMR 枚舉：事件 4661——請求對象句柄（對象類型：SAM_DOMAIN,、SAM_ALIAS、SAM_GROUP）,；

　　LDAP 枚舉,；

　　2.審核 Kerberos 服務票據(jù)操作：

　　成功請求：事件 4769——請求了 Kerberos 服務票據(jù)（票據(jù)選項：0x10000 ——可代理）；

　　TGT 撤銷：事件 4769——請求了 Kerberos 服務票據(jù)（失敗代碼：0x14 – KDC_ERR_TGT_REVOKED）

　　如何緩解這種攻擊,？

　　物理 RODC：

　　1.不要將“經(jīng)過身份驗證的用戶”或“域用戶”添加到“允許的 RODC 密碼復制組”中,。如果需要，應以與可寫 DC（第 0 層）類似的級別保護這些 RODC,；

　　2.將所有特權(quán)帳戶和組添加到“拒絕 RODC 密碼復制組”,；

　　3.不要將常規(guī)用戶帳戶設置為 RODC 管理員，這些類型的帳戶通常不如知名帳戶安全,，并且它們的泄露可能導致本地帳戶（包括 RODC 的 krbtgt 帳戶）的憑據(jù)轉(zhuǎn)儲,。

　　虛擬 RODC（Azure AD Kerberos 服務器/無密碼方案）：

　　1.請確保只將具有無密碼能力的用戶添加到“允許的RODC密碼復制組”；

　　2.Azure AD Connect服務器包含關(guān)鍵的身份數(shù)據(jù),，應該被視為第 0 層；

　　總結(jié)

　　1.物理和虛擬 RODC 都可能受到攻擊,；

　　2.由于需要復制權(quán)限,，虛擬 RODC 中的攻擊面更加廣泛；

　　3.要攻擊的帳戶不需要緩存在 RODC 上,；

　　4.不需要管理員憑據(jù),，如果你有用戶列表，甚至不需要憑據(jù),；

　　5.該攻擊要求至少有一臺DC服務器使用Windows 2016/2019的更新版本（分別為kb4534307和kb4534321補?。?/p>