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

微軟賬戶服務(wù)

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

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

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

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

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

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

如果我們?cè)诤笠环N方法中添加一個(gè)斷點(diǎn)，那登錄到Office中的MSA帳戶會(huì)導(dǎo)致命中：

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

對(duì)我來(lái)說(shuō)，這確實(shí)是一個(gè)象征！如果我們打開像Fiddler這樣的代理，我們會(huì)看到它與Office訪問(wèn)web服務(wù)時(shí)使用的身份驗(yàn)證令牌格式相匹配：

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

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

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

如果我們稱之為：

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

令牌緩存

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

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

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

我們?cè)俅紊钊胨阉鱠ll，但這次我們將重點(diǎn)關(guān)注Windows.Security.Authentication.Web.Core.dll。

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

AddWebTokenResponseToCache方法如下：

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

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

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

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

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

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

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

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

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

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