昨天講完 Windows Security 日誌的整體地圖。今天想聚焦兩個最基本、也最常被拿來判斷登入行為的事件：4624 登入成功、4625 登入失敗。順便講一件事我目前刻意不做的原因。

4624：登入成功,但場景差很多
4624 記錄一次成功的登入。單獨一筆,大多數時候就是正常使用。真正有意義的判讀,通常要搭配幾個欄位一起看：登入的帳號、來源、Logon Type(Day 11 講過的那個欄位),以及有沒有伴隨 4672(指派特殊權限)或 4648(使用明確憑證)這類事件一起出現。

比較值得留意的訊號,是脈絡不對的成功登入：平常不會在這個時段出現的登入、罕見的來源、特權帳號登入一台不該登入的一般端點,或者——這個我在 Day 4 已經實際處理過類似邏輯——緊接在大量失敗之後突然出現的成功。這件事對映到 MITRE 的 T1078(濫用有效憑證)。

也要老實提一下常見的誤判情境：服務帳號或排程工作規律性地登入、透過固定 VPN 或跳板機登入、多人共用同一台工作站——這幾種情況都可能產生大量看似「異常」但其實完全合理的成功登入紀錄,判斷的時候不能只看事件本身,要對照這台主機、這個帳號平常的使用模式。

4625：登入失敗,暴力破解的核心訊號
4625 記錄一次登入失敗。少量的失敗通常只是打錯密碼;但大量失敗,不管是同一個帳號被反覆嘗試不同密碼(暴力破解),還是同一組密碼被拿去試很多不同帳號(密碼噴灑),都是需要留意的訊號,對映 MITRE 的 T1110。

這裡有一個欄位理論上很有價值,但我目前為什麼沒有直接拿來用：失敗原因碼,也就是 Status 跟 SubStatus。這兩個欄位理論上可以分辨「密碼打錯」「帳號根本不存在」「帳號被鎖定或停用」這幾種不同的失敗原因——如果分得出來,對於判斷「這是暴力破解還是帳號列舉」會很有幫助：同一個帳號密碼一直錯,比較像暴力破解;如果失敗原因常常是「帳號不存在」,那更可能是有人在亂猜帳號名稱。

為什麼我刻意不寫死 SubStatus 代碼？
具體的失敗原因碼(例如某個特定的十六進位代碼對應「密碼錯誤」)網路上很多教學文章會直接列出來,照抄很方便。但我這次決定不這樣做,原因是：這些代碼的意義要以 Microsoft 官方文件為準,而且我還沒有拿自己環境裡真實產生的失敗事件,去對照過 Wazuh 的 decoder 實際解析出來的欄位長什麼樣子。如果我直接照抄一份代碼對照表寫進規則或文章裡,一旦哪個代碼記錯,或者 Wazuh 解析出來的欄位跟我以為的格式不一樣,判斷邏輯就會建立在錯誤的基礎上——而且這種錯不容易發現,因為規則可能照樣會產生告警,只是分類分錯了。

這跟 Day 8 那次「有告警不代表邏輯正確」是同一種風險的不同面貌。所以目前這一段我先誠實標成「還沒有拿真實事件驗證過」,等我真的抓到幾筆不同原因的 4625,對照過官方文件跟 Wazuh 的解析結果之後,才會把具體代碼寫進規則裡。

這兩個事件單獨看,能做的判斷有限
寫到這裡想強調一次：4624 跟 4625 單獨拿出來,能做的判斷都很有限。真正有意思的是把兩者放在一起看時間序列——同一個來源,失敗了很多次之後突然成功,這個型態本身就是一個很強的訊號,比任何一筆事件單獨看都更有意義。這部分我打算在後面講攻擊情境的時候(Day 16)專門展開,今天先把兩個事件本身的基礎打好。

明天
接下來想講帳號的生命週期:從建立、加入群組,到可能被鎖定,把 Day 4 那條鏈往前後延伸一點。

明天見。