前面幾天，我們已經完成：

• 建立 pqc_secret_keys.conf Honeyfile
• 使用 Wazuh FIM 監控檔案
• 啟用 realtime="yes" 即時監控

現在防線已經準備好了。

但設定完成不代表真的有效，所以今天要直接進行測試：

模擬攻擊者修改 PQC 誘餌檔案，看看 Wazuh 能不能抓到。

1. 攻擊前的 Honeyfile

目前我們建立的誘餌檔案位於：

/etc/pqc_secret_keys.conf

裡面放的是測試用的假資料，例如：

# PQC TLS Project - Master Keys
ALGORITHM=ML-KEM-768
PRIVATE_KEY=quantum_safe_key_99887766

這些內容並不是真正的金鑰，只是讓檔案看起來具有敏感性。

正常情況下，這個檔案不應該被隨意修改。

2. 模擬攻擊者竄改檔案

接下來假設攻擊者已經取得系統權限，並嘗試修改這個檔案。

我使用：

sudo sh -c 'echo "PRIVATE_KEY=hacked_by_attacker_0000" >> /etc/pqc_secret_keys.conf'

這個指令會把新的內容寫入檔案。

這裡只是模擬未授權竄改行為，目的是測試 Wazuh FIM 是否能夠成功偵測。

3. 確認檔案真的被修改

重新查看：

/etc/pqc_secret_keys.conf

可以看到原本的內容後面多出了：

PRIVATE_KEY=hacked_by_attacker_0000

結果變成：

# PQC TLS Project - Master Keys
ALGORITHM=ML-KEM-768
PRIVATE_KEY=quantum_safe_key_99887766
PRIVATE_KEY=hacked_by_attacker_0000

代表檔案內容確實已經發生變化。

接下來最重要的問題就是：

Wazuh 有沒有發現？

4. 回到 Wazuh Dashboard

回到 Wazuh Dashboard 查看 Security Events，可以看到 FIM 產生了新的事件。

在我的實驗中，可以看到：

Decoder：
syscheck_integrity_changed

Rule ID：
550

Rule Level：
7

規則描述顯示：

Integrity checksum changed.

也就是 Wazuh 發現：

檔案的完整性檢查值發生變化。

這代表前面設定的 Real-time FIM 已經成功偵測到這次檔案竄改。

5. 整個偵測流程

把這次實驗串起來，可以得到：

攻擊者修改檔案
       ↓
/etc/pqc_secret_keys.conf
       ↓
Linux 檔案事件
       ↓
Wazuh Agent / Syscheck
       ↓
偵測檔案完整性變化
       ↓
Wazuh Manager
       ↓
Rule 550
       ↓
FIM Alert

這也是這幾天從 Day 08 開始介紹 FIM 後，第一次把整個流程真正跑起來。

6. 但 Wazuh 到底發現了什麼？

目前我們只知道：

Wazuh 成功發現檔案被修改。

但仔細看 Dashboard 的完整事件內容，還可以看到一些更有意思的資訊，例如：

MD5
SHA1
SHA256
檔案大小
修改時間
inode

而且部分欄位還可以看到修改前與修改後的數值。

這代表 FIM 不只是告訴我們：

「檔案被改了」

還可以提供檔案完整性變化的資訊，協助後續調查。

這部分就留到下一篇繼續拆解。

今日總結

今天成功完成第一次 PQC Honeyfile 竄改測試。

整個結果可以簡化成：

Honeyfile
    ↓
模擬竄改
    ↓
Real-time FIM
    ↓
Rule 550
    ↓
Alert

這證明我們前面建立的 FIM 監控確實能偵測到 pqc_secret_keys.conf 的內容變化。

不過對資安事件來說，「知道檔案被修改」只是第一步。

真正進行事件調查時，我們還需要知道：

到底改了什麼？檔案修改前後有什麼差異？

下一篇就直接把今天產生的 Alert 拆開來看。

包含：

• MD5
• SHA1
• SHA256
• 檔案大小
• 修改時間
• Before / After

看看 Wazuh 到底留下了哪些可以用來進行事件調查的資訊。