第5回: DB事故と移転。シリアライズデータと整合性の防衛
WEB先案内
WEB先案内 ITブログ
第6回: セキュリティ・フォレンジック ― 侵入後の「追跡と復旧」【WordPress改ざん対策】
WEB先案内
WordPressは成熟したCMSです。しかし成熟とは「壊れない」という意味ではありません。
- REST APIの標準化（外部操作経路の増加）
- プラグイン依存構造の拡張
- 自動化攻撃の高度化
これにより、侵入は「偶発的な事故」ではなく構造的な事象になっています。
第6回は復旧テクニックの話ではありません。侵入後に制御を取り戻す設計思想と実践手順の話です。
侵入された後、あなたは「どこから壊れたか」を説明できますか？
なぜ復旧は失敗するのか（構造的理由）
多くの復旧は「見つかった改ざんファイルを削除する」ことで終了します。
- 改ざんファイルを発見
- 削除
- 正常表示確認
- 完了
しかし侵入は単一ファイルではありません。
- 1️⃣ 侵入経路の偵察
- 2️⃣ 侵入（実行コードの配置）
- 3️⃣ パーミション変更（権限昇格）
- 4️⃣ 永続化の仕込み
- 5️⃣ 外部通信（再生成ルートの確立）
ファイル削除だけで直らない理由は、4️⃣と5️⃣を処理していないからです。永続化が残れば、再発は必然です。
ケーススタディ：48時間後の再侵入
改ざんPHP削除 → 動作正常 → 48時間後に再発。
原因はwp_optionsのautoload（起動時自動読込領域）に登録された再生成ロジックでした。
そのコードは、削除されたファイルを外部から再取得していました。
ここで重要なのは「どの層に仕込まれていたか」です。
- ファイル層（PHP改ざん）
- データ層（DB改ざん）
- 実行層（cron / hook）
- 通信層（外部C2接続）
| 層 | 役割 | 見落としやすさ |
|---|---|---|
| ファイル層 | PHP改ざん | ★ |
| データ層 | DB改ざん | ★★★ |
| 実行層 | cron/hook | ★★★★ |
| 通信層 | C2接続 | ★★★★ |
単一層しか見ない復旧は失敗します。
実践①：ログ解析（侵入前段階の可視化）
ログ抽出コマンド例：
grep "POST /wp-login.php" access.log | wc -l
grep "xmlrpc.php" access.log | sort | uniq -c | sort -nr | head
grep "wp-json/wp/v2/users" access.log検証基準：
- 1時間で100回以上のログイン試行
- 単一IPからの連続アクセス
- 同一UAでの高速連続リクエスト
重要なのは件数ではありません。
偏りです。
偏りは自動化の兆候です。
実践②：永続化の構造的検出
autoload領域確認（起動時に必ず実行される設定群）：
SELECT option_name
FROM wp_options
WHERE autoload='yes'
ORDER BY LENGTH(option_value) DESC
LIMIT 20;異常の判断基準：
- 異常に長い値（暗号化・エンコードの可能性）
- 意味を説明できないoption名
- base64やevalを含む文字列
autoloadに仕込まれると、削除しても再生成されます。
cron確認：
print_r(_get_cron_array());もし未知のhookが見つかれば注意してください。
それが再生成トリガーである可能性があります。（定期実行される構造があるかを確認）
実践③：差分の判断ロジック
wp core verify-checksums
diff -r clean_wp/ infected_wp/見るべきポイント
- 更新日時が不自然
- コメントアウト内にコード
- 画像拡張子にPHPコード
- wp-config.phpの微改変
問題は単語ではなく、
「なぜそこにあるのか説明できるか」
説明できなければ異常です。
実践④：DB改ざんの検出
scriptタグは表示時に外部通信を誘発します。phpMyAdminなどのツールで次のようなクエリーを実行してチェックしてみてください。
SELECT ID, post_title
FROM wp_posts
WHERE post_content LIKE '%<script%';注意
WordPressはシリアライズ構造（文字列長依存保存形式）を使用します。単純置換は破壊を招くので気をつけてください。
やってはいけない復旧
- 改ざんファイルだけ削除する
- ログを見ずに初期化する
- DBを単純文字列置換する（シリアライズ破壊）
- パスワード変更を後回しにする
これらは再発確率を上げます。
FDE事故設計
✅ FDE（Forensic-Driven Engineering）とは
フォレンジック（証跡解析）を出発点に、
復旧を「設計プロセス」として実行するアプローチ。
特徴
- ログ起点
- 順序重視
- 再発確率の最小化
- Root Cause 分離
フォレンジックは解析行為。
Engineeringは再発防止設計。
つまり、FDEは
「侵入解析」＋「再発設計」
の統合概念。
FDEの5工程（正式用語整理）
- ① Preserve（証拠保全）
- ② Scope（影響範囲確定）
- ③ Root Block（侵入口封鎖）
- ④ Rebuild（クリーン再構築）
- ⑤ Monitor（再発監視）
① Preserve（証拠保全）
侵入直後にログと状態を保全する工程。
目的：
- access_log / error_log保存
- 改ざんファイルコピー
- DBダンプ取得
削除より先に保全。
ここを飛ばすと因果関係が消えます。
② Scope（影響範囲確定）
侵入の全体構造を特定する工程。
対象：
- 改ざんファイル
- 管理者ユーザー
- autoload
- cron
- DB汚染
見えているファイルで止めない。
③ Root Block（侵入口封鎖）
侵入経路を遮断する工程。
例：
- wp-login制限
- XML-RPC無効化
- WAF有効化
- パスワード総変更
※chmod 000はここに該当 → 実行停止（止血）
④ Rebuild（クリーン再構築）
汚染前状態へ再構築する工程。
- WordPress再インストール
- テーマ/プラグイン再取得
- DBクリーン化
上書きではなく再取得。
⑤ Monitor（再発監視）
再侵入を監視する工程。
- ログ偏り検知
- cron監視
- autoload監視
- ファイル差分監視
ここまでやって初めて復旧完了。
FDEが従来復旧と違う点
| 従来復旧 | FDE |
|---|---|
| 見つかったファイル削除 | 挙動から逆算 |
| 単発処理 | 構造処理 |
| 再発は偶然 | 再発は確率制御 |
では実践的な手順とは？
「侵入を発見した直後から再発防止まで」を実行順に整理します。
重要なのは、速さではなく順序です。順序を誤ると、証拠を消し、原因を隠し、再発の種を残します。
解決への流れ
全ログ保全（触るな、残せ）
最初にやるべきことは修復ではありません。保全です。
実行項目
- access.log の退避（攻撃経路の時系列を保持）
- error.log の退避（実行失敗や不審エラーの痕跡を保持）
- DBダンプ取得（侵入前後の差分確認用）
- 改ざんファイルのコピー（削除せず別保存）
なぜ最初にやるのか？
ログは循環します（一定容量で上書きされる）。
削除・更新を先に行うと、侵入の物語が消えます。
侵入は「点」ではなく「流れ」です。
時系列を保持できるかどうかで、設計者としての質が決まります。
侵入口封鎖（止血処置）
保全後、即座に侵入口を閉じます。ここは「原因特定」ではなく「拡大防止」です。
実行項目
- 全ユーザーパスワード変更（セッション強制失効）
- wp-admin へのIP制限（外部試行遮断）
- XML-RPC 無効化（ブルートフォース経路遮断）
補足（挙動・影響）
XML-RPCは一括認証試行を可能にします（高速総当たりが可能）。
遮断しない限り、攻撃負荷は止まりません。
侵入経路が未特定でも、横展開を止めることが最優先です。
クリーン再構築（上書きではなく再取得）
感染ファイルの「修正」は推奨しません。
理由は単純です。完全に戻せた保証を得られないからです。
実行項目
- WordPressコア再インストール（公式配布版で上書き）
- テーマ再取得（配布元から再DL）
- プラグイン再取得（公式リポジトリ版へ置換）
なぜ再取得なのか？
改ざんコードは微細です（1行だけ差し込まれる）。
目視修復は人間の認知限界を超えます。
クリーン再取得は、差分ゼロを保証する唯一の方法です。
DB精査（永続化の確認）
侵入が厄介になるのはここからです。
ファイルが綺麗でも、DBが汚染されていれば再発します。
実行項目
- wp_options の autoload 確認（自動読み込み領域の監視）
- cron登録確認（再生成トリガー確認）
- 投稿本文への script 混入確認
補足（挙動・影響）
autoload = yes のデータは毎回ページ読込時に実行対象になります（常駐化）。
ここに悪性コードが入ると、削除しても再生成される場合があります。
cronは時間差再実行の装置です（遅延爆弾）。
削除後に戻る現象は、ほぼここが原因です。
監視設計（未来の制御）
復旧で終わるなら、再発は時間の問題です。
最後に行うのは監視設計です。
実行項目
- ログ監視導入（異常試行検知）
- ファイル改変通知（差分即時検知）
- 週次差分確認（意図しない変更の把握）
なぜ監視が最終工程か？
フォレンジックは過去を見る技術です。
監視設計は未来を守る技術です。
この二つが揃って初めて、サイトは「制御可能状態」に戻ります。
即実行チェックリスト
- [ ] wp core verify-checksums 実行
- [ ] autoload上位確認
- [ ] cron確認
- [ ] 管理者ユーザー棚卸
- [ ] 全パスワード変更
- [ ] サーバー権限確認
- [ ] 外部通信ログ確認
フォレンジックとは、未来の再発を設計する行為である。
注釈（挙動と影響）
本章で登場した用語は「定義」ではなく挙動と影響で理解してください。問題は意味ではなく、何が起きるかです。
REST API
外部操作経路（JSON経由で取得・更新可能）。
未制限の場合、ユーザー名列挙が可能になり、管理者推測の足掛かりになります。
curl https://example.com/wp-json/wp/v2/users管理者ユーザー名が返る場合、探索可能状態です。
autoload
起動時自動読込領域（常駐化ポイント）。
ここに悪性コードが入ると、ページ表示ごとに実行されます。
SELECT option_name, LENGTH(option_value)
FROM wp_options
WHERE autoload='yes'
ORDER BY LENGTH(option_value) DESC
LIMIT 20;異常に長い値や説明不能なoption名は重点確認対象です。
cron
疑似定期実行機構（遅延トリガー）。
削除後に再発する場合、ここに再生成ロジックが残っている可能性があります。
wp cron event list未知のフック名は要調査です。
WP-CLI
WP-CLIはGUIを介さず直接WordPress内部を検査できます。
改ざんが管理画面に影響している場合でも可視化できます。
wp option list --autoload=on
wp user list --role=administrator意図しない管理者増加は即対応です。
シリアライズ構造
文字列長依存の保存形式。
単純置換すると復元不能になり、サイト全体が不安定化します。
- phpMyAdminで直接編集しない
- WP-CLIのsearch-replaceを使用する
wp search-replace '置換前の文字列' '置換後の文字列' --preciseホスティング会社はどう動くのか
エックスサーバー実例
実際に改ざんが検知された場合、エックスサーバーでは以下のような対応が行われます。
① ログ解析による改ざん検知
- access_log / error_log を元に不審なPOST通信を検出
- wp-admin や wp-json への異常アクセスを抽出
- 大量POSTや未知のPHP実行を確認
ここで改ざんの痕跡が確認されると、対象ファイルを特定する。
② 改ざんファイルの隔離（Permission 000）
特定されたPHPファイルは
chmod 000 suspicious.phpのような処理が行われる。
000 とは何か
- 読み取り不可
- 書き込み不可
- 実行不可
つまり完全遮断状態。
攻撃コードが動作しないようにするための一次封鎖措置である。
これは削除ではなく、証拠保全を優先した「実行停止処理」です。
③ 事後報告メール
サーバー会社から
- 改ざん検知日時
- 対象ファイルパス
- パーミッション変更実施
- 復旧対応の案内
が通知されます。
ここで重要なのは、
「なぜそのファイルが改ざんされたのか」は通知されない
という点。
原因究明は利用者側の責任になる。
④ 想定される内部オペレーション（推察）
サーバー運用はマニュアル化されている可能性が高く、推測される流れは以下になっている模様です。
- IDS / WAFログ監視
- 改ざんシグネチャ検知
- ファイル整合性チェック（ハッシュ比較）
- 異常ファイル抽出
- chmod 000 による封鎖
- 通知メール送信
ここで終了するため、根本原因の除去までは実施されません。
⑤ 重要な理解
サーバー会社は
- 被害拡大を止める
- 他ユーザーへ影響を出さない
ことが目的であり、
あなたのWordPressを完全復旧させることは目的ではない。
だからこそ、ログを読める力が必要になる。
サーバー会社の対応から学べること
ホスティング会社の動きは、実は教科書である。
- ログ確認
- 異常検出
- 封鎖
- 通知
この順番は、あなたが復旧するときの順番でもあります。
違うのは一つ。
彼らは止血する。
あなたは原因を潰す。
WordPressの侵入対応において、最も重要なのは「削除」ではなく構造の理解です。
改ざんファイルを消すだけでは、制御は戻りません。
侵入は「偵察 → 侵入 → 永続化 → 外部通信」という層構造で進行します。
autoloadやcronに仕込まれた再生成ロジックを処理しなければ、再発は必然です。
フォレンジックとは、過去を調べる行為ではありません。未来を制御可能状態に戻す設計行為です。
ログを読み、差分を確認し、順序を守る。それが設計者としての復旧です。
次回は
「第7回：届かないメールとインフラ」をお届けします。
Gmailの新しい基準以降、メールは「送る」だけでは届きません。
なぜ届かないのか。
どこで止まるのか。
どうすれば信頼されるのか。
DNS設定、SPF・DKIM・DMARC、
サーバーの評価（レピュテーション）まで、
仕組みから解説します。
テストでは届くのに本番で届かない理由も、ログをもとに整理します。
なんとなく設定から卒業したい人へ。お楽しみに。
もし、あなたのサイトで「削除したのに戻る」「原因が説明できない」といった現象があれば、今回のチェック項目を実行してみてください。
あなたのお悩みを解消するために全力でサポートします！
ABOUT ME
あなたのお仕事をする時間を使ってITに関することを調べたり、トライしてみたりして、それでもうまくいかない。そんなことはありませんか？
WEB先案内をご利用いただくと、困ったときにITの顧問としてあなたのITに関するお悩みにお答えし、サポートを行うことができます。
