因此，這個(gè)想法很簡(jiǎn)單，你可以登錄到你的混合 Azure AD 加入的 Windows 10 設(shè)備并自動(dòng)訪問(wèn)云和本地資源。FIDO2 安全密鑰成為進(jìn)入云和本地資源的途徑。

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

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

　　Azure 中的無(wú)密碼體驗(yàn)

　　如上所述，Microsoft 通過(guò) Azure Active Directory 將無(wú)密碼體驗(yàn)擴(kuò)展到本地資源。既然我們談?wù)摰氖潜镜刭Y源的 SSO 功能，那就要先了解一下 Kerberos。

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

　　假設(shè)我想訪問(wèn)在服務(wù)器 A 中運(yùn)行的服務(wù) 1。身份驗(yàn)證流程如下：

　　Kerberos 身份驗(yàn)證

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

　　無(wú)密碼身份驗(yàn)證

　　可以看到部分 TGT 交換完整的TGT，以及在云中復(fù)制的 Kerberos 服務(wù)器密鑰。這是怎么回事？讓我們開(kāi)始深入研究這個(gè)問(wèn)題。到目前為止，只有位于域控制器上的密鑰發(fā)布中心 （KDC） 服務(wù)有權(quán)發(fā)布 TGT。但是，這種新的無(wú)密碼體驗(yàn)的引入使事情發(fā)生了一些變化：正如我們?cè)谥暗牧鞒讨锌吹降哪菢樱珹zure AD 現(xiàn)在可以為一個(gè)或多個(gè)域發(fā)出 Kerberos TGT！這讓我想到了另一個(gè)問(wèn)題，krbtgt 帳戶呢？

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

　　Kerberos 服務(wù)器對(duì)象屬性

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

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

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

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

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

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

　　計(jì)算機(jī)屬性

　　我們談?wù)摰氖侵蛔x域控制器 （RODC）。Microsoft 重用 RODC 的概念來(lái)實(shí)現(xiàn) Kerberos 的“云”版本，允許 Azure AD 提供 SSO 功能。

　　還記得只讀域控制器嗎？

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

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

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

　　1.用戶向其站點(diǎn)的 RODC 發(fā)送 一個(gè)TGT 請(qǐng)求；

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

　　2.1如果沒(méi)有，RODC 將請(qǐng)求轉(zhuǎn)發(fā)到可寫(xiě) DC；

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

　　3.可寫(xiě) DC 對(duì)用戶進(jìn)行身份驗(yàn)證，簽署 TGT，并將響應(yīng)發(fā)送回 RODC；

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

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

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

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

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

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

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

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

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

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

　　3.3.5.7.8 密鑰列表請(qǐng)求

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

　　2.2.11 KERB-KEY-LIST-REQ

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

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

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

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

　　確認(rèn)后，我開(kāi)始查看響應(yīng)（packet n°583）：

　　在 TGS-REP 的加密部分（用會(huì)話密鑰解密）中，我們可以找到 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é)議中的單點(diǎn)登錄功能。它的結(jié)構(gòu)是使用 ASN.1 符號(hào)定義的。語(yǔ)法如下：

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

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

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

　　密鑰列表攻擊

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

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

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

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

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

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

　　總而言之：

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

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

　　我們必須針對(duì)在拒絕組中未明確詳細(xì)說(shuō)明的用戶；

　　有了這些要求，我打開(kāi)了一個(gè)PR，其中包含一個(gè)新的示例腳本（keylistattack.py）和secretsdump.py中的一個(gè)新選項(xiàng)（-use-keylist），以演示這種攻擊。

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

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

　　一旦我們知道要攻擊誰(shuí)，我們就會(huì)請(qǐng)求票據(jù)、處理響應(yīng)并獲取密鑰！

　　keylistattack.py 使用沒(méi)有過(guò)濾的 SAMR 用戶枚舉（-full 標(biāo)志）

　　keylistattack.py 使用 SAMR 用戶枚舉和過(guò)濾（默認(rèn)攻擊）

　　keylistattack.py 定義目標(biāo)用戶名（-t 標(biāo)志）

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

　　如何檢測(cè)？

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

　　1.審計(jì)枚舉操作：

　　SAMR 枚舉：事件 4661——請(qǐng)求對(duì)象句柄（對(duì)象類型：SAM_DOMAIN、SAM_ALIAS、SAM_GROUP）；

　　LDAP 枚舉；

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

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

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

　　如何緩解這種攻擊？

　　物理 RODC：

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

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

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

　　虛擬 RODC（Azure AD Kerberos 服務(wù)器/無(wú)密碼方案）：

　　1.請(qǐng)確保只將具有無(wú)密碼能力的用戶添加到“允許的RODC密碼復(fù)制組”；

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

　　總結(jié)

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

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

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

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

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