Webサイトのお助け隊

「漏えいしたかもしれない」という言葉が社内で出た時点から、作業の性質が変わります。サイトを元に戻すことよりも先に、いつ入られたのか、どこから入られたのか、何がどこまで持ち出されたのかを確定させないといけません。この3つが決まらないと、再公開の判断も、誰に何を知らせるかの判断も止まります。そして確定の作業は、そのときサーバーに記録が残っているかどうかで、結果がほぼ決まってしまいます。2026年6月1日から10月8日までに公表・報道された日本の組織の漏えい事案を集計した調査資料を読むと、その現実が件数として表れています。

176件のうち60件は、原因の欄が埋まらなかった

集計の母数は、公式発表が確認できたもの114件と、報道のみで公式が未確認のもの62件、合わせて176件です。対象期間は2026年6月1日から10月8日まで。月ごとの内訳は6月が39件、7月が31件、8月が36件、9月が42件、10月は8日までで28件でした。

この176件を原因で1件ずつ分類すると、最も多い区分が「原因不明」の60件、全体の34%です。人的ミスが28件、認証情報の窃取やアカウント乗っ取りが27件、脆弱性の悪用が25件、委託先やサプライチェーン経由が16件、ランサムウェアが13件。つまり、3件に1件は「何が起点だったのか」が公表文や報道から読み取れないまま記録されています。種別で数えても、いちばん多いのは「不正アクセス（経路非公表）」の73件でした。

件数についても似た状態です。漏えいした件数が判明しているのは109件で、非公表または不明が67件あります。100万件以上の公表が16件、10万件以上が37件という規模の事案が並ぶ一方で、規模を数字で出せていない事案がこれだけ残っているということです。

なお、この集計は公開情報だけを積み上げた資料で、網羅性には限界があります。自治体や学校の誤送信のような小規模な人的ミスは拾いきれていない可能性があり、攻撃者側の主張だけに基づく未確認情報は集計から外してあります。以下で触れる事案も、公表文と報道に書かれている範囲にとどめます。

「非公表」「調査中」「未報道」は、同じ不明ではない

原因不明60件の内訳は、非公表が35件、調査中が16件、未報道が9件です。ひとまとめに見えますが、組織の内側で起きていることは三者で違います。

調査中というのは、公表の時点で経路が決まっていないという状態です。航空貨物の運送サービスでは、第3報の時点でも侵入経路は調査中と公表されていました。非公表は、調べた結果を外に書いていない状態で、こちらは書けない理由がある場合も含みます。未報道は、公式発表が見つからず報道にも原因の記載がない、つまり外から判断する材料がない状態です。

もうひとつ、混ざりやすいものを分けておきます。「経路が分からない」と「時期が分からない」は別の話です。あるメーカー系の通販サイトでは、旧いECシステムのサーバーに侵入されていた期間が5月21日から8月1日までと示されていますが、侵入の経路は非公表とされています。期間が出せているのは、その範囲を示す記録が残っていたからです。

逆に、記録があっても判明までに時間がかかる場合があります。あるメディア系の会社では、サーバーへの不正アクセスを確認したのが4月28日で、漏えいの可能性が判明したのは6月19日でした。確認から約2か月あいています。調査報告書には、ログが削除されていたため経路を特定できなかったとされる事案も記載されています。消えた記録は、後から作れません。

侵入経路を決めるのは、どの記録か

確定させたい事項と、その根拠になる記録を対にすると、何が足りないと何が言えなくなるのかがはっきりします。

共用のレンタルサーバーでは、アクセスログの保存期間が事業者ごとに違い、数日分しか遡れないこともあります。管理画面からダウンロードできる形で置かれていることもあれば、申請しないと出てこないこともある。侵入に気づいた日に最初にやる作業は、原因の推測ではなく、今あるログの範囲を確認して手元に落とすことです。調査の途中でログが切り捨てられると、そこから先は推測しか書けなくなります。エラーログを読む手順そのものはWordPressの不具合をログから特定する、エラーログの見方と手順に分けて書いています。

19サイトが同時に書き換えられていたとき、最初に作ったのは一覧表だった

ここから当社が実際に対応した側の話です。1つの共用ホスティングアカウントの配下に19サイト以上が同居していて、その全部に同時に不正ファイルが置かれていた案件がありました。相談の入口は1サイトの表示不具合でしたが、調査の単位をアカウント全体に広げないと意味がない構成でした。1サイトだけ駆除しても、隣のサイトから戻ってくるからです。

この手の不正ファイルは名前に型があります。正規の wp-plugins に綴りを似せた wp-pluggins.php、それに mini.php、wp-charm.php、Me_Guard.php、dude.php。「wp-」で始まる紛らわしい名前と、サイトの内容と無関係な短い英単語のファイルが疑わしい対象でした。検出結果はドメインごとの一覧ファイルにまとめて渡しました。どのドメインに何が置かれていたかを並べないと、作業範囲も残存リスクも共有できません。

この案件で印象に残っているのは、制作前・準備中でまだ公開していなかったドメインまで対象になっていたことです。「まだ公開していないから安全」は成り立ちません。サーバーに置いてある時点で外から到達できる状態になっています。復旧のあとは、同じアカウントに全部を同居させる構成そのものを見直して、サーバーの移設と環境の分離まで続けました。

反省点も残しています。この案件はやり取りの記録がほとんど残らず、後から「どの範囲を対象にして、何をして、どうなったか」を復元できませんでした。対象範囲・実施内容・結果の3行だけでも残しておくと、次に同じ症状が出たときの調査時間が変わります。

.htaccess を全階層たどるまで、DNSの不調に見えていた

別の案件は、相談文が「サイトが表示されない」の一行でした。確認すると index.php のパーミッションが足りていない。それだけに見えたのですが、ディレクトリを全部たどると、ファイルの汚染とパーミッションの改変がセットで行われていました。管理者が自分で直せない状態を作るところまでが一連の作業になっているわけです。

やりにくかったのは .htaccess でした。ルートだけでなく各階層に置かれていて、リダイレクトとアクセス拒否が仕込まれている。結果として「ログインページに辿り着けない」という症状になり、最初はDNSや名前解決の不調に見えていました。実体は各階層の .htaccess です。この症状の見分け方は見覚えのないページや転送が増えたとき、改ざんを見つける調べ方に整理しています。

この案件で時間を失ったのは調査そのものではありません。渡されたFTPアカウントに書き込みとパーミッション変更の権限がなく、初動が1日以上止まりました。記録を見に行く前の段階で止まるのが、実務でいちばん多い時間の使い方です。着手前に、FTPでファイルの書き込みとパーミッション変更ができるか、サーバー管理画面に入れるか、この2つだけは確認しておくと動き出しが変わります。

この案件は部分復旧で終えました。依頼の目的が「中身を見て別のサーバーへ移したい」だったためで、どのプラグインの脆弱性や認証情報の漏れが起点だったのかは特定していません。そのまま再公開すれば再感染する状態であることを書面に残して終了しています。納品は予定より5日後ろにずれました。調査量が読めない案件で納期を先に固定すると、こうなります。

エラーログに /mt/xfile/ が残っていた側の話

記録があった側の例も挙げます。2サイトの移行案件で、CMSが Movable Type の 5.2 という古い版でした。移行直後に見覚えのない index.php が出てきて、エラーログを見ると /mt/xfile/ というディレクトリと wso.php へのアクセスが残っていました。加えて不審なPOSTアクセスの痕跡。この3点で、何が置かれていてどう使われていたかが見えました。フィッシングサイトの踏み台にされていた状態です。

対処は段階的に裏切られました。index.php を削除すると xfile ディレクトリが見つかり、それを消すとディレクトリ名を変えて再び置かれる。バックドアが複数ある前提で動かないと、何度でも戻ってきます。最終的に、サーバーの移行、パスワードの全変更、SSHの停止、CMSを8系へ上げるところまでを一括で実施しました。なお、ホスティング事業者に確認したときの回答は「新しいサーバーへの移行は速度の改善であって、セキュリティの強化ではない」でした。移すだけでは、旧版CMSという根本が残ります。

記録が揃っていると調査は一気に短くなります。障害が起きると自動で通知メールが届く構成のサイト群では、通知の本文に該当ファイルと行番号が入っているため、それを最初に共有してもらうだけで切り分けが数十分で終わる案件もありました。白画面や500エラーの場合は、エラーログ、PHPのバージョン、プラグインの最終更新日の3つを突き合わせれば大半は特定できます。ログに出るのはプラグインの内部ディレクトリ名なので、js_composer と「WPBakery Visual Composer」のように、管理画面の表示名と対応づけて読む必要があります。

次に同じ連絡が来たとき、何分で動けるか

事故が起きてから揃える情報と、先に持っておける情報は分けられます。後者は手間の割に効きます。

• 書き込みとパーミッション変更ができるFTPアカウント、サーバー管理画面のログイン手段
• アクセスログとエラーログがどこにあり、何日分残るか（事業者の仕様を一度確認しておく）
• 障害の通知メールが誰に届くか。届いた本文を捨てずに保存する運用
• 同じホスティングアカウントに何サイト同居しているかの一覧
• 作業のたびに残す「対象範囲・実施内容・結果」の3行

改ざんの調査と復旧の実際の流れはWordPressが改ざんされた時の復旧手順、実際の対応記録、費用が跳ねる条件は改ざんや障害からの復旧にかかる費用と、金額が大きく跳ねる条件にまとめています。日常の更新とバックアップの体制そのものを整えたい場合は保守の対応内容をご覧ください。

よくある質問

ログが残っていない場合、漏えいしたかどうかも分からないままですか

断定できない範囲が残ります。実際の公表文では「漏えいの可能性」という表現が使われ、件数も非公表になりやすい。ただし、ファイルの更新日時、改ざんされたファイルの内容、データベースの中身といった別の材料から範囲を絞れることはあります。何も分からないわけではなく、「ここまでは言える」の線が手前に下がる、という理解が近いところです。

アクセスログは、どのくらいの期間を残しておけばよいですか

必要な期間は構成によって変わるため、一律の日数は示せません。判断材料として使えるのは、確認から漏えいの可能性の判明までに約2か月かかった事案や、侵入期間が2か月半にわたっていた事案が実際に公表されていることです。数日分で足りる前提は置きにくい。まずは契約中のサーバーで何日分残るのかを調べて、不足するなら外部へ退避する仕組みを作るところからになります。

改ざんされたファイルは、見つけたらすぐ消してよいですか

消す前に、別の場所へコピーしてください。削除してしまうと、何が置かれていたかという証跡が消えます。当社の案件でも、汚染ファイルを退避せずに復旧して後から参照できなくなった例があります。あわせて、1つ消して終わりにしないことも大事です。ディレクトリ名を変えて再設置された例があるため、全階層の棚卸しと、復旧後のアクセス履歴の確認まで含めて1回の作業と考えるほうが安全です。