讀書筆記：事件響應和IOC

最近在讀《Incident Response & Computer Forensics（第3版）》1，作者是來自 Mandiant（現FireEye）的兩位資深安全專家—Luttgens, Jason T. 和 Pepe, Matthew。本書出版於2014年，作者在這一版中專註於介紹如何在企業範圍內、以快速而徹底的方式進行從檢測到修復的入侵事件調查。

今天這則讀書筆記來自第5章，主要介紹事件調查過程中如何將線索（Leads）轉化為失陷指標（Indicators of Compromise）。在這部分內容之前，首先會介紹出自第2章的相關概念和定義，事件響應過程以及事件調查生命周期、線索、IOC以及 IOC部署。

基本概念和定義

文中定義了事件響應（IR）過程包括初始響應、事件調查和修復。初始響應通常意味著整個 IR 過程的啟動。一旦 IR 團隊確認事件正在進行並執行了初始的收集和響應步驟，那麼調查和修復工作也開始同步執行。初始響應工作的目標包括組建響應團隊、檢查網路和其他可獲得的數據、確定事件類型以及評估潛在影響。

而事件調查的目標則是確定事實，描述發生了什麼、如何發生的，在一些情況下還需要回答「誰」為此負責。作者開發和提煉了一套由5個步驟組成的事件調查流程（見下圖）。這是一個可迭代的過程，因此又稱為事件響應生命周期。

在整個調查過程中，負責調查的團隊會持續生成作者稱之為「線索」（leads）的列表。線索是可指導行動的項目，它與失竊數據、網路指標、潛在主體的身份標識、導致失陷或安全事件的問題相關。

「Leads are actionable items about stolen data, network indicators, identities of potential subjects, or issues that led to the compromise or security incident.」

作者認為沒有線索的事件調查無異於捕魚探險。因此，收集初始線索對於任何事件調查都是至關重要的步驟。作者注意到許多組織在事件調查中會犯一個常見錯誤，僅關注如何發現惡意軟體。從攻擊者的意圖來說，安裝惡意軟體並非其唯一目標。一旦入侵網路成功並獲得有效的身份憑證，攻擊者將不再需要使用惡意軟體訪問其他系統。另外，作者從實戰經驗出發，包括接手在他們之前所獲不多的事件調查以及他們自己的成功經驗，建議應聚焦在線索上，而且應該有必要投入時間評估新的線索。好的線索通常有3個特徵：

相關的：與事件相關，這點看起來顯而易見。但很多組織通常會陷入的問題在於，會將任何看似可疑的信息都視為當前事件的一部分。而且，由於事件的觸發，組織會以前所未有的方式審視自身的環境，由此會發現大量可疑的活動，而事實上卻是正常的。這會給調查團隊帶來極大工作量甚而阻礙調查工作的開展。

詳細的：線索應具有與潛在調查過程相關的詳情。舉例來說，某個外部團體可能提供了一條線索，表明你的環境中有一台電腦在和外部網站通信，而這個網站被植入了惡意代碼。這樣的信息並不夠詳細，還需要額外了解更多細節，比如事件發生的日期和時間、IP地址等，考慮 「who」、「what」、「when」、「where」、「why」以及「how」，否則就可能是浪費時間。

可行的：線索應包含你能使用的信息，而且你的組織應該具備能跟進這條線索所需的手段。舉例來說，現在有一條線索表明大量數據傳送到與 botnet 相關的一個外部網站。你也有準確的日期、時間以及目標IP，但是企業內部沒有對應的網路流數據或者防火牆日誌，用以識別內部資源正是數據源。因此這條線索是不可行的，因為沒有辦法發現網路中特定電腦的活動。

失陷指標（Indicators of Compromise，IOC）的生成，是以結構化的方式記錄事件的特徵和證物的過程。IOC包含從主機和網路角度的所有內容，而不僅僅是惡意軟體。它可能是工作目錄名、輸出文件名、登錄事件、持久性機制、IP地址、域名甚至是惡意軟體網路協議簽名。

IOC 部署：IOC 被用於有效地描述、交流和查找與事件相關的證物，但如何發揮 IOC 真正的價值在於幫助 IR 團隊以自動化的方式去發現問題。調查的成功取決於是否有能力在整個企業中搜索 IOC、並以自動化的方式報告它們，這就是作者所說的「IOC 部署"。

如何將線索轉化為 IOC

前面介紹了好的線索應具備的3個特徵：相關的、詳細的、可行的。當我們已經掌握了大量的好線索之後，我們還需要將這些線索轉化為可行的指標，即能夠檢測進行中的事件以及將來的攻擊。IR 團隊生成的大多數線索包括惡意操作的可檢測特徵。它們可以用兩類指標來表示。第一類是基於屬性的指標，描述了一組已知的惡意軟體或操作的特性，例如註冊表、MD5 哈希或具有唯一名稱的互斥體。而某些線索不太具體，需要通過一組特徵組合定義惡意或可疑的行為，比如在 /Windows/help 目錄下非預期的可執行文件。這稱之為基於方法的、或基於異常的指標。它們都可以轉化為可用於單次運行或企業範圍實時響應的指標，以幫助確定事件範圍。使用指標的目的在於界定事件範圍：發現一次，全面搜索。

「Discover once, search everywhere」.

IOC 開發生命周期

IOC 的開發是一個迭代過程，旨在生成可靠的、可持續的簽名，從而能夠生成可靠的信息用於搜索和匹配。負責生成 IOC 的團隊成員必須遵循 IOC 開發生命周期流程，如下圖所示。

初始信息輸入可能是來自高精度源（如取證檢查、有質量的惡意軟體分析報告）的最有用結果，也有可能僅包含可疑攻擊的簡單特徵。收集完初始信息後，進入指標創建/編輯（Create/ Edit）階段。該階段工作不僅僅是打開一個TXT 或者 XML 編輯器，將 MD5 哈希值拷貝進去，還需要很好地理解 IOC 語言以及使用處理器的限制和細微差別，比如 snort 平台預處理器針對進入數據流操作所需的時間，任何變數的改變（如報文抵達率、分片報文的數量等）都可能導致其他感測器丟包或者丟失信息。另一個例子則是幾個取證分析套件中使用的索引引擎需要注意特殊字元的處理。

指標生成以後，在進入循環或者直接使用之前需要進行驗證，有兩種驗證方法：與指標相關的數據（Data Relevant to Indicator）、以及環境通用的數據（Data Common to Environment）。

驗證獲得的信息會被反饋並用於指標細化。該循環會一直持續到指標已經充分形成，這樣調查者才能可靠地使用指標。此過程可確保指標生成預期結果。接下來就可以考慮IOC 部署和使用，進入發布階段。

主機IOC

線索可以轉化為基於主機和網路的IOC，也可以是兩者的組合。接下來將以主機IOC為例，介紹指標創建/編輯（Create/ Edit）的方法和思路。

作者認為：一個好的主機IOC 由觀測到的一些特定活動特徵組成, 但通常也適用於該活動的衍生物。這可能較難平衡，特別是線索不夠完整或者質量不佳的時候。

「A good host-based indicator is composed of a number of observables that are specific to a particular activity, yet general enough to apply to a derivative of the activity.」

基於屬性的 IOC

大家如果還有印象，前文介紹過：線索可以用兩類指標來表示，一類是基於屬性的，另一類是基於方法/異常的。作者分別對這兩類指標做了舉例介紹。

第一個例子用到了《Practical Malware Analysis (No Starch Press, 2012)》一書中第3章實驗裡面的二進位文件 Lab03-02. dll。

第一步可以基於該文件的 MD5 hash 值作為 IOC 指標。無疑這項指標具有極高的精度，同時非常單一、受限，因為攻擊者極為容易更改文件內容同時也還保留其功能，如僅僅更改內置的IP地址，這會導致基於 MD5 hash 檢測的指標失效。

接下來從 PE 文件數據結構角度進行拓展和優化，可以在指標中加入兩個判斷條件，即 PE 頭部包含的編譯時間戳以及文件大小。之所以補充後者，主要是考慮到攻擊者有時會在編譯之後對其進行手工修改，這樣儘可能降低誤報。值得注意的是，如果攻擊者增刪二進位文件裡面的數據，文件大小這個條件就無法匹配上。因此，需要進一步優化 IOC。

在分析該二進位文件時，我們能發現其在系統上執行了大量的操作，比如安裝 Windows 服務、或者鏈接互聯網上的站點。從這裡開始，其實是轉換思路了，從尋找文件本身到查找執行文件後的效果。這樣即使系統上不再存在這個二進位文件或者如前兩步所述，文件屬性發生變化時，IOC 裡面仍然包含文件被執行後留下的證物（artifacts），可用於搜索匹配。作為示例，作者補充了兩項條件，二進位文件創建的特定服務以及與該惡意軟體外聯的主機名相關的DNS 緩存信息。更新後的IOC入下圖所示。

針對這個場景的IOC，另一種優化的方法則是描述該二進位文件能做什麼。通常會去檢查輸入表（import table），但同時也需要考慮手工導入函數的不適用情況。在這個樣例中，作者發現有大量的輸入，同時也考慮到了大多數惡意軟體會使用許多其他類軟體通用的函數，這裡獨特的一點是：通常不會在單個二進位文件一起找到這些函數的子集。因此需要構造一個具有多個模糊或鬆散的、可歸因屬性的 IOC。下圖顯示的 IOC 捕獲了所導入函數相對獨特的組合。這種思路的好處在於即使攻擊者修改代碼的主要部分或者配置選項，該 IOC 仍然可以識別到它。

基於方法的 IOC

上述都是在描述如何創建用於描述給定文件屬性的 IOC，下面則介紹如何創建用於描述攻擊者行為的 IOC，因為這裡沒有相關的惡意軟體。這些 IOC 被稱為基於方法的指標，可將基於屬性的指標與活躍的攻擊者留下的證物信息結合起來。作者在此以 sethc.exe 替換攻擊為例。Windows 平台上的 sethc.exe 應用程序是一種輔助各種殘疾人士使用 Windows 的增強功能。通過五次快速連續按 SHIFT 鍵進行調用，並可以在成功登錄之前啟動。攻擊者使用該功能、進行替換後可以啟動以系統許可權運行的 cmd.exe 會話。有兩種主要的攻擊執行方法。可以通過 5 次按鍵將啟動位於 c: windowssystem32sethc.exe 的任何可執行映像。其次，還可以將 cmd.exe 添加到註冊表中 sethc 可執行文件的調試句柄，因為 Windows 不會對此做檢查。

針對這類攻擊，以Win 7 SP0為例，IOC 會首先校驗 sethc.exe 的 MD5 hash以及存儲在PE文件的時間戳，判斷條件具體如下：

如果要考慮遍歷所有系統版本及補丁包，上述校驗將變得難以管理、不可控。根據作者經驗，通常 sethc.exe 會被替換為 cmd.exe，且文件大小存在差異，cmd的文件大小總是至少比最大的 sethc 二進位大 10%。因此，IOC 判斷條件可以這樣編寫：

考慮到替換文件還可能是小於文件大小閾值的其他應用，所以需要使用其他半唯一（semi-unique）屬性來降低誤報。前面提到的第2種攻擊方法，通過在註冊表中搜索相關key的存在，確定是否使用了特定映像的調試器。如果用於鏈接命令到 sethc 的映像執行調試器，其註冊表有任何鍵值設置，則應檢查該系統。判斷條件如下圖所示：

最後，作者將上述兩個片段以 OpenIOC（Mandiant採用的IOC格式）語言組合成失陷指標，並對兩者做了對比，建議讀者回想關於了解所使用工具局限性的討論。這裡主要有兩種不同之處值得注意。首先是 OpenIOC 格式的部分路徑。作者希望此檢測與卷無關, 因此在文件的完整路徑上使用「包含」術語。第2個不同在於OpenIOC 使用了範圍而非不等式。這是受限於使用的查詢工具，匹配引擎不會評估不等式。

文中作者還列舉了網路 IOC 的例子，此外，作者對 IOC 的驗證也做了很多經驗分享，主要還是考慮 IOC 在企業內的部署規模，除了對相關性、通用性進行充分驗證，還需要考慮指標的性能以及影響。這裡因為篇幅原因，就不再贅述。

寫在文末

筆者主要就線索如何轉化為 IOC 以及涉及的相關概念做了介紹。筆者感慨於作者將實戰經驗進行系統思考和總結，充分體現了上佳的理論素養。另外，作為這方面的小白，通過學習也算是揭開一點點 IOC 的神秘面紗，開拓了思路。相信業界有經驗的安全分析師或者響應人員，這正是他們的日常工作之一。隨著讀書進度，越發覺得確如 FireEye自己所說，Helix是一個多年積累的產物。

Luttgens, Jason T.; Pepe, Matthew; Mandia, Kevin. Incident Response & Computer Forensics, Third Edition (p. 100). McGraw-Hill Education. ??

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！