建站
咨詢
售后
建站咨詢
新聞中心
在這篇文章中，我將介紹我在逆轉(zhuǎn)Office的身份驗證機制時發(fā)現(xiàn)的兩個問題，并提供一些不需要刪除內(nèi)存的POC工具來幫助恢復(fù)存儲的令牌。
專注于為中小企業(yè)提供成都做網(wǎng)站、網(wǎng)站制作服務(wù),電腦端+手機端+微信端的三站合一,更高效的管理,為中小企業(yè)平魯免費做網(wǎng)站提供優(yōu)質(zhì)的服務(wù)。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動了上千企業(yè)的穩(wěn)健成長，幫助中小企業(yè)通過網(wǎng)站建設(shè)實現(xiàn)規(guī)模擴充和轉(zhuǎn)變。
微軟賬戶服務(wù)
我必須承認，當(dāng)我第一次開始研究這個問題時，刪除我正在運行的Word進程的內(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)視正在進行的RPC調(diào)用。在任何Office進程中進行身份驗證之后，我們看到第一個調(diào)用是RPC方法WLIDCCreateContext以創(chuàng)建上下文，然后是WLIDCAcquireTokensWithNGC，最后是一系列其他調(diào)用，我們將暫時忽略這些調(diào)用。
如果我們在后一種方法中添加一個斷點，那登錄到Office中的MSA帳戶會導(dǎo)致命中：
步進式（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令牌返回后，我們可以很好地進行身份驗證和交互：
令牌緩存
現(xiàn)在我們已經(jīng)了解了如何恢復(fù)MSA，那么Azure AD呢？通過Lee Christensen的帖子知道，我們可以很容易地按需請求新令牌，但是我們在Office進程中看到的緩存令牌被轉(zhuǎn)儲了，它們是如何在啟動時加載的呢？
讓我們提供一個新的主機并將我們的用戶帳戶與AzureAD相關(guān)聯(lián)，然后登錄到Office，再嘗試找出令牌存儲的位置。
為了確保我們在正確的軌道上，讓我們從內(nèi)存中轉(zhuǎn)儲一些字符串，并確保eyJ0eX簽名存在。
我們再次深入搜索dll，但這次我們將重點關(guān)注Windows.Security.Authentication.Web.Core.dll。
這是一個WinRT庫，因此我們需要深入Ghidra了解正在發(fā)生的事情。
AddWebTokenResponseToCache方法如下：
如果我們進一步研究，會發(fā)現(xiàn)此方法實際上負責(zé)將憑據(jù)緩存到序列化文件，這些文件可以在%LOCALAPPDATA%\Microsoft\TokenBroker\Cache中找到。
好的，讓我們看看這些TBRES文件：
如果我們使用ProcMon，我們會看到這些文件確實在進程啟動時被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的認證和緩存會話的幾種不同方法。
POC可以在https://github.com/xpn/WAMBam上找到。
本文翻譯自：https://blog.xpnsec.com/wam-bam/如若轉(zhuǎn)載，請注明原文地址
文章標(biāo)題：如何恢復(fù)網(wǎng)絡(luò)令牌，你學(xué)會了嗎？
分享URL：http://m.5511xx.com/article/djhcipd.html
