Day 13｜Windows Event Log 收到了，接下來怎麼看？從常見 Event ID 開始

前一天談到自動化時，我分享了如何依照設定條件，讓 Stellar Cyber 與防火牆連動。不過，自動化之前，還有一個更基本的問題：我們是不是看得懂收到的資料？

這個問題，在我剛開始接觸 Windows Event Log 時特別明顯。

我工作上使用 Stellar Cyber 的 Windows Sensor 收集 Windows 端的紀錄。最初確認平台有收到資料時，至少知道收集有在運作；但真的要判讀時，我卻不一定知道這些紀錄可以幫上什麼忙。

有時候是不知道 Event ID 代表什麼，有時候則是看懂了事件名稱，仍然不知道：「這個需要跟客戶說嗎？」

Windows Log 有進來，卻不一定能回答問題

我做過的 Windows Log 收集主要還是基本設定，沒有深入排查過每一種事件的產生條件。不過，在工作中我遇過一個很直接的問題：平台雖然有收到 Windows Log，真正想查的事件卻不一定存在。

後來我才逐漸把兩件事情分開來看：Windows 本機有沒有產生需要的事件，以及事件產生後有沒有被 Sensor 收集並送進 SIEM。

如果 Windows 本機沒有留下那一類紀錄，就算 Sensor 正常、SIEM 也持續有資料進來，調查時仍然可能找不到需要的答案。不同的稽核原則，也會影響系統實際留下哪些事件。
Microsoft：建議監控的事件

我以前就曾因為需要記錄登入與登出的情況，先查詢對應的稽核原則，再請客戶協助開啟。後續收集到相關紀錄後，也曾從中注意到較不尋常的登入與登出活動。

這是我當時比較實際的做法：先確認缺少什麼紀錄、查詢需要開啟哪一項原則，再與客戶說明。不是由我直接把所有稽核項目全部打開，也不是每一種 Windows Event 的缺漏，我都已經做過深入排查。

我開始從 Event ID 認識紀錄

剛開始接觸 Windows Event Log 時，一串事件編號對我來說並不直觀。後來我發現，不一定要先把大量編號背起來，可以從工作中最常碰到的問題開始：誰登入了？有沒有登入失敗？哪個程式被啟動？有人存取共享資料夾嗎？

下面整理的是幾種可以先認識的 Windows Security Event。這是一份基礎參考，不代表我在客戶環境中逐一驗證過所有項目。每個 Event ID 都附上 Microsoft 官方文件，需要時可以再查看完整欄位與說明。

先知道一筆事件在描述什麼，才比較容易往下看。不過，知道 Event ID 的意思，還不等於知道這筆活動是不是攻擊。

登入成功，為什麼仍然可能值得確認？

我以前不確定是否需要向客戶通報，其中一個原因，就是有些事件看起來並不是「失敗」或「攻擊」。

例如登入成功，從系統角度來看，只是完成了一次登入。但從監控角度來看，我還會想知道：這個帳號真的應該在這個時間，從這個來源登入嗎？

依照我的工作回憶，我曾在 Stellar Cyber 中看到與 VM／ESXi 有關的登入成功紀錄。讓我注意的不是「成功」這兩個字，而是登入出現在非上班時間，來源 IP 或主機名稱也不像平常預期會登入的設備。

我將看到的時間、帳號與來源等資訊提供給客戶。後來客戶更換了相關密碼，也發現該帳號屬於一名已離職員工。

這段經驗涉及虛擬化環境與平台整合後的資訊，目前不能直接寫成「我透過 Windows Event ID 4624 發現問題」。它比較適合用來說明，我為什麼不能只看一個「登入成功」的名稱，而需要把時間、來源、帳號身分與設備用途放在一起判讀。

同樣地，發現帳號屬於已離職員工，也不代表已經確認是該員工本人操作，更不能直接證明帳號已經遭到盜用。這些都還需要其他證據才能回答。

回到 Windows，4624 也不一定表示有人坐在電腦前輸入密碼。它還可能來自網路存取、服務啟動或遠端登入。例如 Logon Type 2 是互動式登入、3 是網路登入、5 是服務登入，10 則是遠端互動式登入，常見於遠端桌面情境。因此，不能看到 4624 就全部解讀成有人透過 RDP 登入。
Microsoft：4624 與 Logon Type

這也是我想先弄懂常見 Event ID 的原因。同樣叫做登入，背後可能代表不同的活動。

有收到事件，欄位仍可能不夠判讀

除了登入與登出，4688、5140 和 5145 也能提供不同方向的線索。

4688 記錄新程序建立，可以協助了解哪個程式被啟動。不過，有收到 4688，不代表一定能看到完整命令列。Microsoft 的文件提到，命令列欄位需要另外開啟對應原則，預設可能是空白。
Microsoft：Event ID 4688

這正好呼應我曾遇過的情況：SIEM 確實收到事件，欄位解析或內容卻不完整，對當時的判讀幫助有限。

5140 與 5145 則和網路共享存取有關。5140 記錄共享物件被存取；5145 記錄的是系統檢查用戶端是否具有所要求的存取權限。因此，看到 5145，不能直接解讀成某個檔案已經被完整讀取、複製或外洩。
Microsoft：Event ID 5140、Event ID 5145

回想前面談過的 SMB 噪音，也是類似的道理。看到共享存取後，還是需要了解設備原本在做什麼、帳號是否合理，以及存取目標是不是正常工作所需。

這些是我在整理資料後，逐漸補上的基礎知識，不是要把每一種事件都包裝成自己已經完成過的調查案例。

測試中看到的 Event ID 1102

除了客戶環境，我也曾在測試環境中使用 Wazuh，監看同事透過 Kali 執行攻擊模擬時留下的事件。

依照我的回憶，同事完成最後一個步驟後，我在監控畫面看到了 Event ID 1102。這個事件代表 Windows Security 稽核紀錄遭到清除，但它不是指整台設備的所有 Log 都已經消失。
Microsoft：Event ID 1102

回頭檢查目前保留的主腳本，裡面沒有直接看到清除 Windows Event Log 的指令。我當時懷疑可能是工具本身附帶的清理行為，或是後續執行的其他內容所造成，但目前沒有足夠資料可以確認真正的觸發來源。

因此，我能確定的是測試期間曾在 Wazuh 看到 1102，卻不能進一步指定是哪一項工具或哪一行指令造成。這也是測試環境中的觀察，不是真實客戶遭到入侵的案例。

這次經驗讓我開始留意「清除紀錄」本身也可能是調查線索。但在實際環境中，即使看到 1102，仍要確認是誰清除、為什麼清除，以及前後是否還有其他異常活動。系統維護或管理操作也可能涉及紀錄清除，不能只憑一個 Event ID 判斷動機。

從「有收到」走到「知道怎麼問」

回到我最初的困惑：看懂 Event ID 之後，什麼情況需要跟客戶說？

後來我覺得，這件事很難只靠一張事件編號清單決定。比較實際的做法，是先把紀錄轉成可以向客戶確認的問題：這個帳號是否仍有人使用？這個時間是否有維護或遠端作業？來源 IP 或主機是否屬於預期設備？這個帳號的活動是否符合原本用途？前後還有沒有其他登入失敗、程序執行或異常連線？

這些是我整理這篇文章時歸納出的查證方向，不代表我過去每一次都完整做過所有項目。

通報也不一定要一開始就宣告「已經遭到入侵」。有時候，先把看到的時間、帳號、來源與不合理之處說清楚，請客戶協助確認，就能讓後續調查往前走。

我想記錄的，是自己從「確認 Windows Log 有進來」，逐漸走到「開始知道這些 Log 可以拿來問什麼問題」的過程。

有些問題要先請客戶開啟對應的稽核原則，才有資料可以看；有些紀錄雖然收到了，仍需要補上帳號、設備用途與正常作業時間，才能判斷是否值得追查。

對我來說，現在不需要把所有 Event ID 全部背起來。但至少可以從常見事件開始，逐步弄懂它記錄了什麼、沒有告訴我什麼，以及接下來還需要確認什麼。