Azure 活動目錄（Azure AD）Kerberos 是kerberos身份驗證協議的雲版本，是專門爲在Azure雲平 臺上工作而構建的。
在雲計算之前的時代，Kerberos（以及之前的NTLM）是企業環境中大多數到所有身份驗證的核心協議。然而，隨着不斷地向雲化遷移，尤其是隨着SaaS應用程序、雲工作負荷和傳統的基礎設施的混合使用 ，改變了這一點。如今，SaaS應用程序的常見做法是向基於雲的身份提供商進行身份驗證，比如 Azure AD。而本地工作負載仍然對具有Kerberos等傳統協議的AD進行身份驗證。
因此，像Azure虛擬桌面和Azure文件等雲基礎設施的認證雖然本身不屬於本地AD域，但依然依賴相關技術。
新的Azure AD Kerberos 認證協議設計旨在克服這種依賴性，將雲工作負荷引流到Azure AD雲原生認證基礎設施，因此在雲Azure資源和本地Windows協議以及應用（例如SMB、RDP、RPC等等）之間引入一個光滑的集成。 通過這種方式，組織可以整合所有的雲資源的身份認證，無論是SaaS應用還是Azure Ad中的基礎設施的工作負荷。
然而，Azure AD Kerberos仍然與它的前輩本地Kerberos有很多相似之處。在這篇白皮書中，我們分享已經進行的研究，來判斷現有的針對傳統kerberos協議的攻擊技術是否適用於新的修改後的Azure AD Kerberos。研究結論是存在兩種新的攻擊技術。第一種是調整後的臭名昭著的PTT攻擊，我們稱之爲反彈票據。第二種是調整後的銀票攻擊，我們稱之爲銀碘化攻擊。這篇白皮書詳細介紹了兩種攻擊細節和緩解措施。
本着負責的態度，我們在披露前已經與微軟MSRC團隊溝通了這兩種技術，非常感謝其花費時間精力來確認和審批允許我們公開。
Kerberos 回顧
Kerberos是一種現代的值得推薦的企業認證協議，它包括三個獨立的保護過程（就像三頭狗 Cerberus），它們共同提供一個安全通道來傳輸身份驗證消息。該協議基於票據交換，每個過程都爲確認身份驗證不同階段提供了保證。密鑰分發中心（KDC）管理身份驗證過程，監督給認證客戶票據的分發、用戶口令的驗證和服務票據的分發。一般情況下，KDC基於對稱密鑰密碼體制完成其加解密過程，但也可以選擇使用非對稱密體制 。
下面是Kerberos的三個過程實現：
獲取TGT（AS過程）
這是Kerberos認證的第一階段，客戶端需要提供一個有效的口令來接受一個可以驗證其完整性的票據（TGT）。這個TGT (Ticket granting ticket) 是由由認證服務加密的，並且是唯一可以驗證一張給定的TGT票據完整性的驗證者。在TGT票據還附加了一個Session Key，Session Key是TGS服務加密過程中使用的。該Session Key經用戶口令加密，因此用戶可以解密消息獲得Session Key，進行下一步TGS請求的驗證。
獲得ST（TGS過程）
在Kerberos身份驗證的第二階段中，用戶向KDC請求TGS服務。這類型的票據將用於特定的服務。在活動目錄中，已註冊的服務稱爲服務主體名稱（SPN），其約定慣例格式爲：服務類/主機。要驗證一個ST，需要一個共享的密鑰——服務器的私鑰。在Windows機器中，此密鑰被保存在註冊表中的Security Hive中。在其他平臺和第三方應用程序中，微軟提供導出一對（SPN和服務器的私鑰）稱之爲Keytab。TGS 票據用服務器的私鑰加密幷包含一個保存着關於客戶端的授權數據這特權屬性證書（PAC）。這個信息無法被編輯或修改，因爲只有服務器知道其自己的私鑰。
服務申請（AP過程）
身份認證的最後一個階段是Application Request（AP）階段。客戶端通過預定協議（例如HTTP、SMB、RPC、RDP等）直接發送AP-REQ到服務器，這裏麪包含ST，在服務側，ST經過KDC分發的服務端私鑰解密。通過這種方式，服務端可以驗證客戶端票據來自於正確的KDC。解密成功後，服務器通過審覈PAC來確定客戶端是否被授權訪問服務並做出應答。
Kerberos 認證過程
Azure AD Kerberos 簡介
Kerbeos通過兩個服務完成其身份認證過程：
- Authentication Service（AS）：負責驗證用戶口令；
- Ticket Granting Service（TGS）：負責向不同的域資源授予身份驗證票據，並向服務器提供關於用戶的詳細信息。
Azure AD Kerberos 一樣如此，但也有幾點主要的修改：
黑客帝國-墨菲斯：選擇你的命運？ 紅色藥丸（雲） 藍色藥丸（本地）
客戶端到KDC的通信加密
在Azure AD Kerberos中，KDC（包括AS和TGS）轉到了雲上，因此，客戶端無法通過明文信道與KDC交互。因此，Azure AD 利用 KDC Proxy Kerberos Extension（MS-KKDCP）在一個TLS隧道中傳輸Kerberos Message。
KDC Proxy Cloud Domain Mapping
當你註冊到了Azure AD， Windows 劃定一個域（windows.net）到KERBEROS.MICROSOFTONLINE.COM 中，基於這種劃分，當用戶嘗試訪問資源時，就需要windows.net域中的Kerberos認證。KDC Proxy協議就是Azure-Based KDC用來提供在KERBEROS.MICROSOFTONLINE.COM中的ST的協議。
KerbTopLevelNames字段用於在雲資源到雲KDC之間進行映射
解耦身份認證與TGS服務
微軟拆分了AS服務和TGS服務，所以現下，雲TGT可以與在登錄到Azure AD時獲得的主刷新令牌（the Primary Refresh Token，PRT）一起檢索。當到 login.microsoonline.com//oauth2/token 的post請求與一個頭部字段字段tgt=true一起發送時，Azure AD 會響應一個TGT。這個響應包含一個加密的二進制塊，其中有PRT和krbtgt. TGS過程由客戶端發起一個KDC Procy定義的TGS請求（login.microsoonline.com//Kerberos）以及TGT，就像傳統的Kerberos請求一樣。
使用Kerberos Proxy的TGS 請求
最後，Azure Files等兼容資源接受Kerberos 的AP-REQ(Application request)發送已取得的ST。
看起來，Azure AD Kerberos在安全性上投入了大量的思考和努力。第一個安全增強是AS和TGS端點的分離，通過一個更強大的安全機制來保護krbtgt密鑰，避免金票攻擊。第二個安全增強是使用KDC代理和基於TLS的加密通信層在web上傳輸認證信息。然而，Azure AD Kerberos 相比於本地版本是否對常見的漏洞和攻擊技術做了更好的防護呢？讓我們進一步探索。
攻擊Azure AD Kerberos協議
我們介紹兩種我們發現的新的攻擊技術，這兩種技術利用了這些修改中的弱點，我們稱之爲反彈票據攻擊和碘化銀攻擊。
反彈票據攻擊
PTT攻擊回顧
Kerberos的一個主要的安全問題是其在lsass進程中緩存的票據（ in-memory ticket caching），這個機制在Azure AD Kerberos中並沒有得到修復。一旦對手獲取了Windows機器的控制權，他們可以從內存中得到TGT，然後使用這個TGT來請求任意他們希望獲得的Kerberos ST。這種攻擊被稱爲PTT。
PTT攻擊
反彈票據
我們稱Azure AD Kerberos中的PTT攻擊爲Bounce the Ticket攻擊，他們確實非常相似。首先我們從內存中提取TGT用來訪問雲上TGS而非本地TGS。我們獲得的票據可以用來訪問雲上的依賴於Azure AD Kerberos的資源。
在混合環境中，本地AD和Azure AD Kerberos domain 均被使用着，一個攻擊者可以利用反彈票據攻擊來從本地環境跨到Azure AD管理的雲環境中。
Rubeus 攻擊實踐
儘管該攻擊非常像本地PTT攻擊，但依然略有不同，需要改變現有的攻擊工具來使得攻擊更加容易。我們選擇Rubeus，一個由GhostPack編寫用來進行Kerberos交互和濫用的工具。下面的改動使得Rubeus更適應Azure AD Kerberos：
- 將Realm修改爲KERBEROS.MICROSOFTONLINE.COM來適應雲環境；
- 加密的PAC username field 修改爲包含完整的UPN（跟在original domain name後）
- 修改登錄服務器爲login.microsoftonline.com
...
}
kvi.LogonServer = new Ndr._RPC_UNICODE_STRING("login.microsoftonline.com");
if (!String.IsNullOrEmpty(displayName))
{
...
LogonServer 修改
幸運的事，Rubeus 已經支持KDC Proxy擴展了，因爲其本身也不是一個新的擴展，而且經常用來服務應用通過WEB查詢Kerberos這一過程。
嘗試使用Rubeus進行攻擊：
- 使用mimikatz或者其他的攻擊工具導出內存中的雲TGT票據
mimikatz# Privilege::debug
mimikatz# sekurlsa::ticket /export
mimikatz 使用
- 使用導出的票據向雲KDC請求ST，並將ST注入lsass進程
Rubeus.exe asktgs /ticket:ticket.kirbi /service:cifs/AzFilesShare.file.core.windows.net
/proxyurl:https:/ /login.microsoonline.com/tenantID/kerberos /enctype:AES256 /ptt
- 直接訪問目標服務
- 成功
反彈票據（Bounce-the-Ticket BTT）攻擊
碘化銀攻擊
我們繼續介紹一種攻擊技術：本地白銀票據攻擊允許攻擊者利用一個竊取的服務器Key來僞造票據，該票據可以以任意權限訪問服務器。
銀票回顧
在經典的本地銀票攻擊中，攻擊者首先獲取一個服務器的Kerberos Key（機器賬戶的Hash）這個Key可以通過很多技術方式獲取，例如Kerberoasting. 一旦攻擊者獲得了這個Key，就可以僞造ST。因爲在Kerberos中ST是由Server Key加密的，所以攻擊者可以利用該Key僞造該服務器的ST。舉例，一個攻擊者可以生成一個攻擊者壓根沒有改username的認證信息的身份或一個提升了攻擊者控制的賬號的初始權限的身份所對應的票據，這就導致了攻擊者可以以管理員身份訪問目標服務。
銀票攻擊
碘化銀攻擊技術
碘化銀攻擊技術與本地銀票攻擊類似，但也有一些不同。這種技術適應雲化的主要挑戰是在Azure AD Kerberos中，服務器的密鑰是由Azure使用加密強隨機數生成器生成的。這意味我們不能依賴於過去的基於弱密鑰的攻擊，例如Kerberoasting攻擊。我們必須通過其他方式獲取Server Key。獲取服務器密鑰的特定方式因受到攻擊的應用程序而有所不同。對於這個演示，我們分析了Azure文件中的一個安全缺陷。
爲了使得本地銀票攻擊技術適應雲環境，我們修改了Rubeus 的銀票生成方法，且將所需領域到修改到匹配KERBEROS.MICROSOFTONLINE.COM，還有修改了LogonServer，還有就是使用獲得的Key僞造我們自己的碘化銀票據。
利用碘化銀攻擊技術攻擊Azure Files
Azure Files介紹及其如何使用Azure AD Kerberos
Azure Files 是一個基於雲的serverless文件共享服務，相當於雲化的SMB文件共享。該共享可以以不同的方式使用。在我們的上下文中，最感興趣的是從Azure虛擬桌面訪問Azure Files。因爲這種訪問可以使用SMB與Kerberos認證協議，通過Azure AD Kerberos來完成。
對Azure Files的碘化銀權限提升攻擊
Azure文件共享被配置在Azure Portal中，在Azure AD Kerberos 的預覽版中，用戶被要求通過powershell命令配置一個存儲賬戶Key，該Key扮演者着Kerberos 存儲私鑰的角色。
Azure AD Kerberos 預覽版文檔
在GA版本中，不再需要該命令，而是在配置Azure Files時自動完成配置。
該密鑰也可以稍後使用以下powershell命令提取：
$kerbKey1 = Get-AzStorageAccountKey -ResourceGroupName $resourceGroupName -Name
$storageAccountName -ListKerbKey | Where-Object { $_.KeyName -like "kerb1" }
這兩條命令同時適用於預覽版和GA版本。
顯然，攻擊者並不一定需要擁有對該資源的權限來運行Get-azstorageAccountKey命令，只需要成爲以下組之一的成員即可：
- Owner
- Contributor
- Avere Contributor (Microsoft.Storage/storageAccounts/)
- DevTest Labs User
- Disk Snapshot Contributor
- Log Analytics Contributor
- Logic App Contributor
- Reader and Data Access
- Storage Account Contributor (Microsoft.Storage/storageAccounts/)
- Storage Account Key Operator Service
- Virtual Machine Contributor
這些組也不一定與擁有訪問資源本身中的數據的權限有關，比如DevTest Labs用戶。
IAM截圖
所以爲了獲得權限提升，我們需要做的是：
- 獲取以上組中一個弱認證的用戶；
- 使用該用戶權限通過powershell命令在Azure Files中提取Kerberos Server Key；
- 使用Rubeus工具結合我們獲取的Server Ticket僞造到Azure Files的ST；
- 控制Azure Files中的目標信息。
最後，我們將修改了Rubeus 的銀票生成方法，且將所需領域到修改到匹配KERBEROS.MICROSOFTONLINE.COM，還有修改了LogonServer，還有就是使用獲得的Key僞造我們自己的碘化銀票據。
碘化銀攻擊
緩解措施
鑑於當前還沒有補丁來修復導致這些攻擊的問題，我們推薦下列環節措施：
- 檢查並監視對Azure訪問控制（IAM）的任何更改以及共享的訪問控制權限，以驗證僅被授權的用戶具有對Microso.ClassicStorage/storageAccounts/listKeys/action - Kerberos key 提取操作的權限。
- 爲避免反彈票據攻擊，可以減少計算機允許存儲的雲TGTs到最低數量限度（最小化權限），可以通過限制"Allow retrieving the Azure AD Kerberos Ticket Granting Ticket during logon"組策略到使用Azure AD Kerberos安全組.