從零開始使用Microsoft Sentinel實戰威脅狩獵的完整指南

# 使用Microsoft Sentinel進行威脅狩獵實戰

各位好！今天要帶大家實際操作如何運用Microsoft Sentinel執行威脅狩獵。這篇教學會比較詳細，因為我想把每個步驟都完整記錄下來。雖然不敢自稱是資安專家或威脅狩獵高手，但每天都在努力學習，也歡迎大家指正內容中的任何問題！

## 核心概念與環境建置
**威脅狩獵本質**：有別於傳統SIEM被動接收告警，主動式狩獵透過假設性攻擊情境，結合雲原生平台的AI分析能力（如Sentinel整合Log Analytics與機器學習），在攻擊者達成目標前找出潛伏威脅。

**主要技術組件**：
- Data Connectors負責匯入各類日誌
- 使用KQL查詢語言進行關聯分析
- Hunting Bookmarks標記可疑事件軌跡
- 所有偵測邏輯皆可對應MITRE ATT&CK戰術框架

## 實作內容大綱

**環境準備階段**
先在Azure建立具備RDP連線功能的虛擬機，這個VM將作為我們模擬攻擊的靶機。測試遠端連線功能時，記得檢查網路安全組設定是否正確。

**監控平台部署**
建立Log Analytics工作區後，接著部署Microsoft Sentinel實例並完成三方串接（VM、Sentinel、Log工作區）。特別注意數據收集規則的設定，確保安全事件日誌能正常流入。

**攻擊模擬與日誌驗證**
手動觸發數次失敗登入嘗試後，到Azure後台確認Event ID 4625（登入失敗）的紀錄是否確實被擷取。這個階段常遇到的問題是Windows事件轉發設定錯誤導致日誌遺漏。

**基礎狩獵技巧**
從可疑IP追查開始，逐步過濾出異常登入模式。這裡會示範如何用KQL語法快速找出短時間內重複嘗試的惡意IP位址，並比對公開威脅情資資料庫。

**進階防護機制**
將偵測邏輯轉化為自訂警示規則，當特定條件觸發時（例如同IP來源每小時失敗登入超過10次），自動產生工單並通知SOC團隊處理。

## 你能學到的實戰技能
透過這份指南，你將掌握：
- 在Azure環境故意製造安全事件來測試監控有效性
- 運用Sentinel內建Hunting模組追蹤橫向移動跡象
- 撰寫精準的KQL查詢揪出藏在海量日誌中的異常行為
- 建立自動化劇本加速事件回應流程

整篇教學會帶你從零開始打造實驗環境，包含那些技術文件沒寫清楚的實際踩坑經驗。不論是想了解現代SOC運作的新手，或是需要強化雲端監控能力的資安人員，都能從中找到值得參考的操作細節。

**實戰情境演練**：我們將模擬惡意登入嘗試、執行IP追蹤分析，並串聯線索來識別潛在攻擊模式。
**關鍵技能養成**：從建立Azure環境到進階自訂警示設定，本教學將帶你掌握事件應變與威脅偵測的核心能力。完成後，你就能實際運用這些技巧打造有效的威脅狩獵系統，並應用在真實資安調查中。

---

## **架設虛擬機實戰步驟**
我從註冊Azure免費試用開始，新帳戶會送相當於200美金的點數（約台幣6,000），完全夠用。這裡有個小訣竅：建議選擇B1s規格（1核CPU/1GB記憶體）的虛擬機，成本效益最佳，記得避開要額外收費的系統映像檔。

進入Azure入口網站後搜尋「Virtual Machine」，接著你會看到建立頁面。直接點選新增按鈕開始設定，過程中要注意幾個重點：區域建議選「東亞」降低延遲、記得關閉自動關機功能避免訓練中斷。

來到磁碟設定時直接點「下一步」跳過，網路配置頁面則要特別留意——點擊「進階」分頁後選擇「新建防火牆規則」，這裡我們會開放所有網路連線權限方便測試（正式環境千萬別這樣設！）。順帶提醒，事後務必檢查是否誤啟用付費監控告警功能，這可是新手超支的常見地雷。

在接下來的設定面板中，請先刪除預設的規則，然後新建一條規則。這裡我們會採用最高風險的設定值，確保虛擬機的紀錄檔能確實捕捉惡意活動。將目的端埠範圍設為星號（*）以允許所有通訊埠，並把優先級調整到100。最後點擊「檢閱」按鈕，就能開始建立你的虛擬機了！

接著要透過遠端桌面協定（RDP）連線到這台虛擬機。首先到資源清單裡找到目標虛擬機，複製它的公開IP位址。在你本機的Windows電腦上搜尋「遠端桌面」並開啟應用程式，輸入剛才記下的IP位址和當初建立虛擬機時設定的使用者名稱。

成功登入後，我們需要手動關閉幾項Windows防火牆設定來刻意製造系統漏洞。在遠端虛擬機的搜尋欄輸入「具有進階安全性的Windows Defender防火牆」並按下Enter。進入防火牆設定頁面後，你會看到不同分頁選項——逐一切換到這些分頁，把防火牆狀態全部設為「關閉」。

特別提醒：這種操作會讓SMB檔案共享和RDP等協定完全暴露在網路中，攻擊者很容易透過端口掃描發現這些開放服務。建議可以同步架設IIS網頁伺服器或模擬檔案共享環境，搭配弱密碼或未更新的漏洞補丁，這樣能更有效吸引惡意流量。監控時要注意抓取Windows安全事件ID 5157這類關鍵紀錄，Sentinel監控平台記得預先準備好對應的KQL查詢語法。當然啦，做這種實驗千萬記得要在隔離環境操作，結束後務必執行系統還原程序才不會違反資安規範喔！

## **測試與Azure虛擬機的連線狀態**
首先我們要從本地Windows主機執行基本的ping指令，確認能否連上那台Azure虛擬機——這步驟同時也驗證了攻擊者能否接觸到目標主機。打開PowerShell輸入

`ping `

，記得把換成你虛擬機的公開IP。看到系統回傳回應封包，就表示網路通道是暢通的。

## **檢查虛擬機是否正常記錄日誌**
故意登出遠端桌面後輸入錯誤認證（比如我用假帳號「Akash」），接著回到虛擬機開啟**事件檢視器**，切換到**安全性日誌**分頁。用關鍵字「Akash」篩選後，果然找到對應的登入失敗紀錄，詳細內容顯示系統確實捕捉到了錯誤密碼嘗試。（補充：這種NTLM驗證失敗事件在非網域環境中特別容易觸發，和企業內網常見的4625事件不同）

## **建立Log Analytics工作區**
這個空間專門用來集中管理虛擬機吐出的日誌。進到Azure入口網站搜尋**Log Analytics**服務點擊建立，照著畫面指示填完基本設定再按下部署按鈕就搞定了。建議順手調整Windows的稽核原則，把失敗事件層級調高些方便後續追蹤，未來還能結合IP地理資料做進階威脅分析。

## **建立Sentinel SIEM監控平台**

首先在Azure入口網站搜尋**Sentinel**，直接按下Enter進入服務頁面。點選**建立Microsoft Sentinel**按鈕後，系統會要求你選擇先前建好的**Log Analytics工作區**，確認選取後按下**新增**就能完成基礎部署。

## **串接虛擬機器、Sentinel與工作區日誌**

這個步驟的關鍵在於確保虛擬機器的安全日誌能正確流入分析平台。實際操作時，先在Azure入口網站搜尋**Sentinel**服務，接著導覽至**內容管理 > 內容中樞**，用搜尋欄查找「Security Event」相關模組。找到標示為**Windows Security Event**的項目後，點擊右側面板的**安裝**按鈕進行部署。

接著回到內容中樞介面，這次改搜尋「Windows Security Events」並從右側選單選擇**管理**功能。在跳轉頁面中找到採用AMA傳輸機制的版本（通常標註為*Windows Security Events via AMA*），點擊右側的開啟連接器按鈕。最後別忘了建立對應的資料收集規則——這就像是設定一條專用管道，讓終端裝置的安全事件能透過代理程式穩定傳送到雲端工作區。

[補充細節]
- **底層運作原理**: 這裡其實是透過Azure Monitoring Agent(AMA)即時抓取Windows安全日誌，原始資料會先經過正規化處理才存入Log Analytics。要注意的是像4624(登入成功)這類重要事件ID預設就會被標記時間戳記(_TimeGenerated)和來源識別碼(_ResourceId)。
- **常見地雷**: 某些舊版系統的日誌格式可能造成欄位映射錯誤，建議先用KQL寫個parser函數預處理；另外記得去「定價層」設定調整每日資料上限，不然流量爆表時帳單會很精彩...

## **確認日誌是否成功匯入Azure環境**
首先登入**portal.azure.com**，搜尋並進入**Log Workspaces**後選擇你的日誌工作區。接著點選**Logs**功能，記得將檢視模式從簡易版切換成**KQL模式**(Kusto查詢語言)。在這個模式下直接輸入**SecurityEvent**指令，就能查詢到已匯入的Windows安全事件紀錄，所有透過連線器收集的登入稽核資料都會顯示在這裡。

## **刻意使用假帳號測試登入記錄**
為了驗證系統是否能正確捕捉異常登入行為，我特別在遠端桌面連線時輸入了根本不存在的使用者名稱「ThisIsFAKE」。操作完成後再回到Azure入口網站檢查日誌，果然能看到這些錯誤嘗試的詳細紀錄，包含失敗的時間戳記與使用的無效憑證等資訊。

（補充說明：實際部署時建議注意Windows版本相容性，例如Server 2016以上系統才能完整支援安全事件收集。若需要精簡資料量，可透過自訂篩選條件只抓取高風險事件ID如4688程序建立或5140檔案共享存取等，這能有效降低儲存成本。）

登入嘗試後，我進到Azure入口網站的**記錄**區塊，想確認這個事件有沒有被正確記錄下來。系統記錄的欄位很多，不過只要用KQL查詢語言下個指令，就能篩出我們真正需要的資訊。

我特別用這個帳號「AzureAD\ThisIsFAKE」來查——沒錯，這是我故意輸錯的假帳號。指令長這樣：
`SecurityEvent | where Account == "AzureAD\\ThisIsFAKE" | project TimeGenerated, Account, EventID, IpAddress`

查到IP位址後順手做了個定位追蹤，上[whatismyipaddress.com/ip-lookup]網站輸入紀錄裡的IP，果然顯示位置在密蘇里州（我人就在這），這招用來確認登入來源地超方便，萬一冒出個陌生IP也能馬上警覺。

### 關於那些登入失敗紀錄
後來我又用KQL撈了事件ID 4625的資料（專門記登入失敗的），結果發現有個IP一直用「Administrator」這組帳號狂試。最扯的是查出來IP居然在巴西！這種跨國攻擊模式很常見——駭客會用固定帳號名短時間密集嘗試，有時候失敗幾十次後突然成功突破。建議查的時候可以加時間範圍過濾，像這樣：
`| where TimeGenerated > ago(7d)`
要是看到同個IP在不同國家跳來跳去，或是Guest帳戶異常活動（比如`AccountType == "Guest"`突然大量出現），八成就是有問題了。

## **建立自訂警示規則**
這次我要在Azure Monitor設定一個自訂警示，專門用來偵測失敗登入事件，主要監控的是Windows事件ID 4625。首先打開portal.azure.com，搜尋「Azure Monitor」

接著點選建立下拉選單，選擇「警示」功能，然後切換到「自訂記錄搜尋」的頁籤。這裡有幾個進階設定可以調整，像是警示名稱和觸發閾值之類的，都能依照需求客製化。我把這個警示命名為「登入失敗嘗試」。

故意在自己的遠端桌面試了幾次錯誤登入後，果然在Azure Monitor看到警示被觸發了。讓虛擬機運作一整天之後再檢查，發現多了不少來自隨機攻擊者的失敗登入警報，數量明顯比測試時多很多。

## **實戰演練：威脅狩獵查詢技巧**
**情境一：偵測失敗登入的查詢語法**

SecurityEvent  

| where EventID == 4625  

| where AccountType == "User"  

| project TimeGenerated, Account, EventID, Activity, IpAddress, IpPort, TargetAccount  

| order by TimeGenerated desc  

**解說重點：**
1. **SecurityEvent資料表**：這是存放Windows安全紀錄的資料集，包含登入嘗試、帳戶活動等安全性事件。實際運用時可以搭配地理圍欄功能（比如過濾巴西IP段），或是加入威脅情資比對（像TOR出口節點或已知惡意IP清單）來提升準確度。

2. **篩選邏輯**：除了基本的事件ID過濾外，建議可加上時間範圍限制（如最近24小時）和頻率閾值（例如每分鐘超過5次失敗就觸發），這樣能有效減少誤報。如果要更直觀呈現結果，可以在儀表板加上地圖視覺化元件標註異常IP的分佈位置。

這段KQL查詢語句主要用於分析Windows安全事件日誌中的登入失敗記錄，讓我們一步步拆解它的運作邏輯：

首先透過「where EventID == 4625」這個條件篩選器，專門鎖定登入失敗的事件記錄。在Windows系統中，這個特定的事件編號就像個警示燈，每當有人嘗試登入卻失敗時就會觸發，對於揪出可疑的未授權存取行為特別有用。

接著用「where AccountType == "User"」進一步過濾，把範圍縮小到真人使用者的帳戶類型。這樣做有個好處——可以自動排除那些機器帳號、服務帳號或系統帳戶產生的雜訊，讓我們專注在真正需要關注的人為登入活動上。

查詢中「project」指令就像個精準的探照燈，只提取我們最關心的幾個關鍵欄位：事件發生的確切時間戳記（TimeGenerated）、嘗試登入的使用者帳號（Account）、固定為4625的事件編號（EventID）、記錄的活動類型描述（Activity）、來源IP位置（IpAddress）、連接埠號碼（IpPort），以及被當作登入目標的帳戶名稱（TargetAccount）。這些資訊組合起來，基本上就能勾勒出一次失敗登入嘗試的全貌。

最後用「order by TimeGenerated desc」把結果按照時間降冪排列，這招相當實用——讓最新鮮熱辣的登入失敗記錄自動排在最前面。想像一下當你在調查資安事件時，這種排序方式能讓你一眼就抓到最近發生的異常活動，不用再手動翻找時間軸。

簡單來說，這組查詢就像個智能篝火台，從海量的安全日誌裡篩選出所有失敗的使用者登入紀錄。它不僅告訴你「什麼時候」、「誰」試圖登入失敗，還會透露「從哪裡來的」（包括IP位址和通訊埠），以及「想登入哪個帳號」。所有資訊都按發生時間倒序排列呈現，讓監控人員能立即掌握最新的可疑登入動態。

## 在真實事件應變情境中運用查詢指令

這段KQL查詢語法：
`SecurityEvent | where Account == "AzureAD\\ThisIsFAKE" | project TimeGenerated, Account, EventID, IpAddress`

在資安事件調查時特別管用，它能幫我們做到幾件事：首先揪出那些可疑的登入失敗紀錄，比如突然冒出來的假帳號「ThisIsFAKE」；再來是追蹤攻擊來源IP，把這些位置資訊丟到情資平台交叉比對，說不定能挖出背後的操作集團。當看到大量出現的4625事件代碼（登入失敗）時，這通常就是暴力破解的前兆了。

更聰明的方法是透過Azure Monitor設定自動化警報，只要偵測到類似模式就立刻發通知。這種主動出擊的做法，往往能在駭客真正得手前就截斷攻擊鏈。

## 實戰重點回顧

這次我們從頭演練了如何用Microsoft Sentinel打造威脅狩獵防線——先在Azure上架設有弱點的測試機，接著配置日誌收集管道，最後用KQL寫進階查詢來抓異常行為。刻意模擬的失敗登入紀錄就像誘餌，讓我們實際觀察安全事件怎麼被記錄下來。

學到的技巧都很接地氣：像是訂製告警規則的眉角、解讀日誌的小訣竅，這些都是現代資安團隊每天在用的真功夫。無論你是剛接觸威脅狩獵的新手，還是想精進偵測技術的老鳥，這套方法都能幫你建立紮實的基礎。畢竟在資安這行，永遠得多想一步、快人一拍才守得住防線。