前回の記事では「侵入を防ぐ予防対策」を紹介しました。しかし現実には、予防だけで100%の防御は難しく、いかに早く異常に気づくかが被害の拡大を防ぐカギになります。
この記事では、WordPressへの不正アクセスや改ざんを早期に発見するための「検知」対策を解説します。また、実際の感染事例で確認された巧妙な隠蔽手口も合わせて紹介します。対策を理解するうえで、攻撃者の手口を知ることは非常に重要です。
Solid Security による監視
Solid Security（旧 iThemes Security）は、WordPressのセキュリティを総合的に管理できるプラグインです。無料版でも以下の検知機能が利用できます。
ファイル変更検知
WordPressのコアファイルや wp-content 内のファイルが変更された場合に、メールで通知を受け取れます。
正常な運用では頻繁にファイルが変更されることはないため、身に覚えのないファイル変更の通知が届いたら要注意です。特に .htaccess・index.php・wp-config.php の変更は最優先で確認してください。
脆弱性スキャン
Solid Security は1日2回、WordPress本体・プラグイン・テーマに既知の脆弱性がないかをスキャンします。スキャン結果はメールで受け取れます。
ブルートフォース攻撃の記録
不審なログイン試行の記録と、問題のあるIPのブロック履歴を確認できます。「このIPから100回試行された」といった記録が残るため、攻撃を受けているかどうかの判断材料になります。
Google Safe Browsing 連携
Googleのセーフブラウジングリストにサイトが登録されていないかを確認します。マルウェアが検出されてGoogleにブロックされると、検索結果に警告が表示されてしまいます。これを早期発見できます。
Google Search Console を活用する
Google Search Console の「セキュリティの問題」タブは、Googleがサイトに問題を検出した場合に通知が届きます。
今回対応した実際の感染事例では、Googleの検索結果からアクセスした場合だけ別サイトにリダイレクトされるという症状が出ていました。直接URLを入力すると正常に表示されるため、サイト管理者が気づきにくい手口です。Google Search Console を定期的に確認していれば、このような異常を早期に発見できた可能性があります。
Search Console は設置しているだけでは意味がないので、定期的に「セキュリティの問題」と「手動による対策」タブを確認する習慣をつけましょう。
サーバーのエラーログを確認する
レンタルサーバーのコントロールパネルや FTP から error_log ファイルを定期確認することで、不審なPHPの実行エラーや404エラーの急増などを発見できることがあります。
特に以下のようなパターンは要注意です。
- 見覚えのないPHPファイルへのアクセス（例：
/wp-includes/ランダムな文字.php） wp-admin/css/やwp-content/uploads/配下のPHPファイルへのアクセス- 大量の404エラー（脆弱なURLを自動スキャンしている可能性）
バックアップを「検知の証拠」としても活用する
定期バックアップは復旧のためだけでなく、異常検知の比較対象としても役立ちます。
「いつからファイルが変わったのか」を特定するには、正常な状態のバックアップとの差分比較が有効です。バックアップは感染していない時点のものを外部に保存しておくことが重要で、サーバー上だけに置いておくと、感染と同時にバックアップも改ざんされるリスクがあります。
実際の感染事例で確認された巧妙な手口
ここからは、実際の感染サイト（WordPressを使った保育園のウェブサイト）で確認された攻撃手法を紹介します。現在のWordPressマルウェアがどれだけ高度化しているかの参考にしてください。
手口1：リファラーによる条件分岐リダイレクト
最も厄介だったのが、アクセス元（リファラー）によって表示を切り替える手口です。
- Googleなど検索エンジンのBot → SEOスパムコンテンツを表示
- Google経由の一般ユーザー → 別のショップサイトにリダイレクト
- 直接URLでアクセス → 正常なサイトを表示
管理者が自分でサイトを確認するときは直接URLを打ち込むことが多いため、「サイトは正常に動いている」と思い込んでしまいます。Google Search Console や外部のサイトチェックツールでないと気づけない巧妙な設計です。
手口2：CSSカラーテーマディレクトリへのバックドア隠蔽
WordPress管理画面（wp-admin）には、カラーテーマのCSSが格納された wp-admin/css/colors/ というディレクトリがあります。
このディレクトリには blue/・coffee/・ocean/ などのテーマごとのフォルダが存在しますが、各フォルダにPHPファイルが仕込まれていました。
セキュリティスキャナーはCSSファイルを格納するディレクトリをチェック対象から外すことが多く、発見が遅れやすい場所です。意図的に「普通は調べない場所」を狙った配置です。
手口3：CSS・画像ファイルに偽装した「永続化」バックアップ
マルウェアを削除しても自動的に復元される「永続化」の仕組みが確認されました。
改ざんされた .htaccess と index.php のバックアップが、以下のファイルに偽装して複数箇所に分散配置されていました。
.min.css（圧縮CSSファイルのように見せる）.min.js（圧縮JavaScriptファイルのように見せる）.png（画像ファイルのように見せる）.gif（画像ファイルのように見せる）
ドロッパーと呼ばれる復元プログラムが定期的にバックアップと現在のファイルを比較し、改ざんを検出すると自動的に復元します。削除→復元→削除→復元の無限ループに陥るため、バックアップファイルをすべて見つけて一括削除しないと完全な除去ができません。
手口4：三重難読化によるスキャン回避
マルウェアのコードは、セキュリティスキャナーに検出されないよう徹底的に難読化されていました。
具体的には以下の3つの手法を組み合わせていました。
① 文字列分割による関数名の構築
base64_decode のような危険な関数名を、変数を分割して組み立てることでスキャナーの文字列マッチを回避します。
// こんな感じで関数名を組み立てる（概念的な説明）
$a = "ba"; $b = "se"; $c = "64"; $d = "_decode";
// → 結合して base64_decode を生成
② 16進数・8進数の混合エンコード
文字列を \x70\141\x73 のように16進数と8進数を混ぜてエンコードし、通常の文字列マッチを回避します。
③ goto文による制御フロー難読化
ランダムなラベル名を使った goto 文を大量に挿入することで、コードの実行順序を視覚的に追いにくくします。静的解析ツールによる検出も困難にする手法です。
これらを組み合わせることで、シグネチャベースのスキャナーでは検出が非常に難しくなっています。
「気づかない攻撃」への心構え
今回の事例でわかるのは、攻撃者は「バレないこと」を最優先に設計しているということです。
- 管理者が確認するときだけ正常に見える
- 普通は調べない場所にバックドアを隠す
- 削除しても自動復元する
これらを考えると、「異常がなさそうに見える」ことがむしろ危険なサインである可能性もあります。定期的なスキャンと外部からの確認を習慣化することが、早期発見の最大の鍵です。
まとめ：検知のための確認リスト
定期的に以下を確認する習慣をつけましょう。
| チェック項目 | 頻度 | ツール |
|---|---|---|
| ファイル変更通知の確認 | 通知が来たら即時 | Solid Security |
| 脆弱性スキャン結果の確認 | 週1回 | Solid Security |
| Google Search Console「セキュリティの問題」 | 月1回以上 | Search Console |
| ログイン試行ログの確認 | 月1回 | Solid Security |
| サーバーエラーログの確認 | 月1回 | レンタルサーバー管理画面 |
| 外部からのサイト表示確認 | 月1回 | シークレットウィンドウ・別端末 |
次の記事では、実際に感染が発覚した後の「復旧フロー」を紹介します。マルウェアの完全除去から再感染防止まで、実務で対応した手順をもとに解説します。
