當簽名偵測保持沉默 — sec-watch 調查案例

環境: 一家年營收約1,800億日圓的美妝企業，在 Web、應用與資料庫各層運行數百台伺服器，已配備帶託管簽名規則組的 WAF 和大規模內部安全監控體系。
挑戰: 簽名偵測只對已知載荷作出反應。2026年11月6日，單一外部來源執行了長達83分鐘的偵察活動 — OAuth 端點探測、利用外部回呼服務的 SSRF 嘗試、可實際運行的 XSS 載荷、同一毫秒內輪換十種 User-Agent、對路徑與查詢參數的金絲雀暴力試探，最後探測認證後區域（/login、/dashboard）。客戶 WAF 的託管簽名規則組（SQLi、Common、PHP、Known Bad Inputs）對此毫無反應。請求被攔下靠的是 IP 允許名單規則，而不是攻擊偵測。「看到」嘗試，與「知道」它是什麼、是否成功、觸及了什麼，並不是一回事。
AI 自動範圍: GIIP sec-watch（基於 Jev 的二次判定，涵蓋 WAF、CDN 與資料庫稽核日誌）在同一天的兩次掃描中，將該環境的30件可疑事件表面化。隨後，監控機器將全部判定與原始記錄 — WAF 日誌、CDN 日誌、DB 稽核日誌 — 逐條全文對照，重建了完整時間線，並將30件事件連同依據分為四組: 惡意活動21件（全部在 WAF 被攔截，未到達源站）；經允許名單內的正規客戶端路徑、對真實內容 ID 注入字元的手動測試7件（被放行並到達源站，返回 200/301，實施者未確認 — 未被靜默放過，而是作為「要注意」上報）；誤報2件（內部 CMS 正常操作、監控工具自身 IP 名單的既有誤登記 — 均附依據歸為正常）。報告按判定單位確定了調查範圍、攻擊模式、攻擊是否成功以及受影響對象，明確區分已確認事實與推測，並給出了具體後續建議（加入顯式拒絕名單、對被測試參數做伺服器端驗證、移除誤登記 IP）。
人工審核: 判斷與變更由人負責: 是否將來源加入顯式拒絕名單、是否向正規客戶端詢問其路徑上注入測試的經過、是否加入伺服器端驗證，都連同依據作為提案交給客戶團隊 — 報告止步於已確認事實與建議，不擅自更改生產安全策略。

成果

同一天內，客戶得到了全部30件事件的判定: 該活動未到達源站，也沒有資料提取的證據；2件誤報以正常操作結案；而唯一現實的風險路徑 — 簽名偵測之後空無一物的允許名單路徑 — 連同需要驗證的參數被明確指出。偵測負責提出事件，調查負責把事件變成判斷。

簽名偵測保持沉默。GIIP sec-watch 抓住了偵察活動，並證明入侵並未成功。

本案例採用的 GIIP 服務