マルウェア感染で全削除されたサイトを復旧｜PHP8.3環境で16年前のMovable Typeを動かすまで【実例】

「マルウェアに感染したので、とりあえず全部消しました」
「バックアップはあるはずなのに、戻しても動きません」

このような状態からの復旧相談は、決して珍しくありません。
感染そのものより厄介なのは、慌てて行った対処が事態を悪化させてしまうことです。

消してしまったファイル、動かないバックアップ、誰も中身を把握していない古いシステム。
三重苦のような状態からでも、原因を順番に切り分ければサイトを戻せる可能性はあります。

この記事では、実際にお受けした案件を最初から最後まで追いかけます。
一つの原因を潰すたびに次の壁が現れる、復旧作業のリアルな進み方を見ていきましょう。

マルウェア感染で全削除されたサイト復旧の発端

今回の発端は、古いPHP環境で動いていたWordPressサイトのマルウェア感染でした。
問題は感染そのものだけでなく、感染後に担当者の方が一通りファイルを削除してしまったことです。

PHP5.6環境のWordPressが感染していた

ご相談時、対象サイトはPHP5.6という古い実行環境で動いていました。
サポートが終了したPHPや古いWordPressを使い続けると、既知の弱点を突かれやすくなります。

古い環境で感染が起きること自体は、復旧現場ではよくある話です。
ただし、感染に気づいた直後の対応を誤ると、復旧の難易度は一気に上がります。

感染ファイルも正常ファイルもまとめて削除されていた

ご相談をいただいた時点で、感染したファイルを含めて一通り削除された後でした。
感染したと聞けば、まず消したくなる気持ちはよく分かります。

しかし、感染調査では「何が残っているか」と同じくらい、
「どこがどう改ざんされていたか」という痕跡が重要です。

感染調査は、証拠が残っている状態でこそ意味を持ちます。削除してしまうと、復旧はできても「なぜ入られたのか」が分からなくなることがあります。

バックアップがあるのに戻らなかった

「バックアップはある」というお話でしたが、提供されたデータを戻してもサイトは動きませんでした。
ここで大切なのは、バックアップは取得時の環境とセットで初めて意味を持つという点です。

取得時と復元先でPHPのバージョン、データベース、サーバー設定、文字コードが違えば、
ファイルが残っていても正常に動作しないことがあります。

バックアップがある＝いつでも元に戻せる、ではありません。復元先の環境まで含めて確認する必要があります。

マルウェア感染サイトをPHP8.3環境で復旧する条件

今回の復旧条件は、古いPHP5.6環境へ戻さず、PHP8.3環境で動かすことでした。
安全性を考えると当然の判断ですが、古いプログラムほど新しい環境ではそのまま動きません。

元のPHP5.6へ戻すのは安全ではない

一番簡単に見える方法は、元のPHP5.6へ戻すことです。
しかし、それでは感染した時と同じ危険な状態へ戻すことになります。

サポートが終わった環境では、新たな弱点が見つかっても修正版が提供されません。
復旧できたように見えても、同じ事故がまた起こる可能性が残ります。

PHP8.3では古い書き方が動かないことがある

一方で、PHP5.6の時代に作られたプログラムは、PHP8.3ではそのまま動かないことがよくあります。
長い年月の間に、使えなくなった命令や、書き方が変わった部分が積み重なっているためです。

古い書き方のまま新しい環境に置くと、エラーが出るか、画面が真っ白になることがあります。
安全にするために新しくすると動かなくなる、というジレンマがここで生まれます。

まずWordPress側をPHP8.3で復旧した

残っていた素材と、動かなかったバックアップの中身を組み合わせ、
PHP8.3で動作するようにWordPress側を復旧させました。

ここで一区切りになるはずでした。
しかし、その後に同じサーバー内の古いMovable Typeも復旧してほしいという追加のご相談をいただきました。

Movable Type復旧で最初の見立てが変わった理由

Movable Typeの復旧では、最初の机上調査だけでは「PHP8では難しいかもしれない」という見立てでした。
しかし、ローカル環境で実際に動かしてみたことで、前提そのものが変わりました。

同じサーバーに16年前のMovable Typeが残っていた

Movable Typeは、WordPressが普及する前から使われていたホームページ管理ソフトです。
今回の環境には、約16年前のMovable Type 4.27が残っていました。

中には、2002年から2025年までの記事が約2,500件。
20年以上にわたって書き溜められた記録が入っていました。

フォルダ内のPHPファイルだけを見ると難しく見えた

初期調査では、古いシステム内にPHPで書かれたプログラム一式が見つかりました。
その中には、PHP8で廃止された書き方が大量に含まれていました。

これをすべてPHP8.3向けに書き換えるとなると、数万行規模になり現実的ではありません。
そのため、この時点では「そのままでは難しいかもしれない」という見立てになります。

実地検証でMovable Type本体はPerl/CGIだと確認した

ここで諦めず、手元の検証環境に同じシステムを再現し、実際に動かしてみました。
その結果、Movable Type本体はPHPではなくPerlという別の言語で動くことを確認できました。

つまり、最初に見えていたPHPの問題は、今回の運用方式では本体の停止原因ではありませんでした。
実際に動かして確かめなければ、「PHPファイルがあるからPHP8で動かない」と判断して終わっていた可能性があります。

復旧作業では、資料を読むだけでなく、同じ環境を作って実際に動かすことで結論が変わることがあります。

Movable TypeのInternal Server Errorを切り分けた手順

Movable Typeは動くはずだと分かっても、本番サーバーではInternal Server Errorが出続けました。
エラー画面は原因を教えてくれないため、可能性を一つずつ潰していきました。

エラー画面だけでは原因を特定できない

管理画面を開くと、白い画面に「Internal Server Error」と表示されるだけでした。
この表示は、CGIの権限、Perlの実行環境、モジュール不足、設定ミスなど、さまざまな原因で出ます。

最小のテストプログラムで原因の場所を絞った

決め手になったのは、Movable Typeとは無関係の、10行程度の小さなテストプログラムです。
同じ場所に置いて実行したところ、同じエラーになりました。

これで、Movable Type本体やデータベース処理が直接の原因ではないと分かります。
中身が何であれエラーになるなら、問題はもっと手前の実行環境にあります。

最終原因は実行権限のパーミッションだった

最終的な原因は、ファイルの権限設定から「実行の許可」が外れていたことでした。
プログラムは、読むことができても実行できなければ動きません。

サーバー会社の設備更新や移行作業の際に、こうした設定値が変わることがあります。
権限を戻したところ、管理画面は開き、記事も写真も20年分ほとんどが無事でした。

原因だけを見ると単純ですが、そこにたどり着くまでには、感染調査、バックアップ解析、WordPress復旧、Movable Type検証、本番環境の切り分けが必要でした。

マルウェア感染サイト復旧で原因が単純でも作業が簡単ではない理由

復旧後に原因だけを見ると「設定を直しただけ」に見えることがあります。
しかし実際には、間違った前提を一つずつ検証して捨てる工程に価値があります。

原因は、最後まで探し切って初めて単純に見えます。
途中の見立てで足を止めていれば、20年分の記録は失われていたかもしれません。

今回で言えば、「PHPファイルがあるからPHP8では無理」という判断で終わっていたら、
実際には動かせるMovable Type本体まで諦めることになっていました。

マルウェア感染サイト復旧後に行ったセキュリティ対応

サイトが動いた時点で作業を終えると、同じ事故がまた起こる可能性があります。
復旧後は、不要な入口を閉じ、古いシステムをどう扱うかまで判断する必要があります。

サポート終了したMovable Typeは修正版が出ない

今回のMovable Typeはサポートが終了しており、新しい弱点が見つかっても修正版は提供されません。
古いCMSは、復旧できたからといって安全に使い続けられるとは限らないのです。

実際に、この系統のバージョンでは、外部から不正に操作される恐れのある重大な弱点も公表されています。
そのため、使わないプログラムを止め、管理画面への入口を絞る対応が必要です。

不要なファイルと危険な入口を整理した

動作に不要なプログラムと、リスクの高いプログラムを特定して削除・停止しました。
ただし、不要に見えるファイルを片っ端から消すのは危険です。

最後の項目は特に注意が必要でした。
すでに使われていないファイルでも、外部から読める場所に残っていれば情報漏えいの入口になります。

管理画面のアクセス制限も行った

加えて、管理画面を決まった場所からしか開けないよう制限しました。
これだけで外部からの攻撃リスクは大きく下がります。

ただし、アクセス制限は古いCMSの脆弱性そのものを修正する方法ではありません。
あくまで攻撃される入口を減らす対策として考え、今後の移行や静的化も合わせて検討します。

復旧作業で再び全削除を繰り返してはいけません。1つずつ役割を確認したうえで、不要なものだけを整理します。

マルウェア感染サイト復旧後の運用判断

無事に動いても、古いシステムをそのまま使い続けるかどうかは別の判断です。
更新を続けるのか、記録として残すのかで、最適な対応は変わります。

更新を続けるならWordPressなど現行環境へ移行する

今後も記事を書き続けるのであれば、現在広く使われているWordPressなど、
セキュリティ更新が提供される環境への移行が現実的です。

過去の記事は移行対象にできますが、文字コード、画像、URL構造、独自テンプレートによって方法は変わります。
移行前に、件数・文字化け・リンク・添付ファイルを調査することが重要です。

記録として残すだけなら閲覧専用にする

もう更新しないが、記録として残したい場合は、閲覧専用の形に作り変える方法があります。
CMSの実行プログラムを外し、静的HTMLだけを配信するイメージです。

この形にすると、管理画面や投稿機能を攻撃されるリスクを大きく減らせます。
費用も移行より抑えられる場合があり、その後の保守負担も軽くなります。

今のまま放置するのが一番危険

サーバー環境は今後も更新され続けます。
今回のように、設備更新をきっかけに突然動かなくなることは実際に起こります。

余裕のあるうちに方針を決めておくことが、結果的に一番安く済みます。
動いているうちに、復旧・移行・保存のどれを選ぶか整理しておきましょう。

マルウェア感染とMovable Type復旧のよくある質問

感染後に削除してしまった場合でも、すぐに手遅れとは限りません。
よくある質問をまとめます。

感染に気づいて色々削除してしまいました。もう手遅れですか？

手遅れとは限りません。今回の事例も、一通り削除された後からのご依頼でした。すぐに操作を止め、何をどう消したかを分かる範囲でお知らせください。

バックアップがあるのに戻らないのはなぜですか？

バックアップは取得時の環境とセットで機能します。復元先のPHP、データベース、文字コード、サーバー設定が違うと、そのままでは動かないことがあります。

10年以上前のMovable Typeでも復旧できますか？

復旧できる可能性があります。今回の事例では、約16年前のMovable Type 4.27で、20年分・約2,500件の記事を確認できました。

制作会社と連絡が取れなくても依頼できますか？

問題ありません。サーバーやFTPの情報があれば調査できます。分からない場合も、契約されているサーバー会社から確認する方法を整理します。

古い環境のままにしておけば動き続けますか？

おすすめできません。サポートの終わった環境は弱点が修正されず、感染リスクが高い状態が続きます。サーバー会社の設備更新で突然動かなくなる可能性もあります。

調査だけをお願いすることはできますか？

承っています。中身が無事かどうかを確認したうえで、復旧するか、移行するか、記録として保存するかをご判断いただけます。

マルウェア感染で全削除されたサイトも原因を突き止めれば復旧できます

今回の案件は、マルウェア感染、全削除、動かないバックアップ、PHP8.3環境、古いMovable Typeという複数の問題が重なった事例でした。
それでも、原因を一つずつ切り分けることで、WordPressとMovable Typeの両方を復旧できました。

古いホームページのトラブルは、原因さえ突き止められれば直せることがほとんどです。
ただし、その「突き止める」ところに経験と手数が必要になります。

もし今、動かなくなったサイトを前に途方に暮れているのであれば、
何かを消してしまう前にご相談ください。

マルウェア感染後のホームページ復旧が自分で解決できない時は

ホームページの乗っ取り・マルウェア感染・古いCMSの復旧でお困りなら、
クイックレスキューが現物を確認して解決方法を探します。

古いからと諦める前にご相談ください。データを守るため、自己判断で操作する前のご連絡がおすすめです。