まず初めに

参考にした記事（ https://note.com/techlife/n/n1f9aa5c5d3f9 ）では、Xserverで運用していたWordPressサイトが外部から侵入され、複数工程を経て改ざん・再感染を繰り返した実録が詳細にまとめられていました。内容が非常に示唆に富んでおり、「WordPressの不正アクセスはこうやって進行し、こうやって深く入り込むのか」という理解が立体的に得られるものでした。

特に印象的だったのは、攻撃者の行動が単なる1回の侵入ではなく、複数の工程を計画的に積み重ねていることです。管理画面突破から偽装プラグイン設置、マルウェアの横展開、.htaccessの改ざん、PHP設定書き換えまで、ひとつひとつが連動しながら“長期滞在できる環境づくり”が進められていました。

ここでは、この記事を読んで理解できた「侵入後に実際何が起きていたのか」を、自分なりに整理してまとめていきます。

---

侵入・改ざんが起きたときの「何が起きていたか」プロセス分析

WordPressの不正アクセスは“ある一瞬で完結する攻撃”ではなく、段階的にサーバー内へ侵入し、段階的に支配を強めるタイプの攻撃でした。最初の突破から最終的な隠蔽まで、攻撃者がどの順序で行動していたのかを理解すると、どこを守るべきかが逆算できるようになります。

今回のケースでは、以下のような流れで侵入が進行していました。

• 管理画面ログイン突破
• プラグインアップロードによる WebShell 設置
• マルウェアファイルの大量生成
• サーバー内の横展開
• .htaccess 改ざんによる隠蔽
• php.ini／.user.ini 変更による再感染の仕込み

それぞれが「次の攻撃のための準備」になっており、侵入後に何もしないと常に再感染する状態が続くという、非常に厄介な構造になっていたことがよくわかります。

---

管理画面への突破からプラグインアップロードまでの侵入ルート

侵入の最初の一歩は、wp-login.php への不正POST → 管理者権限の取得でした。
ログを確認すると、ログイン成功直後に WordPress の管理画面からプラグインアップロードが実行されており、攻撃者は迷わず次のステップに進んでいます。

WordPressでは、管理者権限さえ奪われれば、プラグインアップロード機能を使って任意のPHPファイルをサーバーに設置できます。そのため、今回の事例はまさに「ログイン突破＝サイトの完全支配」を象徴する流れでした。

wp-login.php への不正 POST と upload-plugin 実行の痕跡

記事に掲載されていたアクセスログには、以下の攻撃動作が明確に確認できました。

• wp-login.php へのPOST（ログイン試行）
• 成功した直後にプラグインアップロード（upload-plugin）
• 続けて WebShell へのPOST要求を複数回実行

このログが示しているのは、攻撃者が最初から“プラグイン経由でWebShellを置くこと”を狙っていたという点です。ログイン直後に迷わず upload-plugin に進んでいるため、かなり計画的な侵入であったことがわかります。

偽装プラグイン・WebShell設置による初期支配の確立

アップロードされたプラグインは、正規の DuplicatePost プラグインに似せた偽造フォルダ構造になっており、その内部に alf.php のような WebShell が仕込まれていました。

このWebShellが設置された地点で、攻撃者は次の操作が可能になります。

• 任意のファイル作成
• マルウェアの自動展開
• システムコマンドの実行
• さらなるバックドア設置

つまり、偽装プラグインは「侵入後の支配権を確実にするための最初の基地」になっていたわけです。

---

マルウェアファイルの大量生成とサーバー内横展開

侵入後、攻撃者は単に一箇所を改ざんするだけではなく、短時間で大量のマルウェアファイルを生成し、サーバー内各所へ横展開していました。

その範囲は WordPress のテーマやプラグインディレクトリに留まらず、Maildir や backup フォルダ、session 領域など、普段利用者が気づかない場所にまで及んでいます。

典型ファイル名（av.php, wp-blog-header.php 等）の拡散状況

記事で公開されていた感染ファイルは、以下のような典型的な名称でした。

• av.php
• wp-blog-header.php（偽装コピー）
• wp-cron.php（偽装コピー）

これらは WordPress の正規ファイル名に似せて作られているため、見落としやすく、初心者では判断が難しいものばかりです。攻撃者が意図的に名前を紛らわせていることがよくわかります。

Maildir・backup・session 等への侵入範囲拡大のメカニズム

興味深かったのは、感染が WordPress ディレクトリ外にも広がっていた点です。
Xserver のアカウント環境はルート直下に多くのフォルダが共存しており、権限設定が不十分な場合、攻撃者がそのまま深く侵入してしまう構造があります。

特に session.save_path 配下や Maildir にまでマルウェアが拡散していた点は、攻撃が単なるWordPress改ざんではなくアカウント全体の侵害だったことを意味していました。

---

.htaccess改ざんと設定変更による“隠蔽と復活”の仕組み

多くのサイトで見落とされがちですが、攻撃者にとって .htaccess の改ざんは極めて重要な工程で、改ざんされると「不正ファイルだけ実行できるトンネル」が作られます。

攻撃者はそこに再感染用ファイルを仕込み、消しても消しても復活する状況を作っていました。

特定ファイル許可ルール（wp-crom.php 等）による実行トンネル形成

参考記事にあった改ざん例では、以下のような動作が確認されていました。

• wp-crom.php
• wp-confiq.php
• lock.php

など、偽物の名前に見えるファイルだけ Allow（実行許可） され、それ以外は拒否するというルールが記述されていました。

これにより、攻撃者が配置した偽装ファイルだけが“裏口として機能する状態”になり、どれだけファイルを削除しても .htaccess で復活させられる危険な状態が成立していました。

php.ini／.user.ini 改ざん・allow_url_fopen 等設定変更の痕跡

さらに深刻だったのは、php.ini や .user.ini まで操作されていた点です。

• allow_url_fopen = On
• auto_prepend_file に見えないファイルを指定
• session.save_path の誘導

などが確認されており、これは“サーバーの入口そのものを書き換える攻撃”に該当します。

WordPressのファイルだけではなく、PHPそのものの挙動を変えられていたため、抜け道が多数存在する極めて危険な状態でした。

WordPress改ざん後に必ず実行すべき初動対策ノウハウ

WordPressが改ざんされてしまった直後は「まずどこから手をつければいいのか」が最も混乱します。実際のところ、攻撃者は侵入した瞬間に複数のバックドアを仕込み、プラグインの偽装や.htaccessの改ざん、uploadsディレクトリへの横展開など、復旧者が追いきれない速度で痕跡を広げていきます。そのため、改ざんに気づいたら最初にやるべきことはサイトを「一度完全に止める」ことです。サイトが動いている限り、攻撃者が残している自動実行スクリプトが何度でも活動を再開し、こちらの復旧作業を上書きしてしまうからです。

一度“止める”と言っても、サーバーを停止する必要はありません。もっと現実的で効果が高いのは「管理画面まわりの入口をすべて閉じる」ことで、WordPress本体への再侵入を食い止めてからファイル調査に入るべきなのです。ここでは、実際の復旧現場で必ず実行する初動ステップを、必要な手順と背景まで含めて丁寧に解説していきます。

---

ログイン・管理画面をすぐロックダウンする方法

WordPressの改ざん後に最初に着手すべきは、wp-login.php と wp-admin の防御強化です。すでに内部に侵入された状態でも、ログイン画面を締め切ることで被害の進行速度を劇的に抑えることができます。

攻撃者は侵入後も BOT を使って wp-login.php に向けて不正 POST を送り続け、さらに admin-ajax.php 経由でスクリプト呼び出しを自動化しているケースが多いため、とにかく最初に “入口” を封じてしまうことが極めて重要になります。

具体的に最初にやるべき2つのアクション

• wp-login.php と wp-admin への同一グローバルIP以外のアクセスをすべて遮断する
• 必要であれば Basic 認証を追加し二重防御を構築

この2つを行うだけで、不正ファイルの再生成・再アップロードが一気に止まり、こちらの調査スピードが攻撃者を上回ります。

---

wp-login.php／wp-adminへのIP制限の書き方

攻撃者が侵入した直後に行うのは、「管理画面への常時アクセス」です。バックドアの呼び出し、プラグインページからのファイルアップロード、テーマエディタからの不正コード挿入──いずれも wp-admin を通じて行われるため、最初の遮断地点として IP 制限は必ず機能します。

以下の .htaccess 記述は、改ざん復旧現場で最も利用される、シンプルかつ強力なテンプレートです。

<Files wp-login.php>
    Order deny,allow
    Deny from all
    Allow from xxx.xxx.xxx.xxx
</Files>

<Directory "/home/ユーザー名/public_html/wp-admin">
    Order deny,allow
    Deny from all
    Allow from xxx.xxx.xxx.xxx
</Directory>

この形のメリットは、WordPress がどれだけ改ざんされていても「入口そのものを止めてしまう」ため、攻撃者の再侵入をほぼ完全にシャットアウトできる点です。特に admin-ajax.php を起点にしたスクリプト呼び出し攻撃が止まるため、ファイル調査中に“また増えてる”という事態がピタッと収まります。

---

Basic認証併用による二重防御の導入手順

IP 制限だけでも強力ですが、固定IP が使えない作業環境では Basic 認証を重ねることで二段構えの防壁を構築できます。実務ではむしろ「IP 制限 + Basic 認証」の組み合わせが鉄板で、攻撃者が BOT で POST を連打してくる環境下では、Basic 認証の段階で自動的に弾き返されるため、不審ログが劇的に減ります。

最も簡単な導入手順は以下の通りです：

<Files wp-login.php>
    AuthType Basic
    AuthName "Restricted"
    AuthUserFile /home/ユーザー名/.htpasswd
    Require valid-user
</Files>

htpasswd を作成したら、管理画面・ログイン画面の双方に適用することで、攻撃者のスクリプトアクセスをほぼ根絶できます。復旧期間中だけでも構いませんが、実際には「本番運用でもずっと残す」ケースが多いほど効果の高い対策です。

---

マルウェア／不審ファイルの削除と権限リセット手法

入口を閉じたら、次は内部に仕込まれたバックドアの削除です。ここからが“本当の復旧作業”で、攻撃者は想像以上に多くのファイルを散らしています。特に WordPress では uploads・session・backup ディレクトリが狙われやすく、偽装された .php ファイルが深い階層に潜んでいることが多いのが特徴です。

バックドアはひとつではなく「数十〜数百単位」で複製されているケースもあります。特に、.png や .txt に見せかけて実際は PHP スクリプトというパターンはよくあるため、拡張子だけで判断すると必ず見逃します。

よくある不審ファイルパターン（実務でよく遭遇するもの）

• 画像ファイルに偽装された .php（例：img_2025.png.php）
• uploads 下にある月別ディレクトリ内の謎の .php
• session や backup 配下に無関係な .php が大量生成
• テーマディレクトリに挿入された class-plugin.php や wp-blog-header.php の偽装版

これらをまとめて削除するために、復旧現場では「拡張子フィルタ」で洗い出すのではなく、“php という文字列を内包しているファイルをすべて抽出”する方法をよく使います。

---

uploads・session・backupディレクトリの横展開確認ポイント

攻撃者は侵入直後に uploads → session → backup の順で横展開する傾向があります。uploads は書き込み可能なディレクトリであり、session はユーザー側の一時ファイルが多く監視が甘く、backup は古いファイルが放置されているケースが多いため、どれも自由に PHP を設置しやすい環境です。

これらのディレクトリを調べる際のポイントは以下の2点です：

• “月別ディレクトリの中”にあるファイルに必ず目を通すこと
  2024/07、2024/08 のような月ごとの階層は油断しがちで、ここに数十のバックドアを仕込まれていることが多いです。
• バックアップ名に偽装したファイルを必ず調べること
  backup.php や old-wp.php、あるいは wp-config.php.bak.php のような“ありそうな名前”で紛れるため、バックアップを装った PHP は全部疑うべきです。

横展開を見逃すと、復旧後に再侵入される確率が跳ね上がります。uploads の調査を雑にやるとほぼ確実に後で後悔するため、丁寧な確認が必須です。

---

.htaccess改ざんのリセットとPHP実行禁止設定テンプレート

最後に、攻撃者が必ず触ってくるのが .htaccess です。攻撃者はここに「特定ファイルだけを許可して実行するためのトンネル」を仕込み、管理画面を締め切ってもバックドアが動作するように細工してきます。特に wp-content/uploads で PHP 実行が可能になっている場合、何度削除してもすぐ復活します。

復旧時にまずやることは以下の2つです。

• .htaccess を WordPress デフォルト状態に戻す
• uploads で PHP を実行できないように明示的に禁止する

以下のテンプレートは、実務でも最もよく使われる安全な初期化用です。

# WordPress デフォルト htaccess（リセット用）
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

さらに uploads 以下での PHP 実行禁止は必須です。

# uploads 配下での PHP 実行を完全禁止
<Directory "/home/ユーザー名/public_html/wp-content/uploads">
    php_flag engine off
    Options -ExecCGI
    RemoveHandler .php .phtml .php3 .php4 .php5 .php7 .php8
</Directory>

この設定を入れるだけで、uploads に置かれたバックドアは二度と実行できません。
特に改ざん後は、uploads 配下の不審 PHP が「犯行の中心地」になっているケースがほとんどのため、ここを閉じるだけでも被害の8〜9割が止まります。

WordPress継続的に安全運用するための防御テクニック

WordPressは世界中で利用される反面、攻撃者からも常に狙われる CMS です。改ざんや不正アクセスは「侵入された瞬間」だけで終わるわけではなく、攻撃者が内部に小さなトンネルを残し、時間差で復活するケースが圧倒的に多いのが現実です。そのため必要なのは、単に侵入を防ぐ一次対策ではなく、**“継続的に攻撃に耐えられる運用体制をどう組むか”**という視点です。ここから紹介する防御テクニックは、実際にインシデント対応の現場で使われているノウハウをまとめたもので、毎日の運用・チェックに落とし込むことを目的にしています。

WordPressのセキュリティは、プラグイン更新だけを気をつければ良いという単純な話ではありません。資格情報の管理、テーマ更新、ファイル権限、PHP設定、サーバー構成など、複数の層が噛み合わないかぎり「本当の安全」は確立できません。逆に言えば、この複数の層を正しく組み立てられれば、あなたのサイトは“攻撃されても崩れない”構造にできます。

---

プラグイン・テーマ・資格情報を一新して安全体制にするには？

侵入や改ざんのリスクを最も高くしてしまうのは、“古いまま放置されたプラグイン・テーマ・パスワード”です。攻撃者はまずここを突破口にします。
したがって、継続運用で最重要となるのが **「バージョン管理と資格情報の総入れ替えをどう定期化するか」**という点です。

改ざん痕跡がなくても、3〜6ヶ月のサイクルで権限と設定を見直すことが理想です。特に企業サイトの場合、複数の担当者が更新することも多く、半年以上パスワードが更新されていないケースはよくあります。こうした“綻び”が、一気に侵入口となってしまうのです。

以下の項目は、ほぼ全てのセキュリティ専門業者が必ずチェックする基本ラインで、WordPressを安全に継続運用するために欠かすことのできない工程です。

---

パスワード総取替・SALT再生成・不要アカウント削除の流れ

パスワードや認証情報が一度でも漏洩すると、攻撃者は数か月〜数年後に利用してくることさえあります。そのため、継続運用では以下の“総入替フロー”をワンセットで実行するのが鉄則です。

■ パスワード総取替の理由と実施ステップ

長文：
管理者アカウントだけを変更すれば安心、と思いがちですが、実際には「編集者・寄稿者・開発者アカウント」が古いまま放置されているケースが多く、ここを突破されて backend に侵入される事例は頻繁に起きています。特に外部制作会社が過去に触ったサイトでは、退職者・旧制作会社・外注業者のログイン情報が残っていることがよくあり、これは最大級のリスクになります。すべてのアカウントを棚卸しし、不要なアカウントを削除し、残すアカウントは強力なパスワードで再発行することがセオリーです。

箇条書き（割合2）：

• 管理者・編集者・寄稿者・開発者すべてのアカウントを一覧化
• 必要なものだけ残し、残すアカウントは全て新パスワードに変更

■ SALT再生成の重要性

長文：
WordPressはユーザーのログイン状態を cookie に保持しますが、その署名に使われる暗号キーが AUTH_KEY / SECURE_AUTH_KEY / LOGGED_IN_KEY / NONCE_KEY などの“認証SALT”です。このSALTは、侵入が疑われる際には必ず再生成して差し替えるべき項目です。なぜなら攻撃者が一度でもサーバー内部を覗いていた場合、このSALTを取得されるだけで「あなたのブラウザになりすまし、ログイン不要で管理画面に侵入」できてしまうためです。

箇条書き：

• WordPress.org の SALT生成ツールで新キーを発行
• wp-config.php 内の既存キーを全て上書き

---

偽装プラグインの見抜き方とプラグイン最適化の実践方法

長文：
侵入後に最も多いのが「正規っぽい名称をつけた偽装プラグインの設置」です。攻撃者は“update-manager”“seo-optimizer”“core-enhancer”など、本物に紛れる名称でフォルダを作り、そこに WebShell を設置します。管理画面上にも表示されないよう偽装する手法も多く、FTP で確認しなければ気付かないケースもあります。
継続運用の観点では、単にプラグインの更新をするだけでは不十分で、**「本当に必要なプラグインだけを残し、それ以外は削る」という最適化」が最大の防御になります。プラグインが多ければ多いほど攻撃対象面が広くなり、脆弱性が発生する確率も比例して増えるからです。

箇条書き：

• /wp-content/plugins/ に存在するフォルダと管理画面の一覧を照合
• 必要最小限の5〜10本に絞り、更新管理しやすい状態に保つ

---

サーバー設定・PHP構成・ファイル権限を強化する

WordPressの防御レイヤーで見落とされがちだが実は最重要と言ってよいのが、“サーバー側の設定”です。どれだけ WordPress 内部を強化しても、PHP や Apache/Nginx の設定がザルだと、そこを突かれて侵入されます。
特にレンタルサーバーの場合、初期設定では利便性重視のためセキュリティが強くない状態になっているケースも多く、意図せず危険な設定がONになっている場合があります。

継続運用では、WordPressよりもむしろサーバー側の設定見直しを定期化することで、攻撃面を一気に減らすことができます。

---

allow_url_include／expose_phpなど危険設定をOFFにする理由

長文：
PHP には、遠隔ファイルを読み込んだり、サーバー内部の構造を漏らしてしまう“危険な設定”が複数あります。これらが ON のままだと、攻撃者は外部の悪性スクリプトを読み込んだり、サーバー上の PHP パスを逆引きして脆弱箇所を突くといった攻撃ができてしまいます。
特に “allow_url_include” が ON になっている環境は危険で、URL 経由で任意のPHPファイルを読み込ませられることがあるため、現代のセキュリティ基準では完全に廃止されるべき設定です。
“expose_php” も同様で、ONになっているとレスポンスヘッダーに“PHPのバージョン”が含まれます。これが攻撃者にとっては「あなたのサイトにどのバージョンの脆弱性が存在し得るか」のヒントになるため、運用上は必ずOFFにしておく必要があります。

箇条書き：

• php.ini で allow_url_include = Off, expose_php = Off
• 併せて display_errors = Off にし、内部構造を外部に漏らさない

---

フォルダ755・ファイル644・wp-config.php600の原則と運用ルール

長文：
WordPressのファイル権限は、攻撃者による書き換え防止において最も重要な設定です。正しく権限が設定されていないサーバーでは、WordPressコアやテーマファイルに勝手にコードを挿入され、バックドアが仕込まれるケースが多発します。
基本原則は「フォルダ755・ファイル644・wp-config.phpだけ600」です。これは読み取りと実行は許可するが、書き込みは必要最低限だけに制限するためのルールで、LaravelやRailsなど他のフレームワークでも同じ思想が採用されています。
特に wp-config.php はデータベースのID/パスワード・SALTなど最重要情報が含まれるため、600にして“所有者のみ読み書き可”にすることが不可欠です。また、権限は設定したら終わりではなく、テーマ更新やプラグイン更新によって自動的に書き換わる場合があるため、月1〜2回は必ず見直す運用が求められます。

箇条書き：

• wp-config.php → 600, ファイルは644・フォルダは755で統一
• 更新作業のたびに権限を再確認し、不要な書き込み権限を削除

再発を防ぐためのチェックリストと月次運用ルーチン

WordPressは一度改ざんされると、潜伏型マルウェアが残存し続け、数週間〜数ヶ月後に再び不正アクセスが発生するパターンが非常に多いCMSです。そのため「直したら終わり」ではなく、“どう月次運用をするか”がサイトの寿命を決めると言っても過言ではありません。再発率を下げる運用体制は、技術的な強化だけではなく、月次ルーチンとして定期的に動かす仕組みを整えることが必要です。
ここでは、現場のセキュリティ担当が実際に行っているリスク検知ルーチンをもとに、最低限守るべきポイントをまとめていきます。

---

潜伏マルウェアを見逃さないためのスキャン・監視手順

WordPress改ざんの7〜8割は、目に見える被害が出るよりも前に、不正ファイルが数十〜数百単位で入り込んでいます。しかも最近のマルウェアは、通常のファイル名を偽装しながらwp-includes や uploads 配下に巧妙に潜り込み、運営者に気づかれないように活動を停止したり再始動したりする“ステルス性”を持っています。
そのため、月に一度のスキャンと検索では不十分であり、週単位で基礎的な検知タスクを回すことが、再感染の確率を劇的に下げる鍵となります。

◆ av.php／base64_decode／gzinflate等キーワード横断検索の習慣化

潜伏マルウェアは、ほぼ例外なく「共通の不正記述」を持っています。これは開発者や攻撃者が異なっても共通して現れる特徴で、特に以下の文字列は毎回の横断検索で必ず拾っておくべき“基礎ワード”となります。

• av.php（WebShellの代表名。名称が変わっていても類似しがち）
• base64_decode、eval、assert、gzinflate などの不正実行用関数
• $_POST と組み合わせた不正コード挿入パターン

長文：
これらのキーワードは、攻撃の種類や巧妙さが異なっていても、コード内部に残らざるを得ない“特徴指紋”のようなものです。とくに gzinflate や base64_decode を組み合わせた暗号化コードは、悪意あるファイルの約90%以上に共通して見られる傾向があり、これらを横断検索するだけで潜伏マルウェアの大半を検知できます。
検索はFTPクライアント、サーバーパネル、SSHなどどの環境からでも可能ですが、最も確実なのは サーバー側でgrepコマンドを用いてルートから全検索する方法 です。また、検索は“見つけること”が目的ではなく“異常がないことを確認すること”に意味があり、週1ルーチンとしてカレンダーに固定するのが理想です。

---

◆ .htaccess／.user.ini 更新日時の定期チェックと異常検知ポイント

• .htaccess が突然書き換わっていないか、更新日時を週1で確認
• .user.ini の生成・更新は高確率で“攻撃者の痕跡”のため要注意

長文：
.htaccess と .user.ini は、攻撃者が最初に触る“入口の設定ファイル”です。とくに .htaccess はWebサーバー側の挙動を強制的に変更できる強力な設定ファイルのため、ここに不正コードが1行混入しただけで、任意のPHPファイルを動かしたり、別サーバーへトンネルを作ったりできます。
さらに近年増えているのが .user.ini です。本来 .user.ini は用途が限られていますが、攻撃者はこれを悪用して auto_prepend_file を挿入し、どのPHPファイルが呼び出されても必ず不正コードが読み込まれる状態を作り出します。
この手法は極めて強力で、表面上サイトが正常に見えても裏側では不正ファイルが再生成され続けることがあります。だからこそ、“更新日時の変化”が唯一の兆候になる場合が多く、月次でなく週次で確認する運用が推奨されます。

---

ログ・バックアップ・運用ルールを見直して「運用で守る」体制へ

WordPressのセキュリティ対策は“設定を固める”だけでは不十分で、日々の小さな異常をどれだけ早く拾えるかが再発防止の核心になってきます。アクセスログ・エラーログ・バックアップ管理などは「やればいい」という話ではなく、**“どの範囲をどの周期でチェックするか”**の再設計が不可欠です。
そして、ここを仕組み化していないサイトは、例外なく再感染のリスクが高い傾向があります。ログ管理やバックアップの頻度を改善するだけで、攻撃発生から検知までのタイムラグが大幅に縮まり、結果的に「改ざんされても影響最小」で済む体制になります。

◆ 週1バックアップの保管戦略とステージング運用の重要性

近年の攻撃は、WordPress本体やプラグインだけでなく、uploads 内の画像フォルダにPHPを偽装して仕込むなど、従来のバックアップでは復元しきれない手口が一般化しています。だからこそ、**バックアップの“質と保存戦略”**を見直す必要があります。

• 週1のフルバックアップ（本番/DB/テーマ/プラグイン/Uploadsを含む）
• 最新3〜5世代を保持し、過去分はローカル環境に退避する

長文：
バックアップは、単に保存しているだけでは意味がありません。重要なのは「具体的にどこから復元できるのか」を把握することです。また、ステージング環境（検証環境）は、復元テストを安全に行う唯一の場所であり、ステージングで“復元→確認”を回して初めてバックアップが機能していると言えます。
さらに、最近は“改ざんされている状態でバックアップが上書きされてしまい、過去の安全な状態が消えてしまう”ケースも多いため、“保存期間のポリシー”や“ローカル退避ルール”を明文化することが必須です。

---

◆ 管理者パスワード変更、不要アカウント削除、ステージング反映の運用フロー

WordPressに改ざんが起きたプロジェクトでよく見られるのが、**“管理者アカウントが多すぎる”**問題です。人数が増えるほどセキュリティリスクは跳ね上がり、実際に攻撃者が「過去に使われた古い管理アカウント」から侵入してくる事例は後を絶ちません。

• 管理者パスワードは1〜2ヶ月に1度の更新
• 使用していない管理者・編集者アカウントは即削除（停止では不十分）

長文：
管理者アカウント管理は、セキュリティ対策のなかでも最も人的な影響が大きい部分です。アクセス権が多いサイトほど、攻撃者が“突破しやすい入口”を見つけやすくなるため、定期的な棚卸しは絶対に外せません。また、パスワードを変更するだけでなく、ステージング環境へ反映するフローを整備することも重要です。
理由は、ステージング側の管理者アカウントが実は生き残っており、本番と異なる認証情報が存在するケースがあるからです。攻撃者はステージングを突破して本番へ横展開することも可能で、実際にそのパターンで再感染が起きた事例は珍しくありません。
そのため、**本番とステージングは常に同期管理し、“不要なユーザーは両方から削除”**というルールを明文化し、運用チーム内で徹底することが再発防止に直結します。

まとめ：WordPress改ざんは「設定強化＋運用改善」で防ぐ

WordPress の改ざん被害は、一度復旧して終わりではなく、その後の“再侵入リスクをどう潰していくか”が本質になります。多くの人が、表面的に見えるマルウェアファイルを削除し、プラグインを再インストールし、見た目が正常になったことで「直った」と判断してしまいます。しかし、実際にはその後こそ注意すべきで、侵入者はバックドアを複数個所に仕込み、wp-config.php や uploads など普段チェックされない箇所に入口を隠していることが頻繁にあります。だからこそ、復旧作業は“ゼロに戻す”ことではなく“もう侵入できない状態を構築していく”ことをゴールに据える必要があります。サイトは動いている限り攻撃者に観測され続けるため、防御を一段階厚くするだけでは足りず、設定面・監視面・運用面のすべてを底上げする「複合的な対策」が必須です。

---

一時対応だけでは再侵入リスクが残るという現実

改ざん復旧後に再び攻撃されるサイトのほとんどが、「可視化されている問題」だけに対処しているケースです。攻撃者は通常、侵入→バックドア設置→偽装ファイル配置→自動復元の仕組みを入れる、という“階層的な仕込み”を行うため、表面上のマルウェアを削除しただけでは、裏側で生き残っているバックドアがやがて改ざんを復活させます。また、脆弱なパスワード・管理者アカウント乱立・古いテーマやプラグイン放置といった、人間側の運用ミスも再侵入の大きな原因です。WordPress は“強化しない状態”で使い続けるほど攻撃対象になりやすく、一時的にファイルを削除しても根本原因が解消されない限り、攻撃者にとっては依然として「入りやすい家」のままです。

・よくある再侵入の典型パターン

• マルウェア削除後に wp-config.php 内のバックドアが生存していて復活
• uploads ディレクトリに設置された「.jpg に偽装された php」が再実行される
• テーマ内にバックドアが残ったまま再び横展開される
• パスワードを変えずに運用を再開して再度突破される

・一時対応で終わらせると危ない理由

• “見える場所だけ削除する”は攻撃者の想定内
• 攻撃者は複数の入口を用意するため“1個所の対処”では復活する
• セキュリティ設定が弱いままでは、何度でも突破される

---

多層防御（ログイン制限・PHP実行禁止・監視運用）が鍵

WordPress を安全に保つために最も効果が高いのは「多層防御」です。攻撃者が侵入してくるルートは一つではありません。ログイン突破もあれば、REST API 経由、古いプラグインの脆弱性、テーマファイル改ざん、アップロード機能の悪用など様々です。そのため、防御も“単一の対策”では不十分で、複数のレイヤーを組み合わせることで侵入を困難にし、仮に一段を突破されても次の防壁で止める構造を作る必要があります。たとえば IP 制限だけでは海外からの攻撃は防げても国内 VPN から突破される可能性が残りますし、パスワード強化だけでは REST API 攻撃を止められません。だからこそ「入口」「ファイル実行」「監視」の三つのレイヤーを同時に固めることが重要です。

・多層防御で必須となる三つの柱

• ログイン防御（IP 制限／Basic 認証／ログイン URL 変更）
• PHP 実行の禁止（uploads・wp-content 配下での実行を封じる）
• 監視運用（改ざん検知・ファイル変更チェック・アラート通知）

・多層防御が強力な理由

• 1つ突破されても次の壁で防げる
• 攻撃者側のコストが一気に上がる
• 自動化攻撃をほぼシャットアウトできる
• 手動攻撃にも強く、改ざん後の復活も難しくなる

多層防御を導入すると、WordPress は「攻撃者にとって割に合わないサイト」になり、他サイトに比べて狙われにくくなります。これは防御の世界では非常に重要で、攻撃者は“入れるサイト”を優先的に狙うため、強固な設定にすること自体が最大の予防策になるのです。

---

非エンジニアでも始められる“最優先チェック項目”をまず実装しよう

セキュリティ対策と聞くと技術的なイメージが強く、初心者にはハードルが高いように思われがちです。しかし、実際には“非エンジニアでも今日からすぐ着手できて、効果が非常に大きい対策”が存在します。むしろ、サイト運用者の 8 割がこの基本対策を実施していないため、攻撃者にとって WordPress が「世界で最も狙いやすい CMS」の地位を維持してしまっているのです。専門知識がなくても実行できる項目を先に固めるだけで、改ざんリスクは体感で半分以下になります。

・今日からできる“最優先の３つ”

• 管理者パスワードの即時強化・使わないアカウントの削除
• プラグイン・テーマの更新と不要なもののアンインストール
• wp-admin / wp-login.php への最低限の IP 制限または Basic 認証の追加

・非エンジニアでも効果が出る理由

• 攻撃の9割が“弱いパスワード”と“放置プラグイン”狙い
• 管理画面に入られなければ 80％ の攻撃は成立しない
• 難しく見えるファイル権限や PHP 設定よりも “入口防御” が圧倒的に効く

最初から完璧を目指す必要はありません。まずは入口・更新・アカウント管理の 3 本柱を固め、徐々に PHP 実行制御や監視運用にステップアップしていくのが、最も現実的で効果の高いアプローチです。運用の習慣さえ整えば、WordPress は十分高い安全性を維持できます。