如何通過Emond在macOS上實現持久化訪問

新聞 02-18

在這篇文章中，我們會介紹如何通過emond在macOS上實現持久化訪問。根據蘋果公司的說法，事件監視進程（emond）會「接受來自各種服務的事件，通過一個簡單的規則引擎運行並採取相應操作（action），這些操作可以是執行命令，發送電子郵件或者短消息，推送通知等」。聽起來挺有意思，實際上Emond自OS X 10.7就已經有了，所以本文所討論的細節適用於最新版本的macOS（10.13.2）。

具體步驟

emond是一個普通的守護進程，每次系統啟動時都會由launchd執行，其對於launchd的配置文件和其他系統守護進程在同一個地方：/System/Library/LaunchDaemons/com.apple.emond.plist，該配置文件決定了何時執行emond，並帶有LaunchDaemons經常使用的任何期望的選項。 emond.plist配置文件位於/etc/emond.d/目錄中。該文件定義了規則路徑，UID/GID過濾，錯誤日誌和事件日誌路徑以及一些其他選項。

圖1：emond.plist中的內容

規則文件被存儲在/etc/emond.d/rules/目錄中，且應該為plist格式。在該目錄下已經有一個示例規則文件了（SampleRules.plist），該示例定義了名稱，類型和事件觸發後的操作。事件有幾種類型（startup, periodic, auth.success, auth.failure等），在這次的演示中我們只使用startup。一旦被emond載入，startup事件類型就會觸發規則；periodic事件類型只有在定義了「startTime」之後才會觸發；同樣的，auth.success事件類型只會在用戶成功驗證後觸發；auth.failure會在驗證失敗事件上觸發，還有其他的一些事件類型就不一一列舉。action定義了事件發生後emond將要做什麼，需要注意的是，我們可以在規則中定義多個action。只有少數action可以被用於惡意目的（如運行命令和發送電子郵件），你可能已經猜到了，運行命令可以允許你執行任意系統命令，對於發送電子郵件，目的不言自明。對於本演示，我們將重點介紹執行命令。

現在我們可以演示如何利用事件監視進程來建立持久化訪問。 emond的機制與其他任何LaunchDaemon相似。 Launchd負責在啟動過程中執行所有LaunchDaemons和LaunchAgent。由於emond是在該過程中啟動的，所以當使用執行命令時，應該注意一下你正在執行什麼命令，以及在哪一個過程應該執行哪個命令。這一點非常重要，因為事件發生然後觸發action（執行命令）的時候電腦很可能沒聯網，所以任何需要網路訪問的命令都沒法用。接下來，我們會展示如何創建規則文件。

要創建規則文件，我們可以使用已經存在的SampleRule.plist文件，並根據需要對其進行修改。

圖二：samplerules.plist

該示例包含我們的規則文件所需的一些值。具體而言，我們可以刪除「allowPartialCriterionMatch」這個key並根據需要更改名稱。所定義的action需要針對執行命令的action類型進行修改。一個完整的例子如下所示：

圖三：實現持久化訪問示例

需要注意的是，第一個操作是睡眠10秒，這樣是為了等待網路連接。至於是10秒還是20秒，因人而異，請自行斟酌。第二個就不用介紹了，建立會話。不過這樣持久性機制還有一個奇怪之處：launchd會在啟動過程中執行emond，但是在QueueDirectories路徑中存在一個文件之前，服務將保持不活動狀態。這在LaunchDaemon配置文件/System/Library/LaunchDaemons/com.apple.emond.plist中指定。放在QueueDirectories路徑中的文件不需要遵循特定的命名方案，也可以為空。

圖四：com.apple.emond.plist中的QueueDirectories

把plist文件放進rules目錄後，emond錯誤日誌會顯示服務已啟動，emond也不會提示說找不到任何規則。

圖五：錯誤日誌

一旦服務開始，如果你已經定義了一個startup事件類型，那麼事件將會立即發生並觸發任何action。現在，我們應該可以看到Empire會話建立了。

圖六：請求

圖七:會話建立

Emond並不是一個OSX事件監視的新機制，但它可以作為一種攻擊新用例。回想起來，在我撰寫本文時，所閱讀過的任何macOS威脅報告中都沒有提及過這樣的方法。但也有可能已經在野使用，或者其本身人畜無害。

如何檢測

這種持久化訪問的方法需要對文件系統進行一些改變，幸運的是，macOS提供了fsevents API來捕獲文件系統事件。實質上fsevents會記錄每個卷中的所有事件。最初，事件存儲在內存中，一旦內存緩衝區已滿或即將卸載卷，事件會被寫入磁碟。FSEvent日誌文件以gzip壓縮格式存儲，並遵循十六進位命名方案。所有日誌文件都存儲在一個隱藏的目錄中：/fseventsd/。訪問此目錄需要root許可權。 fsevents的一個注意事項是時間戳不包含在日誌文件中。通過訪問API，我們可以使用Python或Objective-C篩選所有接收到的事件，並在rules目錄或QueueDirectory中發生文件創建/修改事件時進行警報。

點擊這裡查看開源fsevents項目

你可以注意到fswatch可以在事件觸發時提供時間戳。此外，你可以將其輸出到任何其他命令行，以便進一步處理。你也可以指定多個目錄進行監控。下圖顯示了一旦我們在rules目錄中放置了一個plist文件，fswatch將以一個JSON字元串顯示事件詳細信息。

圖九：事件發生時的輸出

當然這只是一個最基本的例子，可能不適用於部署在大型MacOS環境中。對於後者，更適用的選擇是osquery。Osquery提供文件完整性監視，它使用fsevents api將文件系統更改記錄到特定目錄的文件。更多信息可以點擊這裡。安裝osquery之後，你需要提供一個配置文件來監視文件系統事件。下圖是一個簡單的示例來監視rules目錄中的所有文件系統事件。所有事件將以60秒為間隔進行查詢。

為了簡潔起見，我們從命令行啟動osquery守護進程，並使用-config_path標誌指定配置文件。一旦我們創建了plist文件，並將其放置在rules目錄中，60秒後，在osquery日誌文件中就應該有一個條目。結果默認記錄到/var/log/osquery/osqueryd.results.log。輸出將包括路徑，主機標識符，時間戳，文件事件的類型以及其他。