Jump to content
  • Entries

    16114
  • Comments

    7952
  • Views

    86385088

Contributors to this blog

  • HireHackking 16114

About this blog

Hacking techniques include penetration testing, network security, reverse cracking, malware analysis, vulnerability exploitation, encryption cracking, social engineering, etc., used to identify and fix security flaws in systems.

在這篇文章中,我將介紹我在逆轉Office的身份驗證機制時發現的兩個問題,並提供一些不需要刪除內存的POC工具來幫助恢復存儲的令牌。

微軟賬戶服務我必須承認,當我第一次開始研究這個問題時,刪除我正在運行的Word進程的內存並沒有發現文檔簽名eyJ0eX。這是當前工具用來識別活動令牌的主要方法,我在Windows登錄時使用Microsoft 365帳戶。

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

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

如果我們在這個DLL中尋找RPC調用,就可以看到一堆被定向到名為wlidsvc的服務:

1.png

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

讓我們將WinDBG附加到wlidsc並監視正在進行的RPC調用。在任何Office進程中進行身份驗證之後,我們看到第一個調用是RPC方法WLIDCCreateContext以創建上下文,然後是WLIDCAcquireTokensWithNGC,最後是一系列其他調用,我們將暫時忽略這些調用。

如果我們在後一種方法中添加一個斷點,那登錄到Office中的MSA帳戶會導致命中:

2.png

步進式(Stepping )直到我們點擊ret並檢查填充的參數,在參數12的內存區域中會顯示一些有趣的東西。

3.png

對我來說,這確實是一個像徵!如果我們打開像Fiddler這樣的代理,我們會看到它與Office訪問web服務時使用的身份驗證令牌格式相匹配:

4.png

那麼,我們如何從我們自己的工具中調用它呢?讓我們使用James Forshaw的NtObjectManager生成一個可以使用的存根。

5.png

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

使用RPC客戶端存根創建一個快速的C#應用程序,我們將重播我們之前觀察到的入站RPC調用,並添加參數,這將給我們提供如下內容:

6.png

如果我們稱之為:

7.png

由於這是MSA身份驗證請求,我們將不得不使用Substrate等服務來訪問Microsoft 365服務。旋轉一個代理並在Office中導航是確定調用什麼以及這些web服務採用什麼參數的最佳方式。但你可以看到,passport令牌返回後,我們可以很好地進行身份驗證和交互:

8.png

令牌緩存現在我們已經了解瞭如何恢復MSA,那麼Azure AD呢?通過Lee Christensen的帖子知道,我們可以很容易地按需請求新令牌,但是我們在Office進程中看到的緩存令牌被轉儲了,它們是如何在啟動時加載的呢?

讓我們提供一個新的主機並將我們的用戶帳戶與AzureAD相關聯,然後登錄到Office,再嘗試找出令牌存儲的位置。

9.png

為了確保我們在正確的軌道上,讓我們從內存中轉儲一些字符串,並確保eyJ0eX簽名存在。

10.png

我們再次深入搜索dll,但這次我們將重點關注Windows.Security.Authentication.Web.Core.dll。

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

AddWebTokenResponseToCache方法如下:

11.png

如果我們進一步研究,會發現此方法實際上負責將憑據緩存到序列化文件,這些文件可以在%LOCALAPPDATA%\Microsoft\TokenBroker\Cache中找到。

12.png

好的,讓我們看看這些TBRES文件:

13.png

如果我們使用ProcMon,我們會看到這些文件確實在進程啟動時被Office訪問:

14.png

可以看到,這就是我們的身份驗證信息存儲的地方!查看JSON會發現一個IsProtected字段。在WinDBG中,我們將附加到Office,在CryptUnprotectData上添加斷點並重新啟動。果然,我們發現base64解密數據的內容被解密了。

15.png

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

在使用ProtectedData.Unprotect解密此數據後,我們看到了明文JWT。果然,解密它們會得到我們之前從內存中看到的相同信息:

16.png

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

現在我們知道了,Windows和Office用於Live和Azure的認證和緩存會話的幾種不同方法。

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