歡迎來到 黑吧安全網 聚焦網絡安全前沿資訊,精華內容,交流技術心得!

一文讀懂進程重鏡像技術(附檢測方案)

來源:本站整理 作者:佚名 時間:2019-11-07 TAG: 我要投稿

大約三個月前,一種新的攻擊技術出現在安全社區,名為「進程重鏡像」。 這項技術是由 McAfee 安全團隊在一篇標題為“進程重鏡像和終端安全解決方案繞過”的博文中發布的,在這種攻擊技術發布的幾天后,我的一個同事也是朋友—— Dwight ——拿出了概念驗證代碼(PoC),演示了這種技術,可以在他的 GitHub 上找到。 雖然這項技術還沒有映射到 MITRE ATT&CK 中,但我相信它屬于防御躲避戰術。
盡管我寫這篇博客文章的目的是展示用于檢測這種攻擊的方法,但是它假設你已經讀過 McAfee 安全團隊發布的博客文章并且看過 Dwight 的概念驗證代碼。 這次攻擊的簡要概要如下:
進程重鏡像是一種攻擊技術,它利用了 Windows 操作系統在確定進程鏡像 FILE 對象位置過程中的不一致性。 這意味著攻擊者可以刪除磁盤上的二進制文件,并通過將其初始執行完整文件路徑替換為受信任的二進制文件來隱藏該文件的物理位置。 這反過來允許攻擊者繞過 Windows 操作系統進程屬性驗證,將自己隱藏在他們選擇的進程鏡像的上下文中。
這種攻擊包括三個階段:
· 將二進制文件寫入到磁盤ーー這里假設攻擊者可以將二進制文件寫入到磁盤。
· 未檢測到的二進制加載。這將是進程創建后加載的原始鏡像。
· 惡意二進制文件被“重鏡像”到一個攻擊者希望以某種方式出現的已知的好的二進制文件。 這是可以實現的,因為重命名鏡像時,虛擬地址描述符(VAD)不更新。 因此,當應用程序查詢時,這會返回錯誤的進程鏡像文件信息。
這使對手有機會防御性地規避分析人員和事件響應者的檢測工作。 組織往往沒有收集到“正確”的數據。 通常,數據是非結構化的、無必要的,并且缺乏得出結論所需的實質性細節。 如果沒有高質量的數據,組織可能會對在其環境中運行的技術視而不見。 此外,由于過于依賴 EDR 產品的基本配置(例如,Windows Defender 等) ,你將檢測的細節提供給第三方,而第三方可能使用或不使用正確的函數調用來檢測這種惡意行為(例如 GetMappedFileName 可以正確檢測這種重鏡像攻擊)。 基于這些因素,這種攻擊允許對手成功逃避偵測。 要了解更多關于這種攻擊的內容和信息,請查看關于這個主題的原始博客文章中的 “技術探秘” 部分。
注意: GetMappedFileName 是應用程序用于查詢進程信息的 API。 它檢查所請求的地址是否在指定進程地址空間中的內存映射文件內。 如果地址在內存映射文件內,它將返回內存映射文件的名稱。 這個 API 需要 PROCESS_QUERY_INFORMATION 和 PROCESS_VM_READ 訪問權限。 任何時候當某個句柄具有了訪問權限 PROCESS_QUERY_INFORMATION,它也就被授予了 PROCESS_QUERY_LIMITED_INFORMATION 權限。 這些訪問權限的位掩碼是 0x1010。 這可能看起來很熟悉,因為這是 Mimikatz 所期望的訪問權限之一。 Matt Graeber 提醒過我,在嘗試檢測基于授權訪問的可疑訪問 LSASS 時,這是許多誤報的來源。
透明化
這次攻擊發布后,我花了一個星期六的時間創建了一個威脅追蹤假設,我仔細的研究了數據行為,并找到了它們之間的關系。 在查看 Dwight 的 POC 時,我注意到代碼中的 Win32 API 調用,從這些調用中,我確信我可以將這些 API 調用與特定的事件關聯起來。 因為像許多防御者一樣,我對 EDR 產品及其日志記錄能力做了假設。
在沒有已知 API 到事件 ID 映射的情況下,我開始自己映射這些調用。 我一開始映射的是 Sysmon。 這需要逆向Sysmon 驅動程序將 API 調用映射到事件注冊機制的事件 ID。 這里要感謝 Matt Graeber,感謝他在這個任務中幫助了我,并且花時間教我逆向的過程。 創建這個映射是我實現檢測策略的一個關鍵部分,沒有它就不可能實現最終的檢測策略。
進程重鏡像檢測
檢測方法
用于這一檢測的方法如下:
· 閱讀進程重鏡像攻擊的技術報告。
· 查看Dwight 的 POC 代碼。
· 獲得關于攻擊如何執行的知識后,在數據和攻擊行為之間建立關系。
· 執行攻擊。
· 應用前面獲得的研究知識并結合數據關系進行魯棒性檢測。
檢測步驟
當我瀏覽這個博客的 “Technical Deep Dive”部分時,我突然想到:

https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/in-ntdll-i-trust-process-reimaging-and-endpoint-security-solution-bypass/
上面的圖片中顯示了幾個 API 調用,它們的使用極大的激發了我的興趣。
· LoadLibrary
· CreateProcess
根據我在 Sysmon 驅動程序內部的逆向研究,這兩個 API 調用都是通過事件注冊機制漏斗式進行的。 然后,Sysmon 驅動程序使用必要的輸入 / 輸出接口控制(IOCTL)代碼調用這種機制來查詢數據。 然后將查詢的數據拉回到Sysmon 二進制文件中,后者將生成相關的事件 ID。
對于上述兩個 API 調用的相關過程如下圖所示:

 Sysmon 事件 ID 1的映射: 進程創建

Sysmon 事件 ID 7的映射: 鏡像加載
根據這項研究和 McAffee 文章中的“技術揭秘”部分,我確切地知道執行此攻擊時將生成什么數據。 Sysmon 對LoadLibrary 的每個調用應該有一個 ID是 7的事件,對 CreateProcess 的調用同樣應該有一個 ID 是1的事件; 但是,如何將數據轉換為可操作的數據呢? 特別是威脅追蹤人員可以很容易地使用和操縱以滿足他們需要的數據? 為此,我們將重點放在數據標準化和數據質量上。

[1] [2]  下一頁

【聲明】:黑吧安全網(http://www.gkrbnd.live)登載此文出于傳遞更多信息之目的,并不代表本站贊同其觀點和對其真實性負責,僅適于網絡安全技術愛好者學習研究使用,學習中請遵循國家相關法律法規。如有問題請聯系我們,聯系郵箱[email protected],我們會在最短的時間內進行處理。
  • 最新更新
    • 相關閱讀
      • 本類熱門
        • 最近下載
        福彩原副主任