WordPress 入侵鑑識與根除流程

方法論

WordPress 入侵鑑識與根除流程

一套從「發現被駭」到「不再復發」的鑑識與清除流程。核心原則：清除是治標，找到並補掉根本入侵點才是治本；且要把攻擊者的多層持久化通道一次拆完，抓到一個就收手等於白做（[[縱深防禦]] 的反面應用）。

一、鑑識：把整條攻擊鏈攤開

鑑識的心法是 [[攻擊者思維稽核]] 的反向操作——不問「哪裡寫錯」，而問「駭客留了什麼能力給自己」。

  1. 確認落差：比對 curl 抓到的原始 HTML 與瀏覽器實際渲染的 DOM。原始碼乾淨、DOM 卻有動態注入的腳本，代表惡意程式靠 JavaScript 客戶端注入規避靜態掃描。
  2. 檔案鑑識：按最近修改時間排序 PHP 檔、檢查異常檔名與不屬於任何正常外掛的目錄。注意 mu-plugins/（強制載入且不出現在外掛清單）與偽裝成快取/工具外掛、會自我隱藏的注入外掛。
  3. 資料庫鑑識：用 WP-CLI 撈使用者清單（找惡意管理員、被拔角色的原站主帳號）、查 WP-Cron 排程與 transient（sc_cron_fetch、_transient_sc_payload_t 這類異常）、找集中在幾天內建立的垃圾文。
  4. 動態內容追蹤：追 JavaScript 動態注入來源、分析異常外部呼叫（如 Polygon RPC 的 eth_call）、監控應用程式密碼的非正常使用。
  5. 輔助工具：wp core verify-checksums（比對官方核心 checksums）、Sucuri SiteCheck、nginx 存取日誌分析。

二、清除：多道獨立防線一起拆（依序）

  1. 隔離備份：整站檔案與資料庫先完整備份到隔離目錄，保留證據、也留退路。
  2. 惡意檔案隔離：後門、注入外掛、黑帽 SEO 外掛先停用再搬移，每搬一批就驗證前台正常。
  3. 帳號清理：刪除惡意管理員、轉移其名下內容，恢復原擁有者帳號角色。
  4. 資料庫清潔：刪掉惡意排程、清掉混淆 payload transient、移除垃圾文。
  5. 核心驗證：wp core verify-checksums 逐檔比對，確認核心未被竄改。
  6. 憑證輪換：重洗 WordPress salts（登出所有 session）、清空登入 session、重設管理員密碼，連資料庫與 SSH 密碼一起換。
  7. 快取清理：清頁面快取（如 wp-rocket），再回瀏覽器確認 DOM 乾淨。

三、根除：盤點復發管道，補掉入侵點

清完隔天若又復發，代表還有獨立通道沒堵。至少檢查三類：

  • 後門副本：藏在非標準路徑、直接寫資料庫發文（post_author 為 NULL）的 PHP。用 nginx 日誌搜 ?action=create_post 這類自訂參數逮出請求。
  • 應用程式密碼：Application Passwords 獨立於登入密碼，改密碼撤銷不了，須到使用者設定的清單手動刪除，或直接關閉整個功能。
  • 根本漏洞：舊版外掛的 RCE 等入侵入口。不更新或移除，攻擊者就能無限重新上傳後門，前面所有清除都被繞過。

四、事後加固：把入侵成本墊高

  • 軟體管理：定期更新核心與外掛、不用 nulled 外掛主題、有漏洞又無法更新的外掛直接移除。
  • 帳號安全：定期盤點使用者與應用程式密碼，用不到就關閉整個功能。
  • 曝險面控制：關 XML-RPC、刪 readme.html、wp-config.php 加 define('DISALLOW_FILE_EDIT', true);。
  • 偵測與監控：檔案完整性監控（checksums 或版本控管）、定期 wp core verify-checksums、兩步驟驗證 + 高強度密碼。針對超出已知樣式的新手法（如 EtherHiding），靠正常基準線偵測而非只比對已知惡意樣式。

適用範圍與局限

  • 適用於可存取伺服器與資料庫、能操作 WP-CLI 與讀日誌的情境。純託管、無 shell 權限的站需靠主機商或安全外掛。
  • 若入侵點是弱密碼、供應鏈污染或主機商層級橫向感染，第三步的「補入侵點」定義隨之改變（強化認證／換乾淨來源／處理主機環境）。
  • 骨架可遷移到非 WordPress 的 CMS/網站入侵事件，差別只在檔案與資料庫的鑑識細節。

關聯概念

  • [[持久化攻擊]]
  • [[縱深防禦]]
  • [[攻擊者思維稽核]]
  • [[HMAC 驗證]]