WordPress 資料庫後門清查:假帳號、應用程式密碼、惡意排程一次找出來

這篇需要 SSH 操作

這篇文章的操作需要透過 SSH 連進伺服器執行。還不熟悉 SSH?請先看SSH 連線教學。

檔案層掃完了,但別以為這樣就結束。

很多人清完惡意 PHP、重裝了核心,過幾天又被打進來。原因是攻擊者在資料庫裡也留了後手。

假管理員帳號、應用程式密碼、惡意排程任務、自動載入的 mu-plugin——這些用檔案掃描完全找不到,一定要另外查。


檢查管理員帳號

SSH 進伺服器後,用 WP-CLI 列出所有管理員:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered --allow-root

拿到清單後,逐一確認每個帳號是不是你認識的。以下特徵幾乎可以確定是攻擊者建立的:

  • Email 是 @security.local、@local.invalid、@wordpress.org 這種假的。
  • 帳號名叫 admin、root、webshell、maintenance、bot。
  • 建立日期集中在近期,而且不是你建的。
  • Email 欄位是空的。

檢查應用程式密碼

這是很多人不知道的持久化管道。WordPress 5.6 開始內建「應用程式密碼」,讓外部程式可以透過 REST API 操作網站。

應用程式密碼的可怕之處

  • 它跟登入密碼是完全獨立的。你改了登入密碼,應用程式密碼不受影響。
  • 攻擊者可以用它透過 REST API 做任何管理員能做的事——建文章、改設定、裝外掛。
  • 在後台的「使用者 → 個人資料」頁面才看得到,平常不會去檢查。

用這個指令查有沒有人建了應用程式密碼:

wp db query "SELECT user_id, meta_value FROM wp_usermeta WHERE meta_key = '_application_passwords'" --allow-root

有結果就代表有人建了應用程式密碼。確認 user_id 是哪個帳號的。是你自己建的就沒事;如果不是、或你根本不知道有這個功能,就要清掉。


檢查 WP-Cron 排程任務

WordPress 的 Cron 系統可以排程執行 PHP 函數。攻擊者會在這裡塞一個定時任務,每隔幾小時從外部下載新的惡意程式碼。你清完檔案,它過幾小時又自動回來。

wp cron event list --allow-root

正常的排程項目會有你認識的 hook 名稱,像 wp_update_plugins、wp_scheduled_delete、woocommerce_cleanup_sessions。

可疑的長這樣:sc_cron_fetch、隨機命名的 hook(一串亂數)、或名字不屬於任何你裝的外掛。


檢查 mu-plugins 目錄

mu-plugins(must-use plugins)是 WordPress 的一個特殊目錄:放在裡面的 PHP 檔案會自動載入執行,不需要在後台啟用,也不會出現在外掛列表裡。攻擊者非常喜歡用它來放 runtime 後門。

ls -la /home/runcloud/webapps/SITENAME/wp-content/mu-plugins/ 2>/dev/null

正常情況下這個目錄可能不存在,或只有主機商放的東西(RunCloud 會放一個 runcloud-hub.php)。看到不認識的檔案,像 easypost-runtime.php,用 cat 看內容。


檢查 wp-content 根目錄

另一個容易被忽略的藏匿點是 wp-content/ 根目錄本身(不是子目錄):

find /home/runcloud/webapps/SITENAME/wp-content/ -maxdepth 1 -name "*.php" ! -name "index.php"

這裡正常會出現的有 advanced-cache.php(WP Rocket 或快取外掛產生的)、object-cache.php(Redis / Memcached 的 drop-in)。看到 click.php、shadow-bot.php 這種名字,基本上就是惡意的。


幾個容易踩的坑

改密碼不等於安全

很多人第一反應是趕快改密碼。密碼當然要改,但如果攻擊者已經建了應用程式密碼,改登入密碼完全沒用。他透過 REST API 照樣進出自如。

密碼、應用程式密碼、session salt,三個要一起處理。

mu-plugins 是最容易被忽略的

大部分人掃毒只掃 wp-content/plugins/ 和 wp-content/themes/,根本不知道 mu-plugins 這個目錄存在。攻擊者深知這一點。你在後台的外掛列表裡完全看不到它,但它每次載入頁面都會跑。

排程任務清完要洗 salt

清完 Cron 排程之後,記得跑 wp config shuffle-salts 重洗 salt。這會讓所有現有的 session 立刻失效,包括攻擊者可能還持有的登入 session。詳細步驟後面的加固篇會講。

貼給你的 AI 用

要檢查資料庫有沒有被動手腳?把下面這段貼給 ChatGPT 或 Claude:

我的 WordPress 可能被駭了,需要檢查資料庫有沒有被植入後門。我已經 SSH 進伺服器了。

我的環境:
- 網站路徑:[填入]
- WP-CLI 可用:是/否

請引導我檢查以下項目,每一步等我貼回結果再繼續:
1. 列出所有管理員帳號,幫我判斷哪些是可疑的
2. 檢查有沒有人建了應用程式密碼(Application Passwords)
3. 列出 WP-Cron 排程任務,幫我判斷哪些不正常
4. 檢查 mu-plugins 目錄有沒有不認識的檔案
5. 檢查 wp-content 根目錄有沒有可疑 PHP

SSH 操作注意事項

SSH 指令送出去就是送出去了,沒有 Ctrl+Z。操作前請注意:

  • AI 給的指令,跑之前自己看一遍,確認路徑和檔名是對的再按 Enter。
  • 不要整段複製貼上一口氣跑完。一次一個指令,看到結果再下一步。
  • 刪除和覆蓋操作不可逆。備份沒做完之前,不要動任何清除步驟。
  • 不確定的時候就停下來問。問 AI、問主機商、問會的朋友,都比直接跑好。

SSH 基礎教學請看這篇。

搞不定?讓專人處理

WP 中毒救援 $5,500 起 | 外掛衝突排查含版面復原 $4,000 起

了解服務方案 →

文章分享