一、背景
近期，我一直專注於macOS持久化領域，特別選擇了一些較低級別用户可以修改的文件，而這些文件可能會影響用户交互。我發現，終端用户經常進行交互的一個位置是Dock。
通過研究，我發現有一個plist負責控制Apple Dock應用程序的可視化呈現。在這裏沒有太多突破性內容，因為終端用户經常會通過圖形化界面（GUI）來修改這一plist。在查看了plist中的值之後，我想探究是否可以更改這些值，從而使用運行自定義代碼的惡意應用程序來替換合法的應用程序。
這項研究中的一個突破是DockPersist.js，我將其納入到PersistentJXA項目之中。在我的實現中，將使用惡意應用程序替換Safari或Chrome。我主要研究Safari和Chrome，因為二者很可能會出現在用户的Dock中。但是，這一理論實際上適用於任何應用程序。終端用户在單擊Safari或Chrome圖標後，就會運行我們的惡意應用程序。這種持久化方式類似於Windows上的快捷方式（.LNK）文件持久化，因為在macOS中，Dock圖標通常會作為實際應用程序的快捷方式。
這種持久化方法需要將我們的惡意應用程序上傳到目標計算機。我傾向於在Mythic代理中使用上傳功能，將應用程序保存到目標上。
在修改plist之後，我們就可以立即重新加載Dock。但是，這會導致終端用户的屏幕出現短暫的閃爍。或者，我們也可以等待用户重新啓動後，再讓虛假的應用程序出現在Dock中，因為修改後的plist會在重新啓動後保持不變。
二、攻擊方式
2.1 部署
前面已經説過，這種持久化方式需要將惡意應用程序上傳到目標。在此過程中，有多種方法可以繞過Gatekeeper保護，允許我們將惡意應用程序上傳到目標。這些方法包括：
1、壓縮應用程序包，在Mythic代理（Apfell或Poseidon）中使用上傳命令，然後在目標計算機中解壓縮。
2、壓縮應用程序包，在某個位置託管，使用curl下載到目標，然後在目標計算機中解壓縮。
3、壓縮應用程序包，進行Base64編碼，在進行Base64解碼後保存到目標上，然後在目標計算機中解壓縮。
作為概念驗證（PoC），我僅僅是在“自動操作”（Automator）中創建了一個應用程序。PoC應用程序會打開Safari瀏覽器，這樣就避免了終端用户沒有感知的情況。然後，它將運行我們的Apfell Payload。
在PoC應用程序中，JXA打開Safari並執行Apfell Payload：
為了不讓終端用户發覺，我將默認的“自動操作”圖標替換為Safari瀏覽器。當然，如果使用Xcode，還可以創建更復雜的應用程序。
帶有Safari瀏覽器圖標的PoC應用程序，我們將其命名為Safari：
接下來，我壓縮應用程序包，並將其上傳到目標。在解壓縮到/Users/Shared/之後，我們可以集中精力，在滿足前提條件的情況下調用持久化方法。
注意：由於plist的二進制格式，自動實現要求將虛假的應用程序命名為“Google Chrome”或“Safari”，並且位於/Users/Shared/中。我們可以修改Safari64和Chrome64變量，以更改此位置。
2.2 調用持久化
將腳本導入Mythic中的Apfell代理：
調用DockPersist函數。該函數接受三個參數：應用程序名稱（Safari或Google Chrome）、Bundle ID、是否立即重新加載Dock的選項。
注意：Bundle ID位於Info.plist中，可以使用以下命令來獲取：
/usr/libexec/PlistBuddy -c 'Print CFBundleIdentifier' ~/FakeApp/Safari.app/Contents/Info.plist
在Apfell代理中調用DockPersist函數，指定Safari、Bundle ID和是否重新加載Dock的選項：
三、檢測方法
Crescendo是一個能在主機上迅速捕獲事件的絕佳工具。Crescendo可以作為macOS的實時事件查看器，它的一項出色功能就是利用了Apple的終端安全框架（ESF）。ESF可以監視系統事件中是否存在潛在的惡意活動，實際上它是系統擴展框架中的一個API。與Windows相比較，可以將其理解為macOS上一個功能有限的事件追蹤（ETW）。
通過Crescendo，我們可以輕鬆地查看由持久化執行創建的文件和進程事件。
對於不太瞭解ESF的讀者，大家需要了解下面的一些事件會同步到Crescendo：
ES_EVENT_TYPE_AUTH_EXEC = process::exec
ES_EVENT_TYPE_NOTIFY_EXIT = process::exit
ES_EVENT_TYPE_NOTIFY_CREATE = file::create
ES_EVENT_TYPE_NOTIFY_KEXTLOAD = process:kext::load
ES_EVENT_TYPE_NOTIFY_MOUNT = file::mount
ES_EVENT_TYPE_NOTIFY_UNLINK = file::unlink
ES_EVENT_TYPE_NOTIFY_RENAME = file::rename
ES_EVENT_TYPE_NOTIFY_UIPC_CONNECT = network::ipcconnect
ES_EVENT_TYPE_NOTIFY_FORK = process::fork
儘管目前Crescendo不會捕獲ES_EVENT_TYPE_NOTIFY_MMAP、ES_EVENT_TYPE_NOTIFY_WRITE和ES_EVENT_TYPE_NOTIFY_EXEC，但它已經捕獲到了這種持久化方式對應的足夠多的事件。如果要應對其他惡意活動，我強烈建議使用Xorrior的Appmon。
下面重點介紹了持久化方法的執行，根據不同攻擊者使用的具體方法，實際的惡意應用程序所對應的事件可能會有所不同。
首先，plutil將Dock plist轉換為XML。XML格式更加易於操作。
Plutil將當前com.apple.dock.plist轉換為XML格式：
隨後，記錄了temp9876文件創建和進程創建。
DockPersist.js在/private/tmp/下創建一個隨機命名的文件。該腳本會修改plist的XML版本，並將其以隨機文件名保存。在這裏，temp0wsn4p包含XML格式的惡意plist，因此我們用正確加載Dock所需的二進制格式版本覆蓋了此文件。
Plutil將修改後的plist轉換回二進制格式：
接下來，DockPersist.js在~/Library/Preferences/com.apple.dock.plist中刪除現有的plist。
刪除當前的com.apple.dock.plist：
ESF捕獲到這一動作，並將新的惡意plist以二進制格式保存到~/Library/Preferences/com.apple.dock.plist。
保存修改後的com.apple.dock.plist：
最後，由於我們在函數調用中制定了重新加載Dock，因此將調用killall。
重新加載Dock：
要建立檢測方式，這些事件就是我們的起點。這裏的關鍵是檢測到了plutil和killall。此外，文件創建、刪除和修改事件也同樣可以用於檢測。在攻擊者進行持久化之前，還可以針對將惡意應用程序上傳到目標計算機的這個動作來進行檢測。
3.1 正常執行
大家可能會有一個疑問，現在我們瞭解了ESF是如何捕獲已知惡意行為的，那麼ESF會如何區分正常執行呢？
在正常執行的情況下，cfprefsd（Core Foundation Preferences Daemon）將會在com.apple.dock.plist上觸發file::rename事件（文件覆蓋）。當用户通過GUI手動對Dock進行更改時，也會觸發這些事件。
com.apple.dock.plist的正常修改：
3.2 嘗試逃避檢測
攻擊者可以在另一台主機上修改plist，然後將修改後的plist上傳到目標計算機的對應位置，這樣就能減少潛在指標的數量。但是，這樣做仍然會觸發file::rename事件，而這一事件不會使用在正常執行情況下的cfprefsd進程。由此看來，識別非cfprefsd進程對plist的修改動作，可能是檢測惡意行為的一個較好的判斷標準。
藉助Apfell代理覆蓋替換com.apple.dock.plist：
3.3 可視化指標
如果執行PoC應用程序，將會導致Dock中出現兩個Safari實例。
惡意Safari應用程序與合法Safari應用程序：
第一個Safari是惡意的應用程序，位於plist的“persistent-apps”部分中，而第二個才是真實的Safari，它位於plist的“recent-apps”部分中。
四、其他指標
在瀏覽ESF日誌之後，我注意到了其中包含了寫入SQLite數據庫的一些內容。如果攻擊者利用了osascript，則需要注意的一點是，osascript在~/Library/Caches/com.apple.osascript/Cache.db的位置有一個緩存數據庫。
注：上述緩存數據庫的創建僅適用於攻擊者使用osascript二進制的情況下。除此之外，我還深入研究瞭如果使用OSAKit替代osascript的情況。為了進行測試，我使用Sublime Text Plugin加載了JXA dylib。與osascript緩存數據庫的位置不同，在這種情況下的C2條目被記錄在~/Library/Caches/com.sublimetext.3/Cache.db之中。
使用SQLite對應的數據庫瀏覽器查看該數據庫後，我注意到其中的cfurl_cache_response表中包含Mythic服務器的IP地址，以及Mythic中用於命令和控制（C2）通信的GET請求的簡短日誌。這個緩存內容為應急排查提供了寶貴的來源。
通過數據庫瀏覽器，在SQLite數據庫中查看到C2通信的證據：
使用sqlite3命令行工具也可以查看到這些條目：
五、總結
在本文中，我們展示了macOS中類似於Windows .LNK文件的持久化攻擊方法。更重要的是，我希望本文中分析的持久化指標可以幫助正在開發檢測方式的研究人員。如果大家發現針對這一持久化方式還有其他檢測指標，歡迎與我探討。
六、參考資源
[1] https://posts.specterops.io/detection-engineering-using-apples-endpoint-security-framework-affdbcb18b02
[2] https://medium.com/red-teaming-with-a-blue-team-mentaility/taking-the-macos-endpoint-security-framework-for-a-quick-spin-802a462dba06
[3] https://attack.mitre.org/techniques/T1547/009/
[4] https://developer.apple.com/documentation/endpointsecurity?language=objc
[5] https://github.com/SuprHackerSteve/Crescendo
[6] https://bitbucket.org/xorrior/appmon/src/master/
[7] https://sqlitebrowser.org/
[8] https://eclecticlight.co/2017/07/06/sticky-preferences-why-trashing-or-editing-them-may-not-change-anything/
參考及來源：https://posts.specterops.io/are-you-docking-kidding-me-9aa79c24bdc1
【來源：嘶吼RoarTalk】
聲明：轉載此文是出於傳遞更多信息之目的。若有來源標註錯誤或侵犯了您的合法權益，請作者持權屬證明與本網聯繫，我們將及時更正、刪除，謝謝。 郵箱地址：[email protected]