過去幾天，我從 Alert、False Positive、MITRE ATT&CK，一路談到如何透過 Case 與不同資料來源理解事件之間的關係。

到了 Day 11，我想把視角拉到實際參與過的勒索事件 IR（Incident Response，事件應變）。

不過，在開始以前，我想先說清楚一件事：一場 IR 並不是靠一個人完成的。

我參與過已確認檔案遭到加密、設備無法使用，或出現勒索訊息的事件，但我並不是整起事件的唯一處理人員。現場還有客戶及其他成員，分別處理設備還原、防火牆、端點調查與後續處置。

我主要參與的部分，是在客戶還原設備前先準備 SIEM，讓設備重新連網後可以立即開始監控；接著從觸發的 Alert、網路連線、帳號活動及其他可以取得的紀錄中找出異常，再把觀察結果提供給客戶與其他處理人員。

所以，這篇不是一套完整的勒索事件 IR 教科書，也不是要描述我一個人如何處理整起事件，而是分享我在其中負責及實際了解的部分。

為什麼要在設備還原前先準備 SIEM？

勒索事件發生後，客戶通常需要先處理無法使用或遭到加密的設備。設備如何還原，主要由客戶及負責的工程人員執行；我的工作則是先把 SIEM 的監控準備好。

原因很直接：如果等設備全部還原、重新連網一段時間後才開始監控，中間出現的活動可能就沒有被完整留下。

因此，在客戶開始還原以前，我會先確認 SIEM 已經部署完成，相關的 Log 能夠正常送入。當設備還原完成並重新連上網路時，我就能從當下開始觀察是否有新的異常活動。

這個階段關注的不只是「設備能不能正常開機」，還包含：

• 是否再次觸發安全告警。
• 是否有可疑的外部 IP 連入。
• 內部設備是否出現不符合原本用途的連線。
• 是否有帳號嘗試登入原本不該登入的設備。
• 如果有端點紀錄，是否能看到異常程序執行。

對我來說，設備恢復運作，只能代表服務可能回來了，不能直接代表環境已經安全。

設備重新連網後，我會先看觸發的 Alert

設備剛還原時，我通常會先看 SIEM 觸發了哪些 Alert。

不是因為看到 Alert 就能判斷攻擊者已經重新進入，而是其他行為通常需要累積一段時間，才比較容易看出規律。攻擊者也不會一直保持活動，分析人員未必能在設備重新上線的第一分鐘，就從大量 Log 中直接看出完整脈絡。

Alert 在這裡比較像是提示：先告訴我哪個時間、哪個 IP、哪台設備或哪個帳號值得優先確認。

這也延續前幾天文章一直強調的觀念：Alert 是調查起點，不是事件結論。

我曾經從 SIEM 告警中看到，特定外部 IP 在凌晨短時間內頻繁連線。遇到這種情況，我不會只看告警名稱就直接認定攻擊者已經成功進入，而是繼續確認來源與目的 IP、發生時間、連線的 Port、涉及的設備，以及防火牆最後採取了什麼動作。

SIEM 告訴我往哪裡查，但我仍會回到原始設備確認

SIEM 收到的 Firewall Log，大多會帶有允許、阻擋或其他處置結果。理論上，我可以直接從 SIEM 畫面判斷這筆連線發生了什麼事。

但在 IR 過程中，為了進一步確認，我仍會回到防火牆本身再查一次。

因為「看到連線嘗試」與「確認連線成功」是兩件不同的事。SIEM 可以快速集中資訊、協助我找到調查方向；防火牆上的原始紀錄，則能讓我再次核對設備實際採取的動作。

如果還能取得其他資料，我也會一起比對，例如：

• Windows Event Log 中的登入與帳號活動。
• EDR 偵測到的端點行為。
• 網路流量中的來源、目的與連線方向。
• 設備上正在執行的程序。

只是，IR 現場的資料通常不會像實驗環境那麼完整。

有些設備沒有安裝 EDR，有些設備缺少足夠的 Windows Event Log，也有可能真正需要調查的那台設備，剛好不是防護與紀錄最完整的一台。因此，分析時只能把當下能取得的資料拼起來，而不能假設每個問題都一定有完整證據可以直接回答。

帳號出現在不該出現的地方，就值得繼續往下查

除了外部 IP，我也會留意帳號活動。

例如，某個帳號原本不應該登入其他設備，卻出現了相關嘗試；或者帳號開始在不符合平常使用情境的主機上活動。這些現象不一定能直接證明帳號已經外洩，但足以成為後續調查的方向。

這時，我會把帳號、時間、來源與目的設備、使用的 Port，以及當下看到的其他行為整理出來。如果同一時間還能看到程序執行，也會一併提供給客戶及其他 IR 成員。

在這類事件裡，重要的不是急著替每一筆紀錄下結論，而是先把可以確認的資訊說清楚：我們看到了什麼、還缺少什麼，以及接下來需要確認什麼。

疑似被當成跳板的設備，不一定能立刻隔離

另一個會注意的方向，是內部設備是否持續嘗試連線其他設備。

如果一台設備原本的用途不需要主動連向多台內部主機，卻開始出現不符合原本設計的連線行為，就需要進一步確認它是否遭到利用。

不過，這種行為本身仍不能直接證明設備已經成為跳板。設備用途、正常的管理行為、排程工作或其他系統需求，都可能影響判斷。因此，還是需要向客戶確認這台設備原本負責什麼、平常會連到哪裡，以及當時是否有人進行維護。

如果設備有安裝 EDR，而且現場判斷需要控制風險，我曾協助透過 EDR 隔離設備。但不是所有設備都有 EDR，也不是每台設備都能直接停機。

有些設備可能是維持生產或服務的重要機台。一旦隔離或斷網，可能直接影響營運。遇到這種情況，就不能只從資安角度決定，而是需要把觀察到的異常與可能風險告訴客戶，再一起討論是否能隔離、是否先斷網，或是否有其他替代方式。

這也是我在 IR 現場感受到的困難之一：資安分析希望儘快控制風險，但現場營運不一定允許設備立刻中斷。

防火牆不只是資料來源，也可能是需要調查的設備

一般分析時，我們會把防火牆當成重要的 Log 來源，但在勒索事件中，防火牆本身也可能需要被檢查。

我碰過管理員帳號無法登入的情況，也看過少數防火牆底層遭到鎖住的狀況。至於設備是因為什麼原因無法操作、是否確實遭到入侵，以及哪些設定受到影響，仍需要由負責的人員進一步調查，不能只從「無法登入」就直接下結論。

在原本的防火牆是否仍可信任還沒有釐清以前，現場有時會先部署另一個品牌的防火牆，暫時維持基本的網路邊界防護，再調查原本的設備。

不過，更換品牌本身並不代表風險就會消失。新的防火牆仍需要正確設定，原本可能遭到濫用的帳號、對外服務與進入管道也需要繼續確認。這項處理比較像是先恢復一道可以運作的防護，再替後續調查爭取空間。

我會把哪些資訊提供給客戶？

當我從 SIEM 或其他資料中發現異常時，會盡量把客戶可以核對與採取行動的資訊整理出來，而不是只說「這台設備可能有問題」。

內容通常包含：

• 來源與目的 IP。
• 發生時間及頻率。
• 使用的 Port。
• 涉及的帳號與設備。
• 觸發的告警或行為。
• 能夠觀察到的執行程序。
• 防火牆顯示允許、阻擋或其他動作。
• 建議客戶進一步確認、隔離或斷網的方向。

這些資訊不一定能立刻拼出一條完整攻擊鏈，卻能讓其他 IR 成員及客戶知道目前掌握了什麼，並決定下一步應該由誰確認或處理。

IR 最困難的，往往不是找到一個可疑 IP

實際參與後，我覺得最困難的通常不是找到一個可疑外部 IP，而是現場有許多條件同時限制了調查與處置。

第一個問題是沒有可用備份。設備遭到加密後，如果缺少可以信任的備份，服務就很難快速恢復。

第二個問題是設備不能停機。即使出現可疑行為，也不一定能立即隔離。

第三個問題是設備用途不清楚。有時連客戶也無法立刻確認某台設備應該連到哪裡、使用哪些帳號，分析人員就很難快速區分正常活動與異常行為。

第四個問題是防護與紀錄不完整。不是所有設備都有 EDR，也不是每一台設備都留下足夠的事件紀錄。這會增加判斷難度，也可能讓尚未被排除的進入管道繼續存在。

因此，設備完成還原之後，仍需要一段時間持續監控。這不是因為每一筆異常都代表攻擊者仍在環境裡，而是我們不能只用「設備已經可以使用」作為事件結束的依據。

結語：恢復服務，只是 IR 的其中一步

在接觸這些事件以前，我可能也會直覺認為，把遭到加密的設備還原、讓服務重新運作，事情就差不多處理完了。

但實際參與 IR 後，我逐漸理解，還原只是其中一步。

設備重新連網後，帳號活動是否正常、內外部連線是否符合原本用途、防火牆是否仍可信任，以及目前取得的監控資料是否足夠，都是需要繼續確認的問題。

而我在團隊中負責的，就是透過 SIEM 與當下能取得的 Log，盡量把這些問題整理出來，再將觀察結果交給客戶及其他處理人員。

SIEM 不會替團隊完成整場 IR，也不能只靠一筆 Alert 證明攻擊者還在環境裡。但如果能在設備還原前先建立監控，並在重新連網後持續追蹤，它至少能讓我們在有限的資料中，更快找到值得深入調查的方向。

補充：國際上常見的正式事件應變流程

前面的內容是我在勒索事件 IR 中實際參與及了解的部分，並不是一套完整的國際標準流程。如果把視角拉高，國際上其實沒有一套適用於所有組織、所有事件的唯一作業順序，但有幾個經常被引用的正式框架，可以幫助組織建立自己的事件應變制度。

其中一個是 ISO/IEC 27035-1:2023。ISO 將資訊安全事件管理整理成一套結構化方法，涵蓋事前準備、偵測、通報、評估、回應，以及事後經驗回饋。這套標準提供的是原則與流程骨架，各組織仍要依規模、業務性質及風險調整，並不是拿來直接套用的單一操作手冊。

另一個常見參考是 NIST SP 800-61。NIST 在 2025 年發布 Rev. 3，並取代過去的 Rev. 2。新版不再只把 IR 看成事件發生後，由單一團隊執行的一段循環，而是把事件應變放進 NIST Cybersecurity Framework 2.0 的整體風險管理中。

依照 NIST SP 800-61 Rev. 3，可以用六個功能理解整體方向：

1. 治理（Govern）：建立事件應變政策、責任、決策權限及溝通方式。
2. 識別（Identify）：了解重要資產、設備用途、風險與相依關係。
3. 保護（Protect）：透過存取控制、備份、更新及其他防護措施降低事件影響。
4. 偵測（Detect）：發現並分析可能的攻擊、入侵或異常活動。
5. 回應（Respond）：針對已發現的事件進行管理、通報、控制及必要處置。
6. 復原（Recover）：恢復受到事件影響的資產與營運，並持續確認復原狀態。

這六項功能不是「第一步做完才能進入第二步」的固定直線流程。治理、識別與保護屬於長期準備；事件發生後，偵測、回應與復原可能交錯進行；從事件中得到的經驗，也應持續回饋到政策、防護、監控及後續改善。

這也能解釋為什麼 IR 不會只有一個人參與。NIST 特別指出，現代事件應變往往需要多個內部及外部角色共同完成，可能包括管理階層、事件處理人員、系統與網路工程師、外部資安服務團隊、法務、人力資源及公關等。每個人掌握的資料、權限與責任不同，需要透過清楚的分工及資訊交換，才能讓處理工作繼續往前。

如果把這套架構放到勒索事件，可以再整理成較容易理解的實務方向：

事前準備

• 盤點重要資產、設備用途與負責人。
• 建立事件通報、決策及聯絡流程。
• 準備與測試離線或分離保存的備份。
• 確認重要設備是否有足夠的 Log、EDR 與網路監控。
• 事先討論哪些設備能隔離、哪些設備停機會影響營運。

發現與分析

• 確認受影響的設備、帳號、時間範圍與服務。
• 保存並整理 SIEM、Firewall、EDR、Windows Event 及網路流量等資料。
• 區分已確認的事實、分析中的研判，以及目前仍缺少的證據。
• 評估事件是否仍在持續，以及影響範圍是否可能擴大。

控制與處置

• 依事件狀況隔離設備、限制帳號或阻擋惡意連線。
• 保留調查需要的證據，避免急著清除而失去事件線索。
• 檢查可能的進入管道、遭到利用的帳號與受影響設備。
• 如果設備不能直接停機，應由相關負責人共同評估風險與營運影響。

復原與持續監控

• 從經確認適合使用的備份或乾淨來源進行復原。
• 分階段讓系統恢復連線與服務，並觀察是否再次出現異常。
• 驗證帳號、網路連線、防火牆規則與端點狀態。
• 不能只以「設備已經可以使用」判定事件處理完成。

事後改善

• 回顧攻擊可能如何進入、哪些紀錄不足，以及哪些處置受到限制。
• 補強備份、權限、MFA、漏洞修補、網路分區及端點防護。
• 更新事件應變程序、聯絡資訊及人員分工。
• 將本次事件得到的經驗帶回監控規則、設備盤點與演練計畫。

英國國家網路安全中心（NCSC）的勒索軟體指引也特別提醒，備份不只要定期建立，還要與正式環境分離、實際測試能否還原，並在復原前檢查備份是否可能受到惡意程式影響。這與我在事件中看到的問題相呼應：真正困難的往往不是按下「還原」，而是能不能確認備份可信、重要設備能否中斷，以及設備重新連網後有沒有足夠的監控資料。

因此，如果要把這篇的經驗放回國際框架中，我負責的 SIEM 部署、告警分析、原始 Log 核對與資訊提供，主要落在「偵測」與「回應」；設備還原後的持續監控則連接到「復原」。但完整 IR 還包含事前治理、資產識別、防護、證據保存、營運決策、對外通報及事後改善，必須由不同角色共同完成。

參考資料

• NIST SP 800-61 Rev. 3：Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• ISO/IEC 27035-1:2023：Information security incident management — Principles and process
• 英國 NCSC：Mitigating malware and ransomware attacks