昨天講完事件怎麼從 Windows 走到 Wazuh。今天想講的是它抵達之後變成的那個東西——一筆告警——裡面有什麼,以及那個看起來很重要的等級數字,到底該如何訂定。這兩件事我原本打算分兩天寫,後來覺得放在一起講比較連貫,就併成一天。

一筆告警裡面有什麼？
Wazuh 的告警是一包結構化的 JSON。我目前實際會用到的欄位,大致可以分成幾組:

時間：timestamp,事件發生或告警產生的時間。
來源主機：agent.name、agent.ip,告訴你這是哪台機器產生的。
處理者：manager.name,哪台 Wazuh Manager 處理了這筆。
規則：rule.id、rule.level、rule.description、rule.groups,觸發了哪條規則、多嚴重、人看得懂的描述、分類標籤。
規則對應 MITRE:rule.mitre.id、rule.mitre.tactic、rule.mitre.technique,如果這條規則有掛 ATT&CK 對應的話。
Windows 系統資訊：data.win.system.eventID、data.win.system.providerName,對回 Windows 原始的 Event ID 跟來源。
Windows 事件細節：data.win.eventdata.targetUserName、ipAddress、workstationName 這類欄位,視事件類型而定,不是每筆都有。
定位：location、full_log,這筆日誌從哪個通道來的、原始全文。

如果你有印象,Day 4 追那筆新增帳號事件的時候,我提到命中的是 110121、等級是中等的那次——那筆告警裡上面這些欄位都有,只是我當時沒有整包攤開講。之後如果我截 alert JSON 的圖,大概就是長這樣的結構。

有件事想先講清楚：rule.id 這個數字本身,只在我自己的環境裡有意義。同一個 Wazuh 裝在別的地方,因為載入的規則集版本、有沒有自訂規則不一樣,同一個編號可能對應到完全不同的東西。所以我在文章裡提到的 rule.id,都是我自己環境裡實測過的,不是可以直接照抄的通用對照表。

rule.level:0 到 15,但數字大不代表你想的那樣...
Wazuh 的等級一般是 0 到 15,數字越大理論上越嚴重。低等級的事件甚至可能不會產生告警,只是被記錄下來。

聽起來很直覺但同一個等級數字,在不同規則背後代表的實際風險可能差很多。 我之後應該會講到一個具體案例——有一條規則的等級是 Wazuh 定義裡數一數二高的,但它的觸發來源其實只是 Windows 系統自己的例行維護動作,並不是攻擊。等級數字本身,並不能單獨拿來當作「這件事有多危險」的答案。

Wazuh Rules 管理頁：

Discover 的等級分布：

等級之上還有一層：我怎麼決定該不該報警
rule.level 是起點,不是終點。我目前的想法是,還要疊上幾個會讓風險往上或往下調整的因素,才是我實際判斷「這件事要不要緊張」的依據:

會往上調的：
從「嘗試」變成「成功」(例如登入失敗一堆之後突然成功)。
命中了跨事件的關聯型樣,不是單一告警。
牽涉到特權帳號或關鍵主機。
伴隨防禦被削弱的跡象(清日誌、關防護)。
來源是外部或攻擊網段。

會往下調的：
有合理的業務解釋,或者符合我已經確認過的誤判型態。 屬於授權的維運或測試活動,而且有紀錄可查。

Day 4 那筆事件正好是一個「往上調」的活生生例子：單獨的新增帳號,等級中等;但因為緊接著命中了「同一操作者、短時間內加入特權群組」這個關聯條件,最終等級被拉高了不少。同一個人做的兩件事,分開看都不算太嚴重,合起來看風險完全不同——這也是我覺得,如果只看單筆告警的等級數字,很容易漏掉真正該注意的情況。

這一層目前我還沒有把它寫成可以自動判斷的規則,比較像是我自己看告警的時候,腦中會過的一套檢查清單。要不要把它變成系統裡真的會跑的邏輯,是我後面 可能/應該/大概/希望 處理的事...

明天
接下來想講我自己寫的那批偵測規則——從一開始寫的版本,到後來測試發現不如預期、回頭修改的過程。

明天見。