很多人看到 Windows Security Event Log 的第一反應是..
「數字好多，先放著。」

I know..因為我也走過那段「拿著事件 ID 表在背，但腦中還是很空」的時期。
但站在治理與稽核角度，這些事件其實非常珍貴——它們是最接近「可被驗證事實」的一層資料：誰、在什麼時間、從哪裡、做了什麼。

這篇我想做一件務實的事..
把常見事件（4625 / 4624 / 4688 …）從「各個獨立的 point 」升級成「攻擊鏈時間線」，最後整理成一份可以交付給 SOC / IT 的 偵測 Playbook..目標可稽核、可複製、可持續維運 !

**你不需要背完所有事件 ID；你需要的是一套能反覆套用的判讀框架。

1. 先對準目標：我們要偵測的是「鏈」，不是「單點」

單一事件很容易讓人誤判..

1. 4625（登入失敗）可能是使用者忘記密碼，也可能是撞庫／爆破
2. 4624（登入成功）可能是正常上班，也可能是攻擊者終於猜中密碼
3. 4688（建立新處理序）正常也會發生，但攻擊者常在這裡開始「做事」
   所以偵測的核心不是「看到某個 ID 就緊張」，而是 Correlation..
   把「大量失敗 → 突然成功 → 之後出現可疑進程／命令列」串成時間線，你才會得到可行動的訊號。

**告警不是越多越好；越能解釋、越能交付、越能留下稽核軌跡，才是真的成熟。

2. 基礎準備：沒有可觀測，就沒有可稽核

如果你希望 4688 的判讀品質「真的能用」，建議先把這些前置做到位（至少做到最小可用）..

1. 啟用 Process Creation（4688）稽核
2. 盡量記錄 Command Line（命令列）——這是判讀品質的分水嶺
3. 確保 NTP ，否則事件串起來會像在拼錯時區的拼圖

**實務上我會建議先從「關鍵主機」開始（例如跳板機、AD 相關主機、重要伺服器），用 MVP 規模快速閉環。
一口氣全域啟用常會造成噪音與成本爆炸，治理上也不好交代「價值在哪」。

3. 事件 ID 不是用來背的：是用來定義「訊號」的

每個事件真正有價值的，是哪些欄位與如何被關聯..舉例來說

1. 4625 登入失敗: 你真正該看的方向或許是在 Account、Source IP/Workstation、Logon Type、Failure Reason/SubStatus、時間窗內次數。
2. 4624 登入成功: 你真正該看的方向或許是在 Account、Source IP/Workstation、Logon Type、是否「突然成功」。
3. 4688 建立新處理序: 你真正該看的方向或許是在 New Process、Parent Process、Command Line、執行身分、發生在成功登入後多久。
   ...etc

**事件本身沒有好壞。
真正的好壞，來自你把它放在「什麼上下文」裡看。

4. 三條最常見攻擊鏈

Chain A：登入爆破/撞庫 → 突然成功（4625 → 4624）
偵測目的：找出「大量失敗後突然成功」的可疑登入

最小可用關聯邏輯..

1. 同一帳號或同一來源 IP
2. 在 5–10 分鐘內出現大量 4625
3. 隨後出現 4624（成功）
4. 且成功的 Logon Type / 登入來源與平常行為不同

建議門檻（先保守，後續再細調）

1. 5 分鐘內失敗 ≥ 10 次（視環境調整）
2. 或同一來源 IP 對多個帳號持續失敗（Password Spray）

常見誤判來源（建議先寫進 Playbook，省下大量溝通成本..）

1. 使用者密碼過期、App 反覆重試
2. VPN/VDI 不穩造成重試
3. 服務帳號密碼已改，但排程沒改

**不是「變得更敏感」，而是「更可解釋」..
你要能回答：為什麼這個告警值得被升級？

Chain B：成功登入 → 迅速出現可疑新處理序（4624 → 4688）
偵測目的：抓到「登入後開始做事」的黃金時間

最小可用關聯邏輯..

1. 4624 後 0–10 分鐘內出現 4688
2. 且符合以下任一：
   i) Parent/Child 進程關係不合理（例如 Office/Adobe → cmd/powershell）
   ii) 命令列包含可疑特徵（下載、解碼、遠端執行、繞過等）
   iii) 執行位置在使用者暫存或不常見路徑

你該關注的 point..

1. Parent Process Name
2. New Process Name
3. Command Line
4. Account（用誰的身分跑）
5. Host（發生在哪台機器）

**4688 不一定告訴你「攻擊者來了」，但它常常告訴你「有人開始像攻擊者那樣做事」。

Chain C：攻擊者「關掉你的眼睛」（4612 / 1102）
偵測目的：偵測降低可觀測性的行為（真實攻擊裡很常見）

最小可用關聯邏輯..

1. 出現 4612（稽核策略變更）或 1102（清除紀錄）
2. 且同時間窗前後有登入異常、權限提升或可疑進程等跡象

處置優先級建議..
這類事件或許可以直接拉高嚴重度。原因很簡單..
它代表對方不是在「試試看」，而是在「降低你取證與追蹤的能力」。

**5. 把偵測做成治理語言..Playbook

下面這份模板當作內部文件的參考，交付給 SOC / IT 當標準作業流程。

**偵測 Playbook：Windows Login → Process Chain

Detection Objective..
偵測登入爆破/撞庫後的成功登入，以及成功登入後的可疑處理序行為，建立可追溯、可稽核的處置流程。

Signals..

1. 4625：登入失敗（門檻：N 次 / T 分鐘）
2. 4624：登入成功（判斷是否「突然成功」）
3. 4688：新處理序（含 Parent/Command Line）
4. nice 2 have..4612 / 1102 / 4796 / 4946：降低可觀測性、權限變更、開洞跡象

Correlation Logic..

1. T = 10 分鐘時間窗
2. 條件 A：同一 Account 或同一 Source IP 出現 4625 ≥ N
3. 條件 B：T 內出現 4624（同帳號或同來源）
4. 條件 C：4624 後 10 分鐘內出現 4688，且符合可疑特徵（Parent/Command Line/路徑）

Triage Steps..

1. 確認帳號性質：人員帳號 / 服務帳號 / 管理帳號
2. 檢查來源：IP、是否公司 VPN/VDI、是否常用裝置、是否異常時段
3. 4688 進程鏈：Parent → Child 是否合理呢？命令列是否可疑呢？
4. 同時間是否出現：群組變更、建立服務、遠端連線、開防火牆規則等跡象

Response

1. 低風險：通知使用者確認、要求改密碼、檢查裝置是否異常
2. 中風險：停用帳號/強制 MFA、隔離端點、調查同網段可疑活動
3. 高風險（含 1102/4612）：立即升級事件、保存證據、封鎖來源、啟動 IR 流程

Audit Evidence

1. 事件時間線（Event ID + 關鍵欄位）
2. 命令列與處理序關係（Parent/Child）
3. 來源 IP / 裝置資訊
4. 採取的控制措施與批准紀錄（誰決策、何時、依據是什麼）

RACI

1. Responsible：SOC/資安值班（初判、升級）
2. Accountable：資安主管（重大事件決策）
3. Consulted：IT/AD 管理員（帳號、政策、端點）
4. Informed：系統 Owner（受影響服務方）

**6. 偵測不是一次性專案，是能力產品化

如果你希望這套偵測能活過一季..

1. Baseline：先觀察 2–4 週正常行為（失敗率、常見來源、Logon Type）
2. Exception：已知服務帳號/排程要白名單，但要有審核紀錄與到期檢視
3. Feedback Loop：每次誤判都回寫規則，噪音下降、準確度上升
4. Auditability：每條規則都要能說清楚：目的、邏輯、門檻、Owner、驗收方式

**我們交付的不是「一堆告警」，而是一套「可被管理的偵測能力」。

**結語：事件 ID 本身不會保護你，會保護你的是「交付能力」

事件 ID 本身不會保護你。
真正能保護你的是..你能不能把它們串成時間線，並且把偵測落成可交付的 Playbook，留下可稽核的處置軌跡。

**告警多不代表成熟；能解釋、能交付、能持續維運才是 !