WordPressサイトがハッキングされた！原因調査と対策の全記録

マルウェア36件検出から完全復旧まで、実際のインシデント対応記録を公開。ログ調査で判明した攻撃経路と根本対策を詳しく解説

朝一番でメール通知、36件のマルウェア検出の衝撃

「こんな経験ありませんか？」

• セキュリティツールから突然の警告メール
• 自社サイトがマルウェアに感染している可能性
• 何から手を付けていいかわからない状況
• お客様のサイトを預かる責任の重さ

これは昨年12月、弊社が実際に対応したWordPressハッキング事案の記録です。「Web制作会社でもこんなことが起きるのか」と思われるかもしれませんが、現実にセキュリティの脅威は誰にでも降りかかります。

今回は、マルウェア検出から根本原因の特定、そして完全復旧まで。包み隠さず全てをお話しします。同じような状況に直面した時、きっとお役に立てるでしょう。

発生した事象：Imunifyが検出した36件の脅威

12月27日朝、Imunifyセキュリティツールから警告メールが届きました。内容を見て背筋が凍りました。

検出されたマルウェアの内容

検出された脅威の詳細：

1. htaccess.spam.redi（20件）

   • .htaccessファイルを改ざんしてスパムサイトにリダイレクト
   • 検索エンジンからのアクセスを別サイトに誘導

2. php.bkdr.wshll（ウェブシェル）

   • リモートからサーバーを操作するバックドア
   • ファイルの作成・削除・編集が可能

3. php.bkdr.drpr（ドロッパー）

   • 他のマルウェアをダウンロードして設置
   • 感染拡大の起点となる

4. php.bkdr.fm（ファイルマネージャー）

   • ブラウザ経由でファイル操作を可能にする
   • 正規のツールに偽装されることが多い

5. php.tool.upldr（アップローダー）

   • 任意のファイルをサーバーにアップロード
   • さらなるマルウェア設置に利用

「20年間Web制作をやってきて、これほど大規模な感染は初めてでした。しかし、パニックになっては解決しません。まずは冷静に原因を調査することから始めました。」

ログ調査で判明した攻撃の全容

アクセスログから見えた攻撃パターン

サーバーにアクセスできるようになったため、Apache/Nginxのアクセスログを詳細に調査しました。

# XMLRPCへのPOSTリクエストを抽出
grep "POST.*xmlrpc.php" /var/log/nginx/access.log | head -20

# 特定IPからのアクセスを確認
grep "194.87.10.143" /var/log/nginx/access.log | tail -50

# 疑わしいPHPファイルへのアクセスを調査
grep -E "(wp-links|widgets|maint)" /var/log/nginx/access.log

攻撃経路の詳細分析

1. XMLRPCブルートフォース攻撃

ログを見ると、xmlrpc.phpに対して異常な数のPOSTリクエストがありました：

185.220.xxx.xxx - [27/Dec/2023:02:15:43] "POST /xmlrpc.php HTTP/1.1" 200 403
194.87.10.143 - [27/Dec/2023:02:16:11] "POST /xmlrpc.php HTTP/1.1" 200 118
# （同様のリクエストが数千件続く）

2. 既存バックドアからの侵入

12月27日3時24分、ロシアのIPアドレスから既存のバックドアファイルにアクセスがありました：

194.87.10.143 - [27/Dec/2023:03:24:17] "GET /wp-admin/maint/widgets/index.php HTTP/1.1" 200 0
194.87.10.143 - [27/Dec/2023:03:30:22] "POST /wp-admin/maint/widgets/wp-links.php HTTP/1.1" 200 156

3. 中国の自動スキャンツール

refererヘッダーから、http://www.openurls.com.cn/という中国の自動スキャンツールが関与していることが判明しました。これは脆弱性のあるサイトを自動的に探すツールです。

完全復旧への対応手順

ステップ1：感染サイトの隔離

まず、感染したサイトを隔離して被害拡大を防ぎます：

# サイトを一時的に停止
sudo systemctl stop nginx

# 感染ファイルのバックアップ（証拠保全のため）
sudo cp -r /var/www/infected-site /backup/evidence/$(date +%Y%m%d)

# データベースのダンプも取得
mysqldump -u username -p database_name > /backup/evidence/db_$(date +%Y%m%d).sql

ステップ2：マルウェアファイルの完全除去

Imunifyで検出されたファイルを一つずつ確認し、除去していきます：

# 検出されたPHPバックドアファイルを確認
cat /wp-admin/maint/widgets/index.php
# → 確実にマルウェアと確認できたら削除
rm /wp-admin/maint/widgets/index.php

# .htaccessファイルの復元
# バックアップから正常な.htaccessを復元
cp /backup/clean/.htaccess /var/www/site/.htaccess

# WordPressコアファイルの整合性チェック
wp core verify-checksums --path=/var/www/site/

ステップ3：XMLRPCの無効化

今回の侵入経路だったXMLRPCを完全に無効化します：

# .htaccessに追加
<Files "xmlrpc.php">
    Require all denied
</Files>

# またはNginxの場合はserver設定に追加
location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
    return 444;
}

ステップ4：セキュリティ強化策の実装

WordPressセキュリティプラグインの導入

// Wordfenceプラグインをインストール
wp plugin install wordfence --activate --path=/var/www/site/

// セキュリティ設定を強化
wp option update wordfence_blocked_time 3600 --path=/var/www/site/

管理者パスワードの変更

# 全ユーザーの強制パスワード変更
wp user list --path=/var/www/site/
wp user update admin --user_pass="$(openssl rand -base64 32)" --path=/var/www/site/

よくある失敗パターンと対処法

失敗パターン1：感染ファイルの見落とし

「マルウェアを削除したつもりが、実は隠れファイルが残っていた」

これは本当によくある失敗です。私たちも最初の清掃で数個見落としがありました。

対処法：

# 隠しファイルも含めて全検索
find /var/www/site/ -name ".*" -type f -exec ls -la {} \;

# 最近更新されたPHPファイルを確認
find /var/www/site/ -name "*.php" -mtime -7 -exec ls -la {} \;

# 疑わしいファイル内容を検索
grep -r "eval(" /var/www/site/ --include="*.php"
grep -r "base64_decode" /var/www/site/ --include="*.php"

失敗パターン2：データベース内のマルウェアを見逃す

「ファイルは清掃したのに、まだリダイレクトが起きる」

データベース内のoptions テーブルやposts テーブルにマルウェアコードが仕込まれている場合があります。

対処法：

-- WordPress options テーブル内の疑わしいコードを検索
SELECT * FROM wp_options WHERE option_value LIKE '%base64%';
SELECT * FROM wp_options WHERE option_value LIKE '%eval(%';

-- 投稿内容に仕込まれたコードも確認
SELECT * FROM wp_posts WHERE post_content LIKE '%<script%';

失敗パターン3：根本原因を放置したまま復旧

「とりあえずマルウェアを削除して終わり」では、同じ攻撃を受ける可能性が高いです。

根本対策：

• XMLRPCの無効化
• 不要なWordPressサイトの完全削除
• 定期的なセキュリティ監査
• アクセスログの継続的な監視

予防策：二度と同じ被害を受けないために

多層防御の実装

flowchart TD
    A[インターネット] --> B[WAF/Cloudflare]
    B --> C[Nginx/Apache]
    C --> D[WordPress + Wordfence]
    D --> E[ファイル権限設定]
    E --> F[データベース]
    
    G[定期バックアップ] --> D
    H[ログ監視] --> C
    I[セキュリティ監査] --> D

継続的な監視体制

ログ監視の自動化

#!/bin/bash
# daily_security_check.sh

# XMLRPCへの異常なアクセスをチェック
xmlrpc_count=$(grep "POST.*xmlrpc.php" /var/log/nginx/access.log | grep $(date +%d/%b/%Y) | wc -l)

if [ $xmlrpc_count -gt 100 ]; then
    echo "Alert: Unusual XMLRPC activity detected: $xmlrpc_count requests" | mail -s "Security Alert" [email protected]
fi

# 新しいPHPファイルの作成をチェック
find /var/www/ -name "*.php" -mtime -1 | while read file; do
    echo "New PHP file detected: $file" | mail -s "New File Alert" [email protected]
done

セキュリティ設定の最適化

# wp-config.phpのセキュリティ強化
<Files "wp-config.php">
    Require all denied
</Files>

# 管理画面への国外からのアクセス制限
<LocationMatch "/wp-admin">
    Require ip 192.168.0.0/16
    Require ip YOUR_OFFICE_IP
</LocationMatch>

まとめ：インシデント対応から学んだ教訓

今回のハッキング事案を通じて、改めて実感したのは「完璧なセキュリティは存在しない」ということです。しかし、適切な対策と監視体制があれば、被害を最小限に抑え、迅速に復旧することは可能です。

対応で効果的だった施策：

重要なポイント：

1. 早期発見の重要性 - Imunifyのようなセキュリティツールの導入は必須
2. ログ分析スキル - 攻撃パターンを理解することで根本原因を特定
3. 包括的な清掃 - ファイルシステムとデータベース両方の確認
4. 予防策の実装 - 単なる復旧ではなく、再発防止まで考慮
5. 継続的監視 - 一度の対策で安心せず、継続的な改善を

次に取るべきアクション

もし現在、似たような状況でお困りの場合は、お気軽にご相談ください。20年の経験を活かし、迅速かつ的確なサポートを提供いたします。

セキュリティは一度設定したら終わりではありません。継続的な改善と監視が必要です。しかし、正しい知識と対策があれば、必ず守り抜くことができます。

今回の記録が、同じような問題に直面した方の助けになれば幸いです。