昨天講完為什麼單點規則抓不到失敗後成功。今天想把關聯偵測這件事講得更完整一點一次講完,不含糊帶過。
兩層偵測,溫習一下
前面幾天已經反覆碰過這個區分：單點規則看單一事件,強項是即時、明確,弱點是容易誤報、看不到脈絡;關聯偵測跨事件、跨時間看行為型樣,強項是貼近真實的攻擊手法、誤報較低,但要靠單點規則先產生訊號才有東西可以關聯。
品質的分層大概是這樣：最低品質是單一指標就告警(例如只看程序名稱是不是 powershell.exe);好一點是父程序加命令列加條件的組合;更好的是一整條行為鏈疊上時間窗的限制。這個分層原則,其實貫穿了我從 Day 8 到 Day 16 一路在講的東西。
一套幫我釐清「卡在哪」的架構：四態驗證
這裡想先介紹一個我覺得很有用的分類方式,再拿它回頭整理前面幾天講過的坑,你會發現很多篇其實都可以套進同一個架構裡。
每個「預期應該要有訊號」的情境,驗證結果可以分成四態：
None：照理應該要有訊號,但感測器端根本沒有資料。通常是 Agent、稽核政策、Sysmon 篩選條件、時間同步這類問題。
Telemetry：原始資料確實存在,但還沒有變成規則或告警。可能是 decoder 沒解析對、欄位對映有問題。
Failed：規則存在,但這次沒有命中。可能是條件寫錯、門檻不對,或者攻擊手法的變體規則沒涵蓋到。
Success：命中了,而且可以回溯到原始的證據。
回頭看,Day 6 那個 PowerShell 通道還沒加進 Wazuh 的缺口,屬於 None——資料從沒進來過。Day 8 一開始那個「掛錯父規則」的問題,屬於 Failed——規則有,這次沒接上訊號,但告警表面看起來正常,很容易誤判成 Success。Day 4、Day 8 那條建帳號→加特權群組的鏈,是少數走到 Success 的案例,而且真的能回溯到原始的 4720、4732 事件跟對應的 alert JSON。
這個架構對我自己最大的用處是：**它逼我區分「完全沒資料」「有資料沒告警」「有告警但邏輯沒接上」「真的驗證成功」這四種完全不同的狀態。**之後每次寫到某個情境沒驗證過,我會盡量標出它具體卡在哪一態,而不是籠統帶過。
六種跨事件型樣：
| 型樣 | 觸發邏輯 | 目前狀態 |
|---|---|---|
| C1 暴力破解成功 | 同來源時間窗內多次失敗後出現成功 | 對應規則 110150→110151→110152。Day 16 剛好在處理這條，依實測結果決定是 Failed 還是 Success。 |
| C2 建帳號→加特權群組 | 同操作者時間窗內先建帳號、再加入特權群組 | 對應規則 110121+110131/132/133→110160。已用實機事件驗證過，Success。 |
| C3 Office→腳本→外連 | Office 程序生出腳本宿主，隨後對外連線或寫檔 | 目前只有情境描述，沒有對應的自訂規則實作。 |
| C4 削弱防禦後的活動 | 稽核政策變更或防護停用後，同主機出現可疑登入或程序 | 同樣只有情境描述，沒有規則實作。 |
| C5 帳號基準偏離 | 帳號從罕見來源或時段登入，或短時間跨多台主機 | 只有情境描述，沒有規則實作，也還沒有「基準」本身可以拿來比對。 |
| C6 Bind shell 證據鏈 | Listener 啟動後接受入站連線，再建立 shell 子程序 | 對應規則 110110/111+110112→110162。目前還停在語法正確，沒有實機驗證過。 |
六條裡,只有 C2 是真的走到 Success;C1 跟 C6 有對應的規則但沒驗證過(C1 的狀態要看 Day 16 那次測試的結果);C3、C4、C5 目前連規則都還沒寫,只有型樣本身的設計。
一個容易被忽略的精確度問題
寫到這裡想補一個細節,是我重新看文件的時候才注意到的：C2 那條鏈,判斷「是不是同一個新帳號被加入群組」的方式,目前是用「同一個操作者」這個條件去近似,不是直接比對「這個被加入群組的帳號,跟剛剛被建立的是不是同一個」。原因是 4720 記錄新帳號的欄位,跟 4732 記錄被加入成員的欄位,兩者的資料結構不太一樣,還沒有做過正規化去直接比對。
這不影響 Day 4 那次驗證的有效性——那次操作者確實只做了這兩件事,近似條件跟精確條件會給出一樣的結果。但如果情境更複雜一點(例如同一個操作者短時間內建了兩個帳號、只把其中一個加進群組),目前的規則沒辦法保證抓對是哪一個。
明天
接下來想把偵測邏輯這條線收個尾,講 MITRE ATT&CK 對應要怎麼真的用起來,而不只是規則描述裡貼一個技術編號。
明天見。
iThome鐵人賽
看影片追技術