前幾天完成了 Process Monitor、Process Rule，以及可以同時執行多條規則的 Detection Engine。

目前已經有兩條 Process Detection Rule：

• BG-PROC-001：Web Server Spawned Shell
• BG-PROC-002：Shell Spawned Network Tool

但做到這裡，我發現一個問題：

只看 Process 之間的關係，其實還不夠。

例如 BehaviorGuard 看到：

bash → curl

只能知道 Shell 啟動了 curl，卻不知道 curl 實際執行了什麼指令。

因此 Day 5 開始加入 Command Detection。

新增 Command Detection

今天建立了第一批 Command Rule。

BG-CMD-001：Download Piped to Shell

例如：

curl URL | bash

這個行為代表從網路取得內容後，直接交給 Shell 執行。

這不代表一定是攻擊，因為正常的軟體安裝也可能使用類似方式，但在端點監控中，這是一個值得進一步調查的行為。

因此建立：

BG-CMD-001
Download Piped to Shell
Severity：HIGH

BG-CMD-002：Python Inline Code Execution

另一個規則是偵測：

python3 -c ...

-c 可以讓 Python 直接執行 Command Line 中的程式碼，而不需要先建立 .py 檔案。

同樣地，這不代表一定是惡意行為，但可以作為一個 Detection Signal。

因此建立：

BG-CMD-002
Python Inline Code Execution
Severity：MEDIUM

Detection Engine 開始支援不同類型規則

目前 BehaviorGuard 的規則開始分成：

Process Rules

• BG-PROC-001
• BG-PROC-002

Command Rules

• BG-CMD-001
• BG-CMD-002

Detection Engine 會收到 Event，再將 Event 交給對應的 Rules 進行判斷。

簡化後的架構：

Endpoint Event
↓
Detection Engine
↓
Process Rules / Command Rules
↓
Rule Match
↓
Alert

把 Process Monitor 與 Detection Engine 接起來

今天最重要的改動，是把原本分開的 Process Monitor 與 Detection Engine 接在一起。

之前的測試方式是手動建立 Event，例如：

{"command": "python3 -c ..."}

再丟給 Detection Engine 測試。

這只能證明 Rule 本身可以運作，還不是真正在監控 Endpoint。

因此今天將 Process Monitor 從 Linux /proc 收集到的資料轉換成 Event，再送進 Detection Engine。

目前流程變成：

Linux /proc
↓
Process Monitor
↓
Process Event / Command Event
↓
Detection Engine
↓
Detection Rules
↓
Alert

真實 Process 測試

為了測試這條 Pipeline，我在 Kali 中建立：

zsh → nc

的 Process 關係。

BehaviorGuard 從 /proc 中取得真實 Process 資料後，Detection Engine 成功比對到：

BG-PROC-002
Shell Spawned Network Tool
Severity：MEDIUM

最後產生：

[ALERT] BG-PROC-002

Process：nc
Parent：zsh
Command：nc -l -p 9999

這次和之前最大的不同，是 Alert 不再只是來自手動建立的測試資料，而是來自 Kali 當下真正存在的 Process。

今天學到的資安觀念

1. Event 不等於 Alert

Event 是「電腦發生了什麼事情」。

例如：

zsh 啟動 nc

這是一個 Event。

當 Event 符合 Detection Rule 後，才會產生 Alert。

Event
↓
Detection Rule
↓
Match
↓
Alert

2. Sensor 與 Detection Engine 應該分開

原本我的 Process Monitor 裡面直接寫了偵測邏輯。

但這樣未來規則越來越多，程式會很難維護。

因此現在改成：

Process Monitor → 負責收集 Endpoint 資料

Detection Engine → 負責分析 Event

Detection Rules → 定義哪些行為值得注意

這讓之後新增規則時，不需要一直修改 Process Monitor。

3. Alert 不代表一定遭到攻擊

例如：

Shell → nc

或：

python3 -c ...

都可能出現在正常的管理或開發行為中。

Detection Rule 的目的不是看到某個行為就直接認定「這是攻擊」，而是找出值得進一步調查的行為。

這也讓我開始理解為什麼真實 SOC / EDR 環境需要處理 False Positive（誤報）的問題。

Day 5 成果

目前 BehaviorGuard 已經完成：

Process Monitor
↓
真實 Endpoint Event
↓
Detection Engine
↓
Process Rules + Command Rules
↓
Alert

今天第一次成功讓 BehaviorGuard 從 Kali 真實的 Process 資料觸發自己建立的 Detection Rule。

不過目前還有一個很大的限制：

BehaviorGuard 每次啟動只會掃描一次 /proc。

這比較像是「拍一張照片」，而不是真正的「監視器」。

如果某個 Process 很快就執行完畢，BehaviorGuard 很可能來不及看到它。

Day 6 將解決這個問題：

把 Snapshot Detection 改成 Continuous Monitoring（持續監控）。