在這篇文章中，我將介紹我在逆轉(zhuǎn)Office的身份驗證機(jī)制時發(fā)現(xiàn)的兩個問題，并提供一些不需要刪除內(nèi)存的POC工具來幫助恢復(fù)存儲的令牌。

微軟賬戶服務(wù)

我必須承認(rèn)，當(dāng)我第一次開始研究這個問題時，刪除我正在運行的Word進(jìn)程的內(nèi)存并沒有發(fā)現(xiàn)文檔簽名eyJ0eX。這是當(dāng)前工具用來識別活動令牌的主要方法，我在Windows登錄時使用Microsoft 365帳戶。

事實證明，Microsoft Account (MSA)的身份驗證令牌處理方式與通常的Azure AD SSO帳戶不同。

讓我們從查看經(jīng)過MSA驗證的Office會話開始，啟動Microsoft Office并查看加載的DLL。其中最突出的是MicrosoftAccountWAMExtension.dll。將這個DLL加載到Ghidra中，我們可以開始尋找為MSA帳戶生成身份驗證令牌的原因。

如果我們在這個DLL中尋找RPC調(diào)用，就可以看到一堆被定向到名為wlidsvc的服務(wù)：

不幸的是，微軟并沒有為RPC調(diào)用此服務(wù)提供IDL(或者根本沒有提供很多信息)，所以我們將不得不做一些逆向工程來解決這個問題。

讓我們將WinDBG附加到wlidsc并監(jiān)視正在進(jìn)行的RPC調(diào)用。在任何Office進(jìn)程中進(jìn)行身份驗證之后，我們看到第一個調(diào)用是RPC方法WLIDCCreateContext以創(chuàng)建上下文，然后是WLIDCAcquireTokensWithNGC，最后是一系列其他調(diào)用，我們將暫時忽略這些調(diào)用。

如果我們在后一種方法中添加一個斷點，那登錄到Office中的MSA帳戶會導(dǎo)致命中：

步進(jìn)式（Stepping ）直到我們點擊ret并檢查填充的參數(shù)，在參數(shù)12的內(nèi)存區(qū)域中會顯示一些有趣的東西。

對我來說，這確實是一個象征！如果我們打開像Fiddler這樣的代理，我們會看到它與Office訪問web服務(wù)時使用的身份驗證令牌格式相匹配：

那么，我們?nèi)绾螐奈覀冏约旱墓ぞ咧姓{(diào)用它呢？讓我們使用James Forshaw的NtObjectManager生成一個可以使用的存根。

生成的RPC存根根據(jù)Windows版本的不同而不同，這是毫無價值的，例如，在Windows 10中，我們發(fā)現(xiàn)字段計數(shù)在輸入結(jié)構(gòu)上發(fā)生了變化，因此，如果你收到可怕的(0x800706F7) - The stub received bad data. 錯誤，請多家留意。

使用RPC客戶端存根創(chuàng)建一個快速的C#應(yīng)用程序，我們將重播我們之前觀察到的入站RPC調(diào)用，并添加參數(shù)，這將給我們提供如下內(nèi)容：

如果我們稱之為：

由于這是MSA身份驗證請求，我們將不得不使用Substrate等服務(wù)來訪問Microsoft 365服務(wù)。旋轉(zhuǎn)一個代理并在Office中導(dǎo)航是確定調(diào)用什么以及這些web服務(wù)采用什么參數(shù)的最佳方式。但你可以看到，passport令牌返回后，我們可以很好地進(jìn)行身份驗證和交互：

令牌緩存

現(xiàn)在我們已經(jīng)了解了如何恢復(fù)MSA，那么Azure AD呢？通過Lee Christensen的帖子知道，我們可以很容易地按需請求新令牌，但是我們在Office進(jìn)程中看到的緩存令牌被轉(zhuǎn)儲了，它們是如何在啟動時加載的呢？

讓我們提供一個新的主機(jī)并將我們的用戶帳戶與AzureAD相關(guān)聯(lián)，然后登錄到Office，再嘗試找出令牌存儲的位置。

為了確保我們在正確的軌道上，讓我們從內(nèi)存中轉(zhuǎn)儲一些字符串，并確保eyJ0eX簽名存在。

我們再次深入搜索dll，但這次我們將重點關(guān)注Windows.Security.Authentication.Web.Core.dll。

這是一個WinRT庫，因此我們需要深入Ghidra了解正在發(fā)生的事情。

AddWebTokenResponseToCache方法如下：

如果我們進(jìn)一步研究，會發(fā)現(xiàn)此方法實際上負(fù)責(zé)將憑據(jù)緩存到序列化文件，這些文件可以在%LOCALAPPDATA%\Microsoft\TokenBroker\Cache中找到。

好的，讓我們看看這些TBRES文件：

如果我們使用ProcMon，我們會看到這些文件確實在進(jìn)程啟動時被Office訪問：

可以看到，這就是我們的身份驗證信息存儲的地方！查看JSON會發(fā)現(xiàn)一個IsProtected字段。在WinDBG中，我們將附加到Office，在CryptUnprotectData上添加斷點并重新啟動。果然，我們發(fā)現(xiàn)base64解密數(shù)據(jù)的內(nèi)容被解密了。

JSON文件中我們特別感興趣的字段是ResponseBytes，我添加了一個帶有快速工具的repo，該工具可以解密這些文件，可以在這里找到。

在使用ProtectedData.Unprotect解密此數(shù)據(jù)后，我們看到了明文JWT。果然，解密它們會得到我們之前從內(nèi)存中看到的相同信息：

來自不同提供者和應(yīng)用程序的其他令牌也存儲在這些文件中，包括MSA令牌，這也是毫無價值的。

現(xiàn)在我們知道了，Windows和Office用于Live和Azure的認(rèn)證和緩存會話的幾種不同方法。

POC可以在https://github.com/xpn/WAMBam上找到。

本文翻譯自：https://blog.xpnsec.com/wam-bam/如若轉(zhuǎn)載，請注明原文地址