企業官網遭遇條件式惡意跳轉：72 小時應變與排名復原流程手冊

企業官網遭遇條件式惡意跳轉：72 小時應變與排名復原流程手冊

首段（直接回答）：72 小時內以「保全證據 → 隔離服務 → 比對並全面清除 → 更換金鑰 → 提交搜尋引擎複查」為順序，可完成清除並送出複查，排名復原通常需數週到六週不等。

本文以決策導向與清單為主，讓資訊窗口或行銷負責人能照著做：每步都有判斷條件、具體指令或檢查點、以及常見例外處理。

一覽：72 小時決策樹（快速判斷）

  • 問題識別：行動裝置搜尋導入時發生跳轉，但桌機直接輸入網址正常？ → 疑似「條件式跳轉」，請進入本流程。
  • 第一個動作（若確認疑似入侵）：不要刪檔。立即備份（唯讀）並切到 503 維護模式。
  • 若備份最接近日期可能被汙染：往回找唯一確認乾淨的備份作為基準。
  • 清除順序：核心程式覆蓋 → 佈景/外掛處理 → 資料庫異常內容清理 → 更換金鑰與密碼 → 提交 Search Console 複查。

決策節點（簡要）：
1. 是否大量垃圾頁面被索引（>100）？ → 優先處理索引（410 與移除工具）。
2. 是否有近期新增管理員帳號或可疑排程？ → 強制移除、稽核並更換所有登入類密碼與金鑰。
3. 是否發現已知漏洞的外掛？ → 直接移除，不以僅「更新」為主（示例情境）。

第 0–1 小時：不要立刻刪檔，先保全證據與回應策略

關鍵決策：切勿因為要「看起來正常」就直接刪除檔案，因為刪除會喪失鑑識證據並可能遺漏後門。

具體步驟：
1. 接獲通報（示例時間：星期五 22:17）後的第一件事：完整備份檔案系統與資料庫，將備份設定為唯讀；備份檔名與時間戳須明確記錄。
2. 將網站回應改為 503（Service Unavailable）並加上 Retry-After 標頭，不要回 404 或直接關站。理由：503 能表明暫時性中斷，降低索引被移除的風險。
3. 設定維護模式時，同步啟用基本存取限制（IP 白名單或後台來源限制）以避免手動操作時遭二次入侵。

驗證清單（checkbox）：
– [ ] 已備份並標註為唯讀
– [ ] 已啟用 503 並添加 Retry-After
– [ ] 已限制後台存取來源

第 2–4 小時：範圍確認與初步鑑識

目標：確認被改動的範圍（哪些檔案、資料庫表、是否有新增管理員）並找到可能的入侵路徑。

步驟與方法：
– 檔案雜湊比對：以備份對官方原始版本逐檔比對雜湊值（SHA256 或 MD5），記錄被修改與新增的檔案清單。原始案例示例：核心程式檔發現 14 個檔案被修改，佈景主題下有 3 個非原始檔案。
– 資料庫檢查：檢視選項表（options）或關鍵內容表是否有新增或被改寫的紀錄。示例：發現 2 筆新增編碼跳轉腳本。
– 使用者帳號稽核：列出所有管理員帳號，檢查建立日期與 IP，如果發現近期（示例：9 天前）新增帳號，視為重要線索。
– 入侵路徑追溯：查找未更新的外掛或套件版本是否有已公開漏洞。示例：找到一個 14 個月沒更新的外掛，存在檔案上傳漏洞。

判斷與要點：
– 如果入侵在九天前發生但跳轉在第七天啟用，代表攻擊者先潛伏再啟動，所有在該期間內的備份可能已被汙染，不可直接還原。
– 若發現已知漏洞套件，往回找最近一個可驗證為「乾淨」的備份（原案例回到第 12 天的備份）。

第 5–10 小時：清除（優先順序與操作細節）

原則：先重建核心不可被替代的程式碼，再處理佈景與外掛，最後清理資料庫中的惡意紀錄。

步驟：
1. 核心檔案覆蓋：使用官方原始版本直接覆蓋，不做逐檔補丁。
2. 佈景與外掛處理：對有已知漏洞或長期停止維護的外掛直接移除，改以替代方案或重新評估功能實作方式；不要僅依賴「更新一次」作為唯一防護。
3. 資料庫清理：將被植入的跳轉腳本從選項表或文章內容中清除，並記錄被刪除的資料列 ID 與內容（供 Search Console 說明使用）。
4. 帳號處置：刪除惡意或不明管理員帳號，並強制所有既有使用者重設密碼。

驗證：完成後再次執行雜湊比對，確認與官方版本一致（示例完成時間：早上 07:50）。

注意：若網站功能高度客製或不易以官方檔案覆蓋，需列出差異檔案並以人工審核方式確認安全性。

第 11–14 小時：更換所有鑰匙與查漏

重點：清除檔案不代表攻擊者無法再進入；必須假設任一金鑰、密碼可能已外洩。

必換項目清單：
– 資料庫密碼
– 所有應用程式的驗證金鑰與鹽值（salt）
– 主機控制台（例如 cPanel/SSH）的密碼
– FTP / SFTP 帳號密碼
– 所有第三方 API 金鑰

附加檢查：
– 檢查與移除不明的排程任務（cron）或自動化腳本
– 啟用並強制兩步驟驗證（2FA）於後台管理帳號
– 將後台登入頁加入來源位址限制（例如僅允許公司 IP）

紀錄：把每一項更換動作與時間、執行者記錄下來作為複查證據。

第 15–20 小時：清除垃圾頁面並處理索引

情境說明：受感染的站點常見被植入大量垃圾頁面（示例：1,247 個外來網址），其中部分已被索引（示例：611 個）。

處理步驟：
1. 站內檢索：用 site: 與網站內搜尋指令列出非預期頁面並匯出清單。
2. 回應策略：對確定垃圾頁面回應 410（Gone）而非 404；410 告知搜尋引擎該頁永久刪除，通常比 404 更快被移除。
3. Search Console 暫時移除：使用移除工具先做暫時性隱藏，爭取時間做全面清除。
4. 重新提交 sitemap 並確保 robots.txt 未阻擋重要頁面。

驗證：持續監測索引數，並記錄每次提交移除或 410 的頁面清單。

第 21–40 小時：恢復上線前的完整檢查與向搜尋引擎報備

上線前檢查（必做 6 項）：
– 行動裝置與搜尋來源的跳轉測試（模擬三種情境：行動搜尋點入、桌機搜尋點入、直接輸入網址）
– 所有表單送出測試（包含郵件與通知）
– 金流、會員登入與關鍵交易流程測試
– SSL 憑證有效性與完整性
– robots.txt 與 sitemap 正確性檢查
– 全站 HTTP 回應碼掃描（找 4xx/5xx 與非預期的重導）

上線與複查申請：
1. 關閉維護模式（示例時點：星期六 19:10）並監測短期內的流量與錯誤記錄。
2. 向 Google Search Console 的安全性與人工判決報告提出複查要求。複查說明需分三段：發生了什麼、你怎麼處理的、你做了什麼防止再發生；每段都要具體列出檔案數、入侵路徑與防護清單（示例：列出被修改檔案數、清除方式及 9 項防護措施）。
3. 同時對重要頁面使用網址檢查工具要求重新檢索，並於 Bing 管理工具做相同動作。

提示：複查申請要附上可驗證的作法細節，不要僅寫泛泛的修復敘述。

第 41–72 小時：監測、等待複查結果與排名復原的觀察期

監測要點：
– 每 4 小時檢查檔案系統的異動；架設檔案完整性監控（FIM），一旦核心檔案被修改即刻通報。
– 追蹤 Search Console 的安全性警示與索引數變化；示例中警告解除耗時約 38 小時，垃圾頁索引從 611 降到 324。
– 持續監測主要關鍵字排名與自然流量，並記錄每週變化。

排名復原預期（示例數據，需依個案驗證）：
– 第 1 週：主要關鍵字平均排名從 3.2 掉到 11.7
– 第 2–3 週：開始回升，第三週回到 5.4
– 第 5–6 週：回到事件前水準（示例顯示第 6 週回復）
– 自然搜尋工作階段：事件當週下降 68%，第 6 週回到 97%

實務建議：在復原期間同步規劃付費廣告或搜索廣告承接關鍵流量以降低營收缺口。

事後必做的九項防護（優先順序與具體落實方式）

  1. 移除停止維護的外掛且建立每季一次的相依套件盤點流程（紀錄負責人與到期日）。
  2. 開啟核心程式與外掛的自動更新，並設定更新後的自動測試（例如 CI 流程簡易回歸）。
  3. 架設檔案完整性監控與異常登入通知（例：變更即通報 Slack/EMAIL）。
  4. 後台登入強制 2FA 與來源位址限制。
  5. 備份採異地保存、保留至少 30 天，並每月做一次還原演練。
  6. 加裝網站應用防火牆（WAF）並設定阻擋已知攻擊特徵。
  7. 補齊安全性標頭（Content-Security-Policy、X-Frame-Options、HSTS 等）。
  8. 管理員帳號數量控制（建議 ≤3）且定期稽核帳號活動。
  9. 將本 72 小時紀錄寫成內部文件，由資訊窗口保存並每年更新一次。

限制與例外說明（本文資料邊界）

  • 本文範例中提及的數字（如被修改檔案數 14、垃圾頁面數 1,247、已索引 611、排名復原節點等）皆來自原始個案描述，作為流程說明示例；實際情形會因 CMS、主機環境、備份政策與攻擊深度而異。
  • 部分成本與營收損失為示例估算（如技術處理費用新台幣 180,000 與機會成本估算約 4,600,000），在引用前需由站方以可驗證後台數據替換。
  • 若網站高度客製化或使用專有平台（非典型開源 CMS），某些步驟（如以官方版本覆蓋核心檔）需改為人工審核比對。

常見問答（FAQ）

Q1：能否直接還原最近的備份以快速恢復？
A1：不可直接還原最近備份，當入侵者能潛伏多日時，近期備份可能已被汙染。應往回找可驗證為乾淨的備份基準，或先比對雜湊確認備份是否含惡意程式碼。

Q2：何時向 Google 提交安全性複查？
A2：在完成清除、替換金鑰與至少一次完整雜湊驗證、確認垃圾頁面已回應 410 或已移除後才提交。複查說明要包含發生概況、處置細節與預防措施清單。

Q3：條件式跳轉要如何模擬測試？
A3：需模擬三種情境：行動裝置透過搜尋引擎點入、桌機透過搜尋引擎點入、直接在地址列輸入網址；三者都必須檢查跳轉是否還會發生。

Q4：排名多久能恢復？
A4：依案例示例，排名復原通常需 2–6 週不等；第一週常見顯著下滑，第三週開始回升，第六週可能回到事件前水準，但實際天數視流量結構與競爭環境而定。

下一步（內部連結）：若需要技術或流程協助，可參考我們的相關服務或預約諮詢：

附錄：本流程手冊適用對象快速檢核（若符合兩項以上，請採用本流程）
– 自有官網且有詢價、會員或金流功能
– 使用開源 CMS 且外掛數量多於 15 且未定期盤點
– 曾被搜尋標示為安全問題或擔心再次發生
– 多品牌或多國站管理、缺乏統一維運規範的團隊

結語：網站被植入條件式跳轉時，第一時間的證據保全與回應策略會直接決定後續排名復原耗時。依照本手冊順序執行，能在 72 小時內完成清除與複查送出，並把風險降到可管理的範圍。若需要外部協助，請在預約表單留下時段，我們會以該時段回電（首次通話不收費）。

延伸閱讀：

參考資源：Google 案例