PHPファイルのeval・base64_decodeは不正コード？安全な確認方法

PHPファイルを開いた時に、evalやbase64_decodeを見つけると、
「これは不正コードではないか」と不安になるはずです。

結論から言うと、関数名があるだけでは感染確定ではありません。
ただし、外部入力を復号して実行する流れなら、緊急度は非常に高くなります。

よこやま良平

20年以上ITエンジニアとしてPHPとWordPressの制作・復旧に携わっている、よこやま良平です。多数の復旧現場で、正常な処理を消した事故と、不正コードを見逃した再感染の両方を見てきました。

大切なのは、検索で見つけた危険語の一覧だけで決めないことです。
コードが「どこから値を受け取り、何へ変換し、最後に何をするか」を追います。

この記事では、疑わしいファイルを本番サイトやブラウザで動かさず、
静的に確認する順序を初心者向けに整理します。

【無料プレゼント】
WordPress緊急チェック50

「自分のサイトは今、安全なのか？」
自信を持って答えられますか？

こんなお悩みはありませんか？

• ある朝、サイトを開いたら真っ白画面になっていた
• 管理画面にログインできなくなって手が止まった
• 身に覚えのない記事やページが勝手に増えていた
• プラグインを更新したらサイト全体が崩れてしまった
• 以前バックアップを取ったか自分でも覚えていない

累計1,000件以上のWordPressトラブル対応の経験から、「壊れる前に備える」ためのチェックリストを1冊にまとめました。
ログイン・本体・バックアップ・サーバー・運用の5分野を、50項目で「危険度・確認方法・対処法」まで解説しています。

セキュリティプラグイン・WordPressの教科書も含めた3大特典を、
今なら無料で受け取れます。

今すぐ無料ダウンロードする →

※登録後すぐにメールで特典をお届けします

eval・base64_decodeだけで不正コードと断定しない

最初の結論は、関数名ではなく処理の目的とデータの流れで判断することです。
どちらも正規のPHP関数ですが、攻撃コードでも悪用されやすい性質があります。

base64_decodeは文字列を元へ戻す関数

base64_decodeは、Base64形式の文字列を元のデータへ戻します。
画像やAPIデータ、メール添付、設定値の受け渡しなど、正常な用途でも使われます。

Base64は暗号化ではなく、バイナリを文字として扱いやすくする符号化です。
この関数が1回あるだけでマルウェアとは言えず、復号後の用途まで見る必要があります。

evalは文字列をPHPコードとして評価する関数

evalは、渡された文字列をPHPコードとして評価します。
入力内容によって実行結果が変わるため、設計上の危険が大きい関数です。

古い製品や自動生成コードに残っている場合はありますが、
現代のWordPress拡張では、明確な理由がなければ避けるべき実装です。

マルウェアでよく使われるファイル名や配置場所も、補助的な手掛かりになります。
代表例は、次の記事で全体像を確認できます。

WordPressでよく見つかるマルウェアファイル名一覧と安全な削除方法｜感染時の初動と復旧手順

PHPファイルを確認する前に証拠を保全する

疑わしいPHPを見つけたら、編集や削除より先に原本と周辺情報を保存します。
先に消すと、侵入経路、実行時刻、再発原因を追えなくなるためです。

ファイル本体とメタ情報をセットで残す

保存対象はファイルだけではありません。フルパス、更新時刻、所有者、権限、
容量、SHA-256ハッシュを記録し、アクセスログの対象期間も退避します。

ls -lT /path/to/suspicious.php
shasum -a 256 /path/to/suspicious.php
file /path/to/suspicious.php
cp -p /path/to/suspicious.php /safe/evidence/

証拠用コピーは、公開ディレクトリの外へ保存してください。
難しい場合はサーバー会社へ連絡し、削除前スナップショットを依頼します。

本番環境で開かずテキストとして読む

ブラウザからURLへアクセスすると、PHPがサーバー上で実行されます。
FTPソフトのプレビューやファイルマネージャーも、動作仕様が不明なら避けます。

感染がまだ確定していない段階では、サイト全体の症状も並行して確認します。
管理者、ファイル、データベース、ログの確認順は次の記事が役立ちます。

WordPressハッキング疑いの確認リスト【未確定向け】

eval・base64_decodeを実行せず安全に確認する7手順

安全な確認は、ファイルの由来から入力・変換・実行先へ順番に線をつなぐ作業です。
途中の1語だけで結論を出さず、7手順を記録しながら進めます。

手順1：設置場所と正規の由来を確認する

WordPress本体なら、同じバージョンの公式配布物と照合します。
プラグインやテーマなら、公式配布元の同一バージョンを安全な端末で取得します。

公式ファイルとハッシュが一致すれば、正規である強い根拠になります。
配布元不明、有料製品の改造版、閉鎖済み製品では追加調査が必要です。

手順2：危険関数を文字列検索する

コピーしたファイルを対象に、危険になりやすい関数を検索します。
文字列検索はコードを実行しないため、最初の静的確認として使えます。

grep -nE 'eval|base64_decode|gzinflate|assert|shell_exec|system|passthru' suspicious.php
grep -nE 'curl_exec|file_get_contents|wp_remote_get|wp_remote_post' suspicious.php

検索結果がゼロでも安全確定ではありません。関数名を分割して結合したり、
可変関数や無名関数で同じ処理を隠したりするコードがあるためです。

手順3：値の入力元を上へたどる

base64_decodeへ渡る変数が、どこで作られたかを追います。
固定の短い設定値と、外部から届く値では危険度がまったく異なります。

手順4：復号結果は隔離環境で文字として確認する

復号が必要でも、本番PHPへ渡して実行してはいけません。
ネットワークを切った解析用環境で、データを文字列として扱う方法を選びます。

初心者が安全な隔離環境を用意できない場合は、無理に復号しない判断が正解です。
原本とハッシュを保存し、専門家へ渡せる状態にします。

手順5：復号後の値が何へ渡るか確認する

最も重要なのは、変換後のデータが最後に何を起こすかです。
画面表示だけか、コード実行、コマンド実行、ファイル書き込みへ進むかを見ます。

INPUT  : fixed value / request / cookie / database / remote server
DECODE : base64_decode / gzinflate / string replacement
SINK   : display / file write / database write / eval / command execution

外部入力から復号を経て、evalやコマンド実行へ直結するなら高危険です。
認証、署名検証、許可リストがないほど、攻撃者に操作される可能性が高まります。

手順6：外部通信と永続化処理を探す

不正コードは攻撃者のサーバーから命令を取得したり、
別のバックドアを作成したりして、削除後も戻れる状態を残します。

未知のドメイン、IP直書き、深夜の定期実行、管理者追加、
PHPファイル生成、wp_optionsへの長い値の保存がないか確認します。

手順7：公式差分と変更履歴で結論を補強する

最後に、公式配布物との差分、更新日時、導入作業、アクセスログを重ねます。
複数の独立した証拠が同じ結論を示すほど、判断の信頼度が上がります。

WordPress全体を調べる場合は、ファイルだけでなくHTML、ユーザー、
データベース、ログまで確認する改ざんチェックも実施してください。

WordPress改ざんチェックの完全手順｜感染の確認方法から復旧・再発防止まで

7手順の結果を調査表へまとめる

確認結果は、ファイルごとに「確認済み」「要調査」「高危険」を記録します。
判定だけでなく、その結論に使ったパス、ハッシュ、公式版、ログ時刻も残します。

同じ不審コードが複数ファイルにある場合は、最初に見つけた1件だけで終わらせません。
同じ文字列、ハッシュ、通信先、作成時刻をキーに、サイト全体を横断検索します。

ハッシュが同じなら同一内容ですが、ハッシュが違っても亜種の可能性があります。
共通する関数列、外部ドメイン、変数の流れも比較すると関連を見つけやすくなります。

調査表には、誰が、いつ、どの方法で確認したかも記録します。
複数人で対応する時に重複操作を防ぎ、後から判断を再現できるためです。

PHP不正コードの危険度を判断する6つの観点

危険度は、単独の特徴ではなく、攻撃に必要な条件がいくつ重なるかで判断します。
入力元、実行先、通信、永続化、公式差分、実行履歴を並べて評価します。

正常コードにあり得る特徴

公式配布物とハッシュが一致し、処理目的が文書化され、
入力が固定値や署名検証済みデータに限定されていれば、正常の根拠になります。

ただし、正常だから設計上安全とは限りません。古いeval実装は、
直ちにマルウェアでなくても、更新版へ交換すべき保守リスクです。

高危険と判断する特徴

この状態では、問題の1ファイルだけを消しても復旧にはなりません。
別の入口、盗まれた認証情報、データベース内の命令が残る可能性があります。

グレーなら安全と決めつけない

配布元不明でも、すぐに危険な動作が見えないファイルはあります。
その場合は「安全」ではなく「要調査」と記録し、実行を止めたまま確認を続けます。

Wordfenceなどのスキャン結果は判断材料になりますが、誤検知と見逃しがあります。
検出名だけで削除せず、公式差分、ログ、コードの流れと組み合わせて判断してください。

「検出されなかったから安全」という結論も危険です。新しい亜種、条件付き実行、
データベースから後で命令を取得する仕組みは、静的スキャンを通過することがあります。

アクセスログの時刻とコードの動きを照合する

コードが危険そうでも、実際に呼び出されたかで被害範囲は変わります。
対象ファイルのURL、POST、応答コード、送信量、接続元をアクセスログで確認します。

200応答が続く、POSTの直後に別ファイルが作られる、管理者が増える場合は、
攻撃者が機能を利用した可能性が高く、情報流出も含めて調査範囲を広げます。

404や403だけでも、攻撃がなかったとは言い切れません。
別名へ変更された後、内部処理から読み込まれた可能性があるため、前後のログも見ます。

サーバー、PHP、WordPressの時刻設定が異なる場合は、先にタイムゾーンをそろえます。
時刻を補正せず並べると、設置より前に実行されたような誤ったタイムラインになります。

典型的な誤判定を避ける

1つ目の誤判定は、長いBase64文字列を見ただけで削除することです。
画像、証明書、正規APIのデータである可能性もあるため、配布元と用途を確認します。

2つ目は、ファイル名が正しそうだから安全と考えることです。
攻撃者はindex.php、functions.php、class名など、自然な名前へ追記します。

3つ目は、更新日時が古いから侵入前の正常ファイルと判断することです。
日時は変更でき、バックアップ復元でも変わるため、ハッシュやログと組み合わせます。

4つ目は、コードを整形すると読めるため安全だと判断することです。
見やすさと正当性は別であり、外部入力から実行先までの流れは変わりません。

5つ目は、ウイルス対策ソフトが警告しないため問題ないと考えることです。
サイト固有のバックドアや短いローダーは、既知パターンに一致しない場合があります。

正しい判断は、関数名、名前、時刻、スキャンのどれか1つへ依存しません。
独立した証拠を重ね、反対の可能性も検討してから対応を決めます。

PHP不正コードを見つけた後は危険度別に対応する

確認後は、正常・要調査・高危険の3段階で対応を変えるのが正解です。
どの段階でも、根拠と操作履歴を残してから次へ進みます。

正常なら根拠と更新方針を記録する

公式ファイルとの一致や提供元の回答で正常と確認できたら、
ファイルのパス、バージョン、ハッシュ、確認日を保守記録へ残します。

evalを使う古い製品なら、代替版や最新版への移行も検討します。
正常判定は「放置してよい」という意味ではなく、更新計画の出発点です。

要調査なら公開領域から隔離する

安全と説明できないが不正確定にも至らない場合は、原本を保全し、
ステージング環境で無効化した時の影響を確認します。

本番で隔離する時は、同じ機能を使うページ、予約処理、決済、フォームを点検します。
機能停止が大きい場合は、先にメンテナンス表示や代替手段を用意します。

高危険ならサイト全体を復旧する

不正と判断したら、サイトを保護し、ファイルとDBの証拠を保存します。
その後、正規ファイルへの交換、認証情報の変更、管理者とcronの点検を行います。

バックアップへ戻すだけでは、侵入日より後の正常データを失ううえ、
バックアップ自体にバックドアが含まれていると再感染します。

WordPress本体は公式配布物、テーマとプラグインは信頼できる配布元から入れ直し、
uploadsなど置き換えられない領域は個別に調査する方法が安全です。

認証情報は、清掃前に一度、復旧完了後にもう一度変更すると、
作業中に残っていた不正処理へ新しい情報を盗まれるリスクを減らせます。

具体的な復旧順序は、改ざん箇所の記録から正規ファイルへの交換、
認証情報の見直しまでを扱う次の記事にまとめています。

WordPressが改ざんされた時の復旧方法｜ログイン不能・マルウェア駆除ガイド

復旧後は再生成と不審通信を監視する

復旧直後に表示が正常でも、潜伏した処理が数時間後や翌日に動くことがあります。
少なくとも数日は、ファイル変更、管理者、cron、外部通信、エラーログを確認します。

削除したパスへのアクセスが続く場合は、攻撃者が入口を再利用しようとしています。
WAFやIP拒否だけで終わらせず、最初に侵入を許した脆弱性や漏えい認証を修正します。

正常な基準ファイルのハッシュを復旧後に保存すると、次回の差分確認が速くなります。
ただし更新時には基準も変わるため、バージョンと取得日を必ずセットで記録します。

更新されていないプラグイン、使っていないテーマ、不要な管理者は削除します。
攻撃面を減らすことが、難読化コードを再び置かせない最も確実な再発防止です。

プラグイン設定だけでなく、更新・バックアップ・緊急復旧まで継続して任せたい場合は、
保守サービス「クイックレスキュー365」の内容も確認してください。

WordPress・サイト保守クイックレスキュー365

eval・base64_decodeの安全確認でよくある質問

よくある疑問も、実行せず、証拠を残し、複数の根拠で判断する原則は同じです。
迷いやすい4点を短く整理します。

判断に迷う時は不明のまま保留する

調査で最も危険なのは、早く終わらせるために安全か不正かを決めつけることです。
根拠が足りないなら「不明」とし、実行を止めた状態で追加情報を集めます。

提供元へ問い合わせる時は、ファイルそのものを無断送信せず、
製品名、バージョン、パス、ハッシュ、該当行の目的を確認してください。

顧客情報や認証情報が含まれる可能性がある場合は、共有先と共有方法を限定します。
公開の掲示板やオンライン解析サービスへ貼り付けないことも重要です。

PHPのeval・base64_decodeは実行せず流れで判断する

PHPのeval・base64_decodeを見つけても、関数名だけで削除してはいけません。
原本を保全し、入力元、変換、実行先、通信、永続化を順番に確認します。

復旧後は更新、認証、バックアップ、ログ監視を継続し、
同じ経路から再侵入されない状態まで確認してください。

WordPressセキュリティ対策の完全ガイド｜初心者でも今日からできる安全設定チェックリスト付き

WordPressの不正アクセス・乗っ取りが自分で直せない時は

ワードプレスのWordPressエラートラブル解決をしたいなら
クイックレスキューが解決します。

これらでお悩みなら最短30分ですぐに解決します！

いまなら期間限定で