「対策していたのに破られました」WordPressの侵入経路をログから追って分かったこと

WordPressの復旧・トラブル対応を承っている、Web制作エンジニアのWadaHideです。

前回、実際に対応したサイト改ざんの話を書きました。今回はその続きで、「なぜ入られたのか」を調べた結果について書きます。

正直に言うと、調べる前の私の予想は外れていました。

（2026年9月24日 訂正：公開時、この記事では侵入経路を「ログイン試行を束ねて送りつけた、パスワードの総当たり」と書いていました。その後、別の事案を調べる中で、WordPress本体の欠陥を突かれた可能性が高いと分かったため、書き直しました。）

予想：どうせ古いプラグインの脆弱性だろう

サイトが乗っ取られたと聞いたとき、まず疑ったのは「更新されていない古いプラグイン」でした。よくある話です。何年も放置されたプラグインに既知の弱点があって、そこから入られる。セキュリティ記事でも、たいていそう書かれています。

ところが、サーバーのアクセスログを解析していくと、まったく違う答えが出てきました。

攻撃者が突いたのは、プラグインではなく、WordPress本体の欠陥でした。

パスワードは、当てられたのではなく書き換えられていた

ログを見ると、ログイン画面（wp-login.php）でパスワードを試すアクセスは、1週間で1件も成功していませんでした。ここは守られていたのです。

代わりに攻撃者が使ったのは、REST APIという別の入口でした。

WordPressを外部のプログラムから操作するための仕組みで、その中に「複数の処理をまとめて一度に実行する」機能があります。本来はまっとうな、効率化のための機能です。

ところが、この機能には本体の欠陥がありました。細工したリクエストを送ると、ログインしていない人でも、中のデータを書き換えられてしまうものです。直した版は、攻撃のちょうど1週間前に公開されていました。このサイトは、表示が崩れるのを避けるために自動更新を止めていたので、古いままでした。

実際のログでは、攻撃者はこの入口に約1分間で25回リクエストを送っていました。その直後に管理者のパスワードが書き換わり、攻撃者はその新しいパスワードで、ログイン画面から堂々と入ってきています。

パスワードは、当てられたのではなく、書き換えられていたのです。

玄関に頑丈な鍵をかけていたのに、勝手口の錠そのものが壊れていた。そういう状態でした。

実は、最初にログを読んだとき、私はこれを「ログイン試行を束ねた総当たり」と読み違えていました。「何度もアクセス → その直後にログイン成功」という形が、総当たりにそっくりだったからです。2か月後、別の事案で同じ欠陥を調べたときに、ログを読み直して気づきました。「パスワードが変わった」のが、ログインより先だったのです。

最初のアクセスから2分半で、裏口が完成していた

もう一つ、ログを秒単位で追って分かったことがあります。

新しいパスワードでログインした攻撃者は、その約20秒後には管理画面から偽のプラグインをインストールし、有効化していました。正規のキャッシュ系プラグインを装った、遠隔操作用のバックドアです。

さらにその20秒後には、そのバックドアが本当に動くかどうかのテストまで済ませていました。

最初のアクセスから、ここまで2分半。

「気づいてから対応すればいい」が成り立たない理由が、この数字に全部詰まっています。気づいた時点では、もう終わっているのです。

1日1万件、ずっと叩かれていた

ついでに過去のログも見てみました。

xmlrpc.php という、これも標準で用意されている入口があります。スマートフォンのアプリから投稿するための古い機能で、いまはほとんど使われていません。

そこに、1日あたり1万件を超えるアクセスが来ていました。被害が起きるずっと前から、毎日です。

サイトの運営者は、当然そんなことは知りません。管理画面には何も表示されないからです。何も起きていないように見えるのは、たまたままだ突破されていなかっただけでした。

そして、不正なアカウントは一つも作られていなかった

これも予想と違った点です。

「乗っ取られたら、見覚えのない管理者ユーザーが増えているはず」と思っていました。ところがユーザー一覧を確認しても、不審なアカウントは一つもありませんでした。

攻撃者がやったのは、既存の管理者アカウントのパスワードを変えて乗っ取ることだけ。新しいアカウントを作れば管理者に気づかれますから、目立たない方を選んだのでしょう。

「ユーザー一覧が正常だから大丈夫」とは言えないということです。

この経験から、対策の順番が変わりました

以前の私なら、セキュリティ対策として「パスワードを強くする、ログインURLを変える、ログイン試行回数を制限する」を挙げていたと思います。世の中の記事もだいたいそう書いています。

でも今回の件は、パスワードをどれだけ強くしても防げませんでした。当てられたのではなく、書き換えられたからです。

いまお客様に提案する順番は、こうなっています。

1つめ。本体とプラグインを最新に保つ。 自動更新をオンにしてください。今回の件は、直した版がすでに出ていたので、更新さえしていれば防げた攻撃でした。更新で表示が崩れることはまれにありますが、崩れた表示は直せば済みます。乗っ取られてからの復旧に比べれば、ずっと小さな手間です。

2つめ。使っていない入口を塞ぐ。 xmlrpcもREST APIの一括処理も、ほとんどの個人サイトでは使っていません。使わない扉は、鍵をかけるより塞いでしまうほうが確実です。

3つめ。表札を外す。 WordPressは初期状態だと、URLに ?author=1 と付けるだけでログイン用のユーザー名が見えてしまうことがあります。ユーザー名が分かっていれば、総当たりは「答えが半分埋まった状態」から始められます。ここを止めるだけで成功率は激減します。

4つめ。玄関を守る。 ログイン試行回数の制限と二段階認証。多くの記事が最初に挙げるものですが、順番としては最後です。

そして、ファイルを触るのが不安なら、まずレンタルサーバーのWAFを有効にしてください。 管理画面で切り替えるだけで、失敗のしようがなく、それでいてかなりの範囲をカバーできます。今日できることの中では、これが一番費用対効果が高いです。

対策していて破られる、ということはあります

この話を書いたのは、脅かしたいからではありません。

「ちゃんと対策していたのに」という状況は実際に起こる、ということを知っておいてほしいからです。そして、その原因はたいてい、対策していなかった部分ではなく、対策の対象だと思っていなかった部分にあります。今回で言えば、「更新を止めておくこと」が安全策のつもりで、実は穴になっていました。

自分のサイトが自動で更新されているか、入口がいくつ開いているか。一度確認してみてください。

ご相談について

「対策したいが、何から手を付ければいいか分からない」「設定ファイルを触るのが怖い」「以前トラブルがあったので、今度は大丈夫か確認したい」——そういったご相談も承っています。

私は、表面を直して終わりにせず、なぜ入られたのかを突き止めて塞ぐところまでを一つの仕事だと考えています。今回のように、ログを解析して侵入経路を特定し、その経路そのものを遮断する。そこまでやらないと、また同じことが起きるからです。

すでに被害に遭っている場合も、まだ何も起きていない場合も、状況の確認とお見積りは無料です。

一緒に、原因から考えていきましょう。