本文是 Sysmon 威脅分析系列的第一部分。 該系列的所有其他部分：
第1部分：Sysmon日誌分析簡介 （我們在這裡）
第 2 部分：使用 Sysmon 事件資料識別威脅
第 3 部分. 使用圖表深入分析 Sysmon 威脅
如果您從事資訊安全工作，您可能經常需要了解正在進行的攻擊。 如果您已經擁有訓練有素的眼睛，則可以在「原始」未處理日誌中尋找非標準活動 - 例如，正在執行的 PowerShell 腳本 或偽裝成 Word 檔案的 VBS 腳本 - 只需捲動 Windows 事件日誌中的最新活動即可。 但這確實是一個非常令人頭痛的問題。 幸運的是，微軟創建了 Sysmon，這使得攻擊分析變得更加容易。
想要了解 Sysmon 日誌中顯示的威脅背後的基本想法嗎？ 下載我們的指南 您會意識到內部人員如何秘密觀察其他員工。 使用 Windows 事件日誌的主要問題是缺乏有關父進程的信息，即從中無法理解流程的層次結構。 另一方面，Sysmon 日誌條目包含父進程 ID、其名稱以及要啟動的命令列。 謝謝你，微軟。
在我們系列的第一部分中，我們將了解您可以使用 Sysmon 的基本資訊做什麼。 在第 XNUMX 部分中，我們將充分利用父進程資訊來建立更複雜的合規性結構（稱為威脅圖）。 在第三部分中，我們將研究一種簡單的演算法，該演算法掃描威脅圖，透過分析圖的「權重」來搜尋異常活動。 最後，您將獲得一種簡潔（且易於理解）的機率威脅偵測方法。
第1部分：Sysmon日誌分析簡介
什麼可以幫助您理解事件日誌的複雜性？ 最終——SIEM。 它將事件標準化並簡化後續分析。 但我們不必走那麼遠，至少一開始不需要。 一開始，要了解 SIEM 的原理，嘗試一下精彩的免費 Sysmon 實用程式就足夠了。 而且她出奇地容易相處。 繼續努力，微軟！
Sysmon 有哪些功能？
簡而言之 - 有關流程的有用且可讀的資訊（見下圖）。 您會發現 Windows 事件日誌中沒有的大量有用詳細信息，但最重要的是以下欄位：
- 進程 ID（十進制，而不是十六進制！）
- 父進程ID
- 處理命令列
- 父親進程的命令列
- 文件圖像哈希
- 檔案圖像名稱
Sysmon 既作為設備驅動程式又作為服務安裝 - 更多詳細信息 它的主要優點是能夠分析來自 幾個 來源、資訊關聯以及結果值輸出到位於路徑沿線的一個事件日誌資料夾 Microsoft -> Windows -> Sysmon -> 操作。 在我自己對Windows 日誌進行的令人毛骨悚然的調查中，我發現自己必須不斷地在PowerShell 日誌資料夾和安全性資料夾之間切換，快速瀏覽事件日誌，勇敢地嘗試以某種方式將兩者之間的值關聯起來。 這從來都不是一件容易的事，我後來意識到，最好立即儲備阿斯匹靈。
Sysmon 透過提供有用的（或供應商喜歡說的，可操作的）資訊來幫助理解底層流程，從而實現了巨大的飛躍。 例如，我開始了一個秘密會議 ，模擬網路內智慧內部人員的移動。 這是您將在 Windows 事件日誌中看到的內容：
Windows日誌顯示了有關該進程的一些信息，但用處不大。 加上十六進制的進程ID？？？
對於了解駭客基礎知識的專業 IT 專業人員來說，命令列應該是值得懷疑的。 使用cmd.exe然後執行另一個命令並將輸出重定向到一個奇怪名稱的文件，這顯然類似於監控軟體的操作 ：這樣就使用WMI服務建立了一個偽shell。
現在讓我們來看看 Sysmon 條目的等效項，注意它為我們提供了多少附加資訊：
Sysmon 功能在一張螢幕截圖中：以可讀的形式提供有關進程的詳細信息
您不僅可以看到命令列，還可以看到檔案名稱、可執行應用程式的路徑、Windows 所了解的資訊（「Windows 命令處理器」）、識別符 父母的 行程、命令列 家長，它啟動了cmd shell，以及父進程的真實檔名。 終於一切都集中在一處！
從 Sysmon 日誌中我們可以得出結論，我們在「原始」日誌中看到的這個可疑命令列很可能不是員工正常工作的結果。 恰恰相反，它是由類似 C2 的進程（如我之前提到的 wmiexec）產生的，並且直接由 WMI 服務進程 (WmiPrvSe) 產生。 現在我們有一個跡象表明遠端攻擊者或內部人員正在測試公司基礎設施。
介紹 Get-Sysmonlogs
當然，如果 Sysmon 將日誌放在一處，那就太好了。 但如果我們能夠以程式設計方式存取各個日誌欄位（例如透過 PowerShell 命令），情況可能會更好。 在這種情況下，您可以編寫一個小型 PowerShell 腳本來自動搜尋潛在威脅！
我並不是第一個有這樣想法的人。 在一些論壇帖子和 GitHub 中，這很好 前面已經解釋如何使用PowerShell解析Sysmon日誌。 就我而言，我想避免為每個 Sysmon 欄位編寫單獨的解析腳本行。 所以我使用了懶人原則，我想我想出了一些有趣的結果。
第一個重要的點是團隊的能力 讀取 Sysmon 日誌，過濾必要的事件並將結果輸出到 PS 變量，如下所示：
$events = Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" | where { $_.id -eq 1 -or $_.id -eq 11}
如果您想自行測試該命令，透過顯示 $events 陣列的第一個元素 $events[0].Message 中的內容，輸出可以是一系列格式非常簡單的文字字串： Sysmon 欄位、冒號，然後是值本身。
萬歲！ 將 Sysmon 日誌輸出為 JSON-ready 格式
你是不是跟我有同樣的想法？ 只需多一點努力，您就可以將輸出轉換為 JSON 格式的字串，然後使用強大的命令將其直接載入到 PS 物件中 .
我將在下一部分中展示用於轉換的 PowerShell 程式碼 - 它非常簡單。 現在，讓我們看看我作為 PS 模組安裝的名為 get-sysmonlogs 的新命令可以執行哪些操作。
我們可以輕鬆地直接從 PowerShell 會話中搜尋增量活動，以及使用 PS 命令，而不是透過不方便的事件日誌介面深入進行 Sysmon 日誌分析 （別名 - “？”）縮短搜尋結果：
透過 WMI 啟動的 cmd shell 清單。 使用我們自己的 Get-Sysmonlogs 團隊進行廉價的威脅分析
奇妙！ 我創建了一個工具來輪詢 Sysmon 日誌，就像它是一個資料庫一樣。 在我們的文章中關於 值得注意的是，該功能將由其中描述的酷實用程式執行，儘管形式上仍然是透過真正的類似 SQL 的介面。 是的，EQL 優雅的，但我們會在第三部分談到它。
Sysmon 和圖形分析
讓我們退一步思考一下我們剛剛創建的內容。 本質上，我們現在擁有一個可透過 PowerShell 存取的 Windows 事件資料庫。 正如我之前提到的，記錄之間存在連接或關係（透過 ParentProcessId），因此可以獲得完整的流程層次結構。
如果您讀過該系列 您知道，駭客喜歡創建複雜的多階段攻擊，其中每個進程都發揮自己的小作用，並為下一步準備跳板。 僅僅從「原始」日誌中捕獲這些東西是極其困難的。
但是，透過我的 Get-Sysmonlogs 命令和我們稍後將在文本中查看的附加資料結構（當然是圖表），我們有一種實用的方法來檢測威脅 - 這只需要進行正確的頂點搜尋。
與我們的 DYI 部落格專案一樣，您越多分析小規模威脅的細節，您就越會意識到企業層級的威脅偵測有多複雜。 而這種意識是極其 很重要的一點.
我們將在本文的第二部分中遇到第一個有趣的複雜情況，我們將開始將 Sysmon 事件相互連接成更複雜的結構。
來源： www.habr.com