昨天停下來回顧了一次前九天。今天回到正題,想把 Windows Security 日誌這塊地形先攤開來看一遍,再往下走攻擊情境跟偵測邏輯——如果連日誌本身長什麼樣子都沒搞清楚,後面講攻擊情境很容易變成空談。

這份日誌記錄什麼？
Windows 的 Security 日誌記錄跟安全相關的系統活動：登入登出、帳號與群組管理、特殊權限的使用、程序建立、稽核政策本身的變更。 這是我目前大多數偵測邏輯的原始資料來源。

一個提醒,雖然前面幾天已經隱約講過,這裡想講明白一點：單一事件大多數時候是正常的,價值在於關聯跟異常對照,不是看到某個 Event ID 出現就緊張。這也是為什麼 Day 4 那條攻擊鏈規則要靠「同一操作者、短時間內」這個條件,而不是單獨看某一筆事件。

常見的 Event ID 家族
大致分幾類 (以 Microsoft 官方文件的語意為準,實際觸發條件尚未每一個都驗證過)：

裡面 4720、4728、4732 這幾個,前面幾天已經在 Day 4 跟 Day 8 反覆出現過,算是我目前少數真的走過完整驗證的部分。其他像 4688、4648、4672 這幾個,我目前還停在「知道意義、還沒逐一拿真實事件對照過」的階段。

Event Viewer 裡 Security 日誌的總覽畫面,看得出這份日誌大致的量體跟事件種類分布。

Logon Type：同樣是「登入」,場景差很多
登入相關的事件裡有一個欄位我覺得特別重要:Logon Type。同樣是 4624 登入成功,背後代表的場景完全不一樣:

這個欄位的實際用途,是幫我判斷「這筆登入合不合理」。舉例來說,如果一個平常只會用本機互動登入(Type 2)的帳號,突然出現 Type 10(RDP)的登入,這件事本身可能就值得多看一眼——雖然我目前還沒有針對這種基準比對寫成規則,這一段是我接下來想補的部分。

一筆實際的登入事件,框出 Logon Type 這個欄位的位置跟數值。

AD 網域這一層,還有一個沒補的洞
如果主機有加入網域,還會有一批帳號認證跟目錄相關的事件記在網域控制站上,例如 Kerberos 相關的票證事件、目錄物件被修改的事件。這批事件我目前的認識比較薄弱,連 Event ID 語意都還沒有一一對照過 Microsoft 官方文件確認。

這裡剛好呼應 Day 9 提過的那個缺口：網域控制站目前的事件採集設定,還沒有涵蓋目錄服務與複寫相關的通道。也就是說,就算我理論上知道該看哪些 Kerberos 或目錄變更事件,實際上這台主機的採集範圍可能還接不到
這個缺口目前還沒補,先記著。 (o′┏▽┓｀o)

常見會誤判的情況
寫這篇的時候順便把我目前知道的誤判型態整理一下,避免自己以後忘記：排程工作或服務帳號的登入(Type 4/5)、正常的網路共享存取(Type 3),這幾種常常大量出現,但多半跟惡意行為無關。這跟 Day 9 講的噪音問題是同一種邏輯的延伸——量大不代表危險,要看背景脈絡合不合理。

明天
接下來想講兩個最基本的登入事件:4624 跟 4625,以及我在裡面一個叫 SubStatus 的欄位上踩到的坑。

明天見。