偵測與應變

為什麼從 10 月 17 日查起

Amazon 的蜜罐 MadPot 在 2026-10-17 就看到利用嘗試，比公開早四天。AWS 寫明不要假設公開日就是最早的利用日。修補發布當下（2026-10-21 14:00 UTC，台灣時間 22:00）基金會說還沒看到可運作的公開 exploit，但 AWS 稱當天 02:00 UTC（台灣時間 10:00）起已看到多份 PoC。不要用「公告當時說沒有」把查日誌延到下週。

註：蜜罐、PoC

蜜罐

Amazon 的蜜罐叫 MadPot，於 2026-10-17 看到利用嘗試，比公開早四天。蜜罐看到，和客戶機器上已經失守，是兩件不同的事。

PoC

Proof of concept。Calif 於 10 月 20 日約 20:00 UTC 誤發展示影片，副本仍在流傳。基金會在修補發布當下表示尚未看到可運作的公開 exploit；AWS 稱約 02:00 UTC 起已看到多份 PoC。

Wiz 與研究團隊都提醒：應用層的存取日誌可能幾乎是空的，因為路徑可以在應用程式碼之前就被碰到。記憶體外洩可能不執行任何惡意程式，所以只盯著「有沒有新的程式被跑起來」會漏看。

偵測訊號

研究團隊列出的調查訊號如下。它們和後面的行程、檔案訊號一樣，不能單獨證明被入侵；完全沒看到，也不代表沒事。不要把這些現象做成拿去對正式網站試的請求。

• 異常的 multipart 請求之後，緊接著 memory-limit 錯誤或連續的 HTTP 500。
  註：multipart

  multipart

  調查時可留意異常的 multipart 請求之後，緊接著 memory limit 錯誤或連續 HTTP 500。這只是調查訊號，不能單獨證明遭到利用，也不能拿來當測試請求。在網頁伺服器層擋掉這種格式會影響正常上傳與部分結帳。

• 回應裡出現異常巨大、或格式不像正常 session id 的 PHPSESSID cookie。
  註：session、PHPSESSID

  session

  伺服器端狀態，用來把一連串請求認成同一位訪客。這次與上傳進度、PHPSESSID 有關；應用程式沒有呼叫 session_start() 時，讀到行程記憶體這件事仍可能成立。

  PHPSESSID

  攜帶 session 識別資料的 cookie 名稱。研究者展示，異常的回應 cookie 可能把伺服器行程記憶體裡的敏感資料帶出去。偵測時可留意異常巨大、或格式不像正常 session id 的值。

• 無法解釋的 PHP worker 當掉或重啟。
  註：worker

  worker

  處理網頁請求的 PHP 行程。同一支 worker 接下一個請求時，可能在正常初始化把殘留狀態清掉之前就用到它。修補後要重啟所有 worker。

• PHP 相關父行程（php-fpm、php-cgi、php-cgi.exe、httpd、apache2）衍生出 sh、bash、cmd、powershell、python、perl、curl、wget、nc、certutil.exe 等子行程。
• 指令列出現 /dev/tcp、mkfifo。
• 網頁伺服器行程在執行 whoami、id、uname。
• 網站根目錄或上傳目錄新增 PHP 檔，或出現新的排程、新的系統帳號。

Huntress 說，RCE 得手之後最常見的樣子，就是 PHP 工作行程生出不該有的子行程。他們建議行程監控先用觀察模式，不要一上線就自動砍行程。

註：RCE

RCE

Remote code execution，遠端程式碼執行。未登入的呼叫者有機會讓伺服器執行他指定的指令。這次兩個 CVE 的官方後果都包含未授權 RCE；名稱裡的 shell 不代表每一個請求都必然走到那一步。

網路層：Corelight 公開了 Zeek 與 Suricata 的偵測規則，用途包含可疑的 HTTP 活動與從回應標頭辨識受影響版本，需要能檢查 HTTP 內容，請到其官方儲存庫取得。

日誌保全

• 先保留再處理：網頁伺服器日誌、PHP 與 PHP-FPM 日誌、系統行程紀錄、檔案的時間戳。
  註：PHP-FPM

  PHP-FPM

  以獨立行程池處理請求的常見跑法。基金會確認經應用層路徑可以 RCE。官方沒有把 PHP-FPM 寫成安全，只是沒有把它排在 mod_php 前面。

• 確認日誌輪替不會在調查期間把 10 月 17 日以後的紀錄刪掉；必要時先複製一份到別處。
• 對可疑檔案做人工確認，不要自動刪除。自動刪檔會毀證據，也可能刪到正常的快取。可以搭配檔案完整性比對。
• 懷疑失守的主機先不要重灌。

懷疑已經失守時

1. 隔離：把主機隔離，或至少從負載平衡拔掉，停止繼續對外提供有洞的服務。
2. 保全：照上一節保留日誌與檔案狀態。
3. 並行修補：同時修補其他還沒被隔離、仍暴露的系統，不要等鑑識做完。
4. 盤點：新的 PHP 檔、新帳號、新排程、異常的子行程。
5. 輪替祕密：密碼、API 金鑰、session 祕密與憑證。這次有讀取行程記憶體的路徑，沒有留下 webshell 不等於祕密還安全。
   註：webshell

   webshell

   攻擊者放在網站目錄的網頁程式，用來在得手之後維持存取。偵測時可留意網站根目錄或上傳目錄新增的 PHP 檔。沒有留下 webshell，不等於行程記憶體或設定裡的祕密仍然安全。

6. 通報：通知需要知道的人。台灣的機關與企業，資安署已透過資安警訊、N-ISAC、TWCERT/CC 通報，內部窗口依各單位規定。沒有把握時，找事件應變支援。

什麼時候可以結案

查不到異常不等於沒事，但調查要有終點。下面三種結果擇一。

基本調查範圍。 每一台在修補前對外、跑受影響版本的主機，時間從 2026-10-17 到修補並重啟完成為止：

• 網頁伺服器的存取與錯誤日誌、PHP 與 PHP-FPM 日誌（worker 異常結束、記憶體上限錯誤、連續 500）。
• 行程紀錄：PHP 相關行程有沒有衍生上面列的子行程（EDR、auditd 或同等紀錄）。
• 網站根目錄與上傳目錄裡新增或被改過的 PHP 檔，新的排程與系統帳號。

可以結案： 已修補並驗證是接流量的那一支；日誌涵蓋整段期間；上面範圍都查過，沒有訊號。記憶體外洩不一定留下痕跡，所以這類主機上的高價值祕密（資料庫密碼、API 金鑰、session 祕密）仍建議輪替。

證據不足： 日誌已經輪替掉、期間有缺口，或沒有行程紀錄。這時不能說「沒有被入侵」，只能說「無法排除」。照失守處理其中可以做的部分：輪替祕密、加強監控一段時間，必要時從乾淨來源重建。

交給事件應變人員： 看到子行程、新的 PHP 檔、新帳號或排程任何一項；主機上有個資或金流資料；或單位規定要通報。先照上面保全證據，不要自己清掉。