如何使用Windows Library檔案進行持久化
前言
想象一下，假設在你不知道的情況下，攻擊者在你的計算機上放置了一個惡意檔案。每當你訪問桌面上某個資料夾時（例如Documents資料夾），都會執行一次該檔案。這樣的場景，通過利用一種鮮為人知的持久化技術就可以實現，這一過程需要用到Windows庫（Library）檔案。
在Windows系統中，引入了庫檔案，允許使用者在單個檢視中檢視多個目錄的內容。庫可以包含儲存在本地計算機或遠端位置的檔案或資料夾。
對這些檔案進行濫用以實現持久化的技術，首先由WikiLeaks Vault 7公開，這種技術與Junction Folder濫用有許多相似之處。由於這兩種技術都難以檢測，所以它們為攻擊者提供了一個不錯的選擇，同時也為安全研究人員製造了一大挑戰。
本文將主要分析如何使用庫檔案來實現持久化，以及在搜尋過程中需要查詢的內容。
關於庫檔案
預設情況下，Windows庫檔案位於%APPDATA%\Microsoft\Windows\Libraries目錄下，副檔名為library-ms。這些檔案是基於XML的，並遵循了公開可用的模式。
作為示例，我們查看了用於Documents資料夾的文件庫檔案（Documents.library-ms）。在該檔案中，最值得關注的部分是SimpleLocation元素的URL。這一元素指定了基於檔案系統或基於協議處理程式的搜尋聯結器（Search Connectors）的位置。
在我們的示例中，庫使用全域性唯一識別符號（GUID）指向了URL元素中兩個不同的已知資料夾。通過搜尋GUID，我們發現了兩個文件目錄：
{FDD39AD0-238F-46AF-ADB4-6C85480369C7} %USERPROFILE%\Documents
{ED4824AF-DCE4-45A8-81E2-FC7965083634} %PUBLIC%\Documents
在使用這兩個位置時，開啟這個庫將會允許使用者在單個檢視中檢視兩個不同目錄的內容。下面的螢幕截圖中展示了每個資料夾中的內容：
然而，在檢視庫時，所有專案都會顯示在同一個資料夾中：
建立惡意庫檔案
那麼，我們如何濫用此功能來獲得永續性呢？
最簡單的方法是新增另一個URL元素，來載入惡意COM物件。當訪問或顯示資料夾時，它將導致我們的COM物件執行。
在下面的示例中，我們建立了一個引用Payload beacon.dll的COM物件。
然後，另一個searchConnector被新增到庫中，其中一個URL元素引用了我們建立的CLSID。
最後，該庫已經被儲存到桌面，因此它看起來像一個合法的資料夾“Documents”。如果使用者開啟該資料夾，將會顯示Documents資料夾中的內容。但是在後臺，COM物件也會被執行，從PID為5392的rundll32.exe啟動我們的信標Payload（Beacon）。
有趣的是，rundll32沒有顯示父程序。這是由於，在執行COM物件後，退出了父程序dllhost.exe（COM Surrogate程序）。在Sysmon中，我們將看到類似於以下示例的事件，其父程序為dllhost.exe，子程序為rundll32.exe。
檢視Process Monitor，我們可以看到dllhost.exe在查詢我們建立的CLSID，然後載入beacon.dll，再然後執行rundll32.exe。
雖然這些資料點可用於檢測，但很可能會出現合法活動的誤報情況。我們可以通過關聯資料點，來得到具有更高準確度的結果。
實現持久化
顯然，為了實現永續性，我們需要在系統啟動時執行library-ms檔案。那麼，應該如何實現這一目標呢？
除了通常的持久化技術之外，有一種更隱蔽的方法，是使用Windows資源管理器。它將在檢視包含該檔案的目錄時，自動執行該檔案。因此，使用者無需實際單擊這個檔案，只需要檢視目錄就足夠了。舉例來說，我們可以將庫檔案放在桌面上，在啟動時，資源管理器將會對它進行渲染，導致COM物件執行。
從檢測角度來看，啟動執行和使用者單擊執行之間的區別就在於，啟動執行時父程序是explorer.exe，因為它是導致庫檔案呈現出來的資源管理器。
尋找library-ms檔案
我們可以通過查詢具有library-ms副檔名的任意檔案，來使用Shell/">PowerShell搜尋惡意庫檔案，然後過濾URL標記以獲取CLSID，同時檢索相關的登錄檔項以進行分析。
此方案僅僅是基於對URL元素的濫用，如果想要進一步發現異常，可能需要尋找其他元素。
我們提供了一個指令碼，用於對%USERPROFILE%資料夾中建立的任何library-ms檔案執行上述條件檢查，我們可以使用該檔案檢查登錄檔中是否存在與此技術相關的異常項。
指令碼的下載地址為： ofollow" rel="nofollow,noindex" target="_blank">https://gist.github.com/countercept/6890be67e09ba3daed38fa7aa6298fdf 。
尋找library-ms檔案建立也很有用，這可能會是一個高準確度的指標，因為這些擴充套件很少會被建立。類似於Sysmon這樣的工具可以讓我們輕鬆監視這些事件，只需要將以下內容新增到帶有FileCreate標記的Sysmon配置檔案中即可。
建立library-ms檔案時，我們將看到如下所示的檔案建立事件：
結論
在Windows中，有很多“傳統”的持久化技術，例如登錄檔、服務、計劃任務等，許多安全研究者都會關注這些技術。正如本文所描述的， library-ms檔案對防守方提出了一個獨特的挑戰，由於它們可以隱蔽地通過COM引用執行程式碼，所以檢測和分析過程就更加具有挑戰性。
系統防守方應該專注於建立和修改.library-ms檔案以及COM條目。除了來自explorer.exe或dllhost.exe的這些可疑程序執行之外，它們還可以提供惡意活動的進一步證據。
參考連結： https://www.countercept.com/blog/abusing-windows-library-files-for-persistence/
*本文作者：eridanus96，轉載請註明來自FreeBuf.COM