.png.c9b8f3e9eda461da3c0e9ca5ff8c6888.png)
Microsoft系統中心配置管理器(SCCM)。 SCCM是一款微軟產品體系架構下的桌面端，服務器，移動端管理產品。主要是負責桌面標準化，網絡批量安裝部署軟件和操作系統，殺毒策略，資產收集，移動端管理等等。是一款作為IT管理員，企業基礎架構管理的必備工具。在這篇文章中，我們將介紹SCCM 如何使用其HTTP API 來初始化客戶端。我們還將了解如何從SCCM 檢索網絡訪問帳戶，以及我們如何解密這些憑據而無需使用DPAPI 或管理員帳戶。
實驗室設置對於我們的實驗室設置，我們將使用默認的SCCM 部署。我發現最簡單的方法是通過自動化實驗室，它支持通過ConfigurationManager 角色進行安裝：
我們將在這篇文章中使用的版本是Configuration Manager 2103，我們將把我們的主站點命名為P01。本實驗的服務器將稱為SCCM01，我們將配置為使用HTTP 進行通信。
一旦SCCM服務器的設置完成，我們將把一切都保留為標準，並添加一個Network Access Account供以後使用：
完成後，我們就可以繼續探索了！
客戶端註冊讓我們首先看看客戶機嘗試向SCCM註冊時生成的請求。為了做到這一點，我們使用@_Mayyhem awesome SharpSCCM工具：
當SharpSCCM 調用實際的.NET 客戶端庫時，我們會收到一個清晰的請求，我們可以使用WireShark 來識別它。客戶端向SCCM 服務器註冊的初始步驟如下：
這個HTTP 請求被發送到SCCM 服務器，由兩部分組成，一個是XML 編碼的標頭，另一個是在多部分/混合HTTP 請求中發送的XML 編碼的正文。有趣的是，該協議還使用了CCM_POST 的HTTP 方法。
標頭採用UTF-16 編碼，如下所示：
請求正文是zlib壓縮和Unicode編碼：
為了簡單起見，我刪除了一些較長的十六進製字符串，但我們在這裡看到的是三個十六進制blob被發送到服務器，以及一些關於我們的客戶端的初始信息。
讓我們轉儲Signing blob：
如果我們看這個，我們實際上會看到這是一個DER 編碼的證書：
生成此證書時，添加了兩個擴展密鑰使用OID：
這些將證書標記為短信簽名證書(自簽名)。
因此，我們看到客戶端證書被傳遞給SCCM服務器以供稍後使用，但是SignatureValue字段呢？讓我們啟動dnSpy並深入研究System.ConfigurationManagement.Messaging.dll程序集，該程序集位於安裝了客戶端的主機上的C:\Windows\CCM 中。
經過一番搜尋，我們在Interop.Crypt32.HashAndSignData中找到了答案：
這表明，使用帶有PKCSv15填充的RSA- sha256正在使用與證書關聯的RSA 私鑰對XML 請求正文進行簽名。
這裡需要注意的一件奇怪的事情是，一旦生成簽名，字節在ASCII十六進制編碼並添加到請求¯\_(ツ)_/¯之前會被反轉。
當服務器響應這個客戶端註冊請求時，我們再次看到有一個XML 標頭和正文，其中正文數據被zlib 壓縮。可以看到我們被分配給了ClientID，它是在我們的客戶端與服務器通信期間使用的UUID：
在這個階段值得注意的是，這個請求可以發送到未經身份驗證的SCCM URL http://SCCM01/ccm_system/request。這足以向SCCM添加一個客戶端條目，但是我們將處於“未批准”狀態。這種狀態在以後會變得很重要：
政策要求客戶端註冊後，客戶端執行的下一個階段是檢索策略列表。此調用還使用
不幸的是，這是事情變得有點複雜的地方。我們首先需要關注的是PublicKey blob。這實際上只是客戶端之前為證書生成的RSA 公鑰，但是這次它被編碼為PUBLICKEYBLOB。
接下來是ClientIDSignature。這是我們之前看到的用於簽署ClientID 的RSA-SHA256 簽名，前面帶有GUID:然後轉換為Unicode。例如：
最後是PayloadSignature，它是隨後壓縮的主體的簽名。
這個請求的主體是zlib 壓縮和Unicode 編碼的，帶有我們客戶端的信息：
對該請求的響應是XML主體中可用的策略列表：
雖然這裡有很多有趣的東西，但我們現在要關注的領域將是網絡訪問帳戶的共享方式。
秘密政策如果你遍歷我們檢索到的策略列表，你一定會遇到標記為“秘密”的策略。其中一個策略是NAAConfig，它包含了網絡訪問帳戶：
你可能已經看到@gentilkiwi 在2021 年發布的Mimikatz 更新中引用了這些帳戶，這表明通常這些憑據是在SCCM 客戶端上使用DPAPI 加密的：
但是，如果我們嘗試使用RequestAssignments 請求返回的URL 直接下載此策略，我們會看到出現一個錯誤。
這樣做的原因是需要對秘密策略的請求進行身份驗證。但是由於這是SCCM，所以還需要進行另一種類型的身份驗證。
經過一番搜尋之後，我發現了對SCCM 服務器上名為ccmgencert.dll 的DLL 中使用的身份驗證類型的引用：
既然我們知道了一些使用的簽名方法，這些標頭實際上可以很容易被創建。看看被添加到SCCM平台的客戶端，我們看到它們是這樣的：
ClientToken只是我們的cliententid和當前DateTime的一個連接。 ClientTokenSignature是使用上面相同的RSA-SHA256算法的簽名。
讓將這些標頭添加到我們的請求中，看看會得到什麼：
這一次，我們得到了不同的回應。我的意思是我們出現錯誤，但我們也沒有得到任何不好的數據。
事實證明，對於我們的客戶端實際請求秘密策略，他們需要在服務器上處於Approved 狀態。
默認情況下，SCCM 安裝有以下內容：
那麼，計算機是如何自動自我認可的呢?還有另一個URL被/ccm_system_windowsauth/request的客戶端使用。如果之前的XML ClientRegistrationRequest被發送到這個路徑，並完成NTLMSSP驗證計算機帳戶，則客戶端設置為Approved 狀態：
現在，當對此URL 進行身份驗證時，我們似乎可以使用任何隨機域用戶帳戶。然而，問題是它似乎不足以迫使客戶進入批准狀態。相反，我們需要使用計算機帳戶（儘管它不需要與我們嘗試註冊的客戶端相對應），所以addcomputer.py 在這裡非常有用。
通過將此身份驗證步驟添加到我們的註冊請求並強制我們的客戶端進入Approved 狀態，下次我們請求NAAConfig 策略時，我們會得到如下所示的內容：
好吧，回到dnSpy，我們去嘗試弄清楚。答案在Interop.DecryptMessageFromCertificateFile 方法中找到，該方法顯示了CryptDecryptMessage API 調用的使用。
參數顯示此加密策略是使用3DES CBC 的PKCS7 編碼blob，其密鑰源自我們之前在證書中提供的RSA 公鑰。
解密後，我們終於看到了一些實際的憑證，如下所示：
網絡訪問帳戶混淆起初，獲取這些賬戶似乎需要更多的加密貨幣。但是MimiKatz 已經向我們展示了這些憑據最終可以在客戶端上訪問，因此我們知道我們的客戶端必須能夠在使用DPAPI 保護它們之前以某種方式解密這些憑據……那麼密鑰是什麼？在尋找這個加密是如何完成的之後，我在客戶端上找到了一個名為PolicyAgent.dll 的DLL。
最重要的是調試字符串：
UnobfuscateString 聽起來很有希望，當然聽起來比DecryptString 更好。我沒有深入研究這個反彙編的所有部分，而是創建了一個快速調試工具來調用這個函數。
當運行在與SCCM實驗室網絡無關的主機上時，並且連接到調試器以逐步解決通過以這種方式調用方法而發生的不可避免的訪問衝突時，就會解密用戶名和密碼：
這意味著所使用的加密與描述的完全一樣，它是被混淆的！我們擁有在密文中解密這些憑證所需的所有信息，而且我們可以完全離線完成！
通過重新創建unobfuscation方法的步驟，我們可以創建如下所示的解密代碼。
有了計算機帳戶，我們就可以在SCCM 中添加虛假客戶端，下載加密的網絡訪問帳戶憑據，並對其進行解密，而無需處理提升權限或任何DPAPI 解密。