昨天講完 RDP 暴力破解的設計，今天想把背後更根本的一個原理講清楚：為什麼「大量失敗之後緊接著一次成功」這種型態,單靠一條規則看單一事件是抓不到的,一定要靠關聯才行。

評估一筆事件的時候,只看得到這筆事件本身
Wazuh 的規則,本質上是針對「進來的這一筆事件」去比對條件——這個事件的 Event ID 是什麼、欄位裡的值符不符合某個樣式。如果我寫一條規則說「4624 且來源是外部」,這條規則在評估某一筆 4624 事件的當下,看不到三分鐘前同一個來源送過幾次 4625。單一事件本身,不帶有「這是不是暴力破解猜中的那一次」這種上下文,規則沒有辦法無中生有推斷出它跟之前的失敗有關係。

這就是為什麼單獨一條規則,不管條件寫得多細,結構上就是抓不到「失敗後成功」這種需要跨時間、跨事件比對的型態。要抓到,得靠專門的關聯機制。

關聯機制怎麼補上這個缺口？
Wazuh 提供的做法,大致是讓一條規則可以「記得」前面規則的命中結果：一種是用頻率累積,在時間窗內同來源命中低等級規則達到一定次數才升級;另一種是讓後面的規則直接參照前面某條規則有沒有命中過,再加上比對是不是同一個帳號或同一個來源,確認這兩件事真的是同一條故事線,不是巧合湊在一起。

這個機制我不是紙上談兵——Day 4 跟 Day 8 那條「建帳號後加入特權群組」的關聯規則,用的就是同一種手法：靠前面規則的命中結果加上「同一操作者」的條件,把兩個分開的動作串成一條有意義的鏈,而且是我真的用實機事件驗證過、看著它從頭到尾觸發的。

但這裡要老實劃清楚一條界線：關聯這個機制本身,在我的環境裡是驗證過的;但「失敗後成功」這個特定的應用,還沒有。 Day 8 提過,負責處理登入失敗跟破解成功的那幾條規則,目前只做過語法檢查,沒有真的餵過一段「連續失敗、最後一次成功」的真實序列去看它會不會如預期觸發。 機制證明可行,不等於這個具體用法也已經證明可行。

同樣的形狀,不一定是同一件事
值得先提醒自己一句：失敗後成功這個型態,惡意跟良性長得一模一樣。使用者自己打錯密碼兩三次,最後一次打對,產生的事件序列跟暴力破解猜中沒有結構上的差異。

真正能區分的,是節奏跟來源：自動化嘗試通常間隔很規律、失敗次數多、來源可能是外部或不常見的位址;人為打錯密碼通常間隔不規則、次數少、來源是使用者慣用的裝置。這幾個判斷因子我目前還沒有寫成規則裡具體的門檻,停留在「知道該看什麼」的階段,跟 Day 12 提到的情況類似。

明天
接下來想把跨事件關聯這件事講得更完整一點,一次講完我目前設計的五種關聯型樣,不只是失敗後成功這一種。

明天見。