マルウェアチェックの方法｜閲覧者・運営者別の確認と改ざん検知

セキュリティ 公開 2026-10-06　/　最終確認 2026-10-06　/　サイトスカウター編集部

「このサイトは安全か」「自分のサイトが改ざんされていないか」。マルウェアチェックの目的は、閲覧者と運営者で異なります。閲覧者は、Googleのセーフブラウジング サイトステータスなどで危険の兆候を確認し、警告が出たサイトは開かない・ダウンロードしないのが基本です。運営者は、Search Consoleのセキュリティの問題の通知と、サーバー上のファイル変更・ログの確認を組み合わせて検知します。

この記事では、改ざんの典型症状、閲覧者向けの確認手順、運営者向けの具体的なコマンド例、感染時の初動と再審査、予防策を順に解説します。内容は、Google、警察庁、IPA、JPCERT/CCの公開資料に基づいています(最終確認日: 2026-10-06)。

なお、サイトスカウターの/server/で調べられるのは、HTTPS・ヘッダーなどの外から見える設定とブラックリスト掲載です。ファイルの中身を検査するものではない点は、最後の章で説明します。

目次
1. マルウェアとは？サイト改ざんの典型的な症状 2. 【閲覧者向け】このサイトは安全か？マルウェアチェックの確認手順 3. 【運営者向け】サイト改ざんの兆候とSearch Consoleでの確認 4. ファイルの変更検知とログ確認のコマンド例 5. 改ざん・感染が分かったときの初動と復旧、再審査 6. サイト改ざんを防ぐ予防策：更新・最小権限・WAF・バックアップ 7. サイトスカウターの/server/でサイトのセキュリティ診断をする よくある質問 出典・参考資料

マルウェアとは？サイト改ざんの典型的な症状

「マルウェア」は、利用者の意図に反して不正な動作をするソフトウェアの総称です。ウイルス、ランサムウェア、情報を盗むスパイウェアなどを含みます。Webの世界では、サイトそのものが改ざんされ、訪れた人にマルウェアを配る入口になるケースがあります。つまり「マルウェアチェック」には、閲覧者として「このサイトは安全か」を確かめる場合と、運営者として「自分のサイトが改ざん・感染していないか」を確かめる場合の2つがあります。

サイト改ざんとは、第三者が無断でWebサイトのファイルやデータベースの内容を書き換えることです。警察庁は、改ざんの主な手口として、盗まれたアカウント情報による不正アクセス、ソフトウェアの脆弱性の悪用、アクセス制御の不備の悪用を挙げています。IPAとJPCERT/CCも、サーバーソフトウェアの脆弱性や、サイト更新に使う端末の管理を注意喚起しています。

改ざん・感染の典型的な症状

  • 見覚えのないページ、ファイル、管理者アカウントが増えている
  • 特定の条件(スマホから、検索結果から来た場合など)でだけ、別のサイトへ転送される
  • 検索結果のタイトルや説明文が、自分が設定した覚えのない文字列(意味不明な文字、無関係な商品名など)に変わっている
  • ブラウザや検索結果に「危険なサイト」「ハッキングされている可能性」といった警告が出る
  • ページを開くと、身に覚えのないファイルのダウンロードやポップアップが始まる
  • サーバーの負荷や外向き通信が、アクセス数に見合わず急に増える

Googleは、サイト側の問題を大きく「ハッキングされたコンテンツ」「マルウェアおよび望ましくないソフトウェア」「ソーシャルエンジニアリング(フィッシングなど)」の3つに分類しています。以降は、立場別に確認手順を説明します。

【閲覧者向け】このサイトは安全か？マルウェアチェックの確認手順

閲覧者の立場で確かめられるのは、あくまで「危険の兆候が見つかるか」です。「何も見つからない」ことは「安全の証明」ではありません。新しく作られた攻撃サイトは、どの確認サービスにもまだ載っていないことがあるためです。複数の方法を重ねて判断してください。

1. まずURLとドメインを見る

アクセスする前に、ドメイン名が本物と一字違いではないか、メールやSMSのリンクから来ていないかを確認します。偽サイトの見分け方は偽サイトの見分け方で詳しく解説しています。鍵マーク(HTTPS)は通信が暗号化されているという意味で、サイトの運営者が信頼できることを示すものではありません。

2. Googleセーフブラウジングのサイトステータスで調べる

Googleは、危険なサイトやファイルを検出して警告する「セーフブラウジング」を提供しており、Chromeなどのブラウザ、Google検索、Gmailなどで使われています。Googleの透明性レポートにある「セーフブラウジング サイトステータス」にURLやドメインを入力すると、そのサイトで危険なコンテンツが最近検出されたかを確認できます。ここで警告が出ていれば、アクセスは避けてください。

3. ブラウザの警告画面の意味を知っておく

セーフブラウジングが扱う脅威は、大きく次の3種類です。

  • マルウェア: 端末に害を与えたり、情報を盗んだりするソフトウェアを配布している
  • 望ましくないソフトウェア: ブラウザの設定を勝手に変えるなど、利用者を欺く動作をするプログラム
  • ソーシャルエンジニアリング: フィッシングなど、パスワードやカード情報を入力させようとする偽装

全画面の警告が出た場合は、詳細から進む操作をせず、タブを閉じてください。運営者本人が改ざんに気づいていないだけのこともありますが、閲覧者側からそれを見分ける手段はありません。

4. 不審なサイトでは「開かない・ダウンロードしない・入力しない」

確認の結果に関わらず、次の行動は避けてください。

  • 実行ファイル(.exe、.msi、.scr)、スクリプト(.js、.vbs)、ショートカット(.lnk)、マクロ付きのOffice文書を、出どころが不明なまま開く
  • 「ウイルスに感染しています」「更新が必要です」などの画面の指示に従ってソフトを入れる
  • ログイン情報やカード番号を、リンク先で初めて見たフォームに入力する

すでに開いてしまった場合は、ネットワークから切り離し、セキュリティソフトで全体検査をかけ、そのサイトで入力したパスワードは別の端末から変更してください。迷ったときは、IPAの情報セキュリティ安心相談窓口などの公的な窓口に相談できます。ブラウザで証明書の警告が出る場合は、「プライバシーエラー」の原因と対処も参考になります。

図1　不審なサイトでの行動
×　避ける行動×警告を無視して進む×出どころ不明のファイルを開く×画面の指示でソフトを入れる×初見のフォームに入力する○　取るべき行動○タブを閉じる○サイトステータスで再確認○公式サイトから入り直す○不安なら公的窓口に相談

【運営者向け】サイト改ざんの兆候とSearch Consoleでの確認

運営者にとって怖いのは、自分では気づかないまま改ざんが続くことです。攻撃者は、管理者が見ない条件(検索エンジン経由の訪問者だけ、スマホだけなど)でのみ悪意のあるコードを動かし、発見を遅らせることがあります。次の兆候を定期的に確認してください。

画面や検索結果で気づく兆候

  • 検索結果の文字化け・見覚えのない文言: Googleで「site:自分のドメイン」と検索し、タイトルや説明文に無関係な言葉が混じっていないか見ます。実際のページは正常に見えても、検索エンジンのクローラーにだけ別の内容を見せる細工(クローキング)が入っていることがあります
  • リダイレクト: 検索結果から自分のサイトを開いたときだけ別サイトに飛ばされる場合は、改ざんの典型です。シークレットウィンドウやスマホ回線でも確認します
  • 見覚えのないファイル・ページ・ユーザー: 更新した覚えのないファイル、アップロード用ディレクトリ内のPHPファイル、増えた管理者アカウントは要注意です
  • Search Consoleのセキュリティ問題: Search Consoleの「セキュリティと手動による対策」にある「セキュリティの問題」には、ハッキングされたコンテンツ、マルウェア、ソーシャルエンジニアリングといった検出結果が表示されます。未登録なら、まず所有権を確認して登録しておくのが、最も費用のかからない見張りになります

Search Consoleが検出する内容

Googleのヘルプでは、検出される種類として、コードインジェクション(悪意あるリダイレクトなど)、コンテンツインジェクション(スパム的なリンクやテキストの挿入)、URLインジェクション(スパム目的で新しいページが勝手に作られる)などが挙げられています。該当する場合は、通知されたURLの例を手がかりに、同じ細工が他のページにも入っていないか調べます。

図2　改ざんチェックリスト
検索結果site:検索で無関係な語がない転送検索経由・スマホで転送されないファイル覚えのない新規ファイルがないアップロード先画像用の場所にPHPがない管理者身に覚えのないユーザーがいないSearch Consoleセキュリティの問題が0件アクセスログ不審なPOSTや集中がない

ファイルの変更検知とログ確認のコマンド例

SSHで入れるLinuxサーバー(Apache/Nginx)を前提に、そのまま実行できる確認コマンドを紹介します。/var/www/htmlは公開ディレクトリ(ドキュメントルート)に読み替えてください。いずれも読み取りだけの操作ですが、本番環境では念のため対象範囲を確認してから実行してください。共用レンタルサーバーなどSSHが使えない場合は、FTPクライアントやサーバーの管理画面で更新日時の新しい順に並べても、近い確認ができます。

最近変更されたファイルを探す(find)

-mtime -7は「変更から7日未満」を意味します。

# 直近7日以内に変更されたファイルを新しい順に表示
find /var/www/html -type f -mtime -7 -printf '%TY-%Tm-%Td %TH:%TM  %p\n' | sort -r | head -50

# 日付を指定して、それ以降に変更されたファイルを探す
find /var/www/html -type f -newermt "2026-10-01" -printf '%TY-%Tm-%Td %TH:%TM  %p\n' | sort -r

置かれるはずのない場所のPHPや、疑わしいコードを探す(find / grep)

画像のアップロード先にPHPファイルがあるのは典型的な不審点です。また、難読化されたコードを実行する書き方は、悪意のあるコードで多用されます(正規のプラグインが使う場合もあるので、見つかったらファイルの中身を確認してください)。

# アップロード用ディレクトリにあるPHPファイル(WordPressの例)
find /var/www/html/wp-content/uploads -type f -name "*.php"

# 難読化したコードを実行する典型的な書き方を含むPHPを探す
grep -rIlE "eval\(base64_decode|gzinflate\(base64_decode|str_rot13\(" --include="*.php" /var/www/html

# 難読化JavaScriptの痕跡
grep -rIlE "document\.write\(unescape|String\.fromCharCode" --include="*.js" --include="*.php" --include="*.html" /var/www/html

.htaccessの不審な転送ルールを確認する

検索エンジンや特定のリファラー(参照元)だけを別サイトへ飛ばす設定が、.htaccessに書き込まれることがあります。

# .htaccess を探して直近30日以内に変更されたものを表示
find /var/www/html -name ".htaccess" -mtime -30 -ls

# User-Agent や Referer を条件にした書き換えルールを確認
grep -rnE "RewriteCond +%\{HTTP_(USER_AGENT|REFERER)\}" /var/www/html --include=".htaccess"

検索エンジンにだけ別の内容を見せていないか確認する(curl)

通常のブラウザと、Googlebotを名乗るリクエスト、検索結果からの訪問を装うリクエストで、応答を比べます。自分のサイトに対してだけ使ってください。

URL=https://example.com/
# 通常アクセス
curl -s -o /dev/null -w "通常: %{http_code} %{redirect_url}\n" "$URL"
# Googlebot を名乗るアクセス
curl -s -o /dev/null -w "bot : %{http_code} %{redirect_url}\n" -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" "$URL"
# Google検索からの訪問を装うアクセス
curl -s -o /dev/null -w "検索: %{http_code} %{redirect_url}\n" -e "https://www.google.com/" "$URL"

結果のステータスやリダイレクト先が食い違えば、条件付きの転送や出し分けが仕込まれている可能性があります。

WordPressなら公式ファイルとの差分を検証する(WP-CLI)

# コア・プラグインのファイルを、配布元のチェックサムと照合
wp core verify-checksums
wp plugin verify-checksums --all

# 管理者ユーザーの一覧(見覚えのないアカウントがないか)
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

# 投稿本文に埋め込まれたscriptタグを確認
wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%' LIMIT 20;"

テーブル接頭辞がwp_以外の場合は読み替えてください。

正常な状態のハッシュ値を保存しておき、後で比較する

更新日時は攻撃者が書き換えられるため、日時だけに頼ると見逃します。改ざんされていない状態で一度ハッシュ値の一覧を作り、サーバーの外に保管しておくと、後から1ファイル単位で差分を検出できます。

# 基準を作る(正常な状態で1回だけ。キャッシュ等の更新が多い場所は除外)
find /var/www/html -type f -not -path "*/cache/*" -print0 | sort -z | xargs -0 sha256sum > ~/baseline.sha256

# 後日の確認(変化したファイルだけが FAILED と表示される)
sha256sum -c --quiet ~/baseline.sha256

新規に追加されたファイルはsha256sum -cでは出ないので、findの結果と基準の一覧を比べます。

アクセスログで不審なアクセスを探す

Apacheのcombined形式のログを例にします(ログの場所は環境で異なり、Debian/Ubuntuでは多くの場合/var/log/apache2/access.logです)。

LOG=/var/log/apache2/access.log

# POSTを受けたURLの上位(管理画面以外に偏りがあれば要確認)
awk '$6=="\"POST"{print $7}' "$LOG" | sort | uniq -c | sort -rn | head -20

# PHPへのPOSTをIPごとに集計
grep "POST" "$LOG" | grep -E "\.php" | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

# 特定のIPが何を要求したか(203.0.113.10は例示用のIP)
grep "^203.0.113.10 " "$LOG" | head -50

ログは、改ざんの入口を特定する最大の手がかりです。保存期間が短い設定のままだと原因が追えなくなります。IPAの20ヶ条でも、ログの保管と定期的な確認が対策として挙げられています。

改ざん・感染が分かったときの初動と復旧、再審査

改ざんやマルウェア感染が分かったら、目に付く部分だけを慌てて直すのは避けてください。侵入経路を残したまま見た目だけ直すと、再び改ざんされます。次の順で進めるのが基本です。

1. 証拠の保全(ログとコピー)

警察庁は、改ざんを発見した場合に、アクセスログを保存してから最寄りの警察に通報するよう案内しています。サーバーのログと、改ざんされた状態のファイル・データベースを別の場所へ保存しておきます。復旧前に消してしまうと、原因を調べられなくなります。

2. 隔離(公開を止める)

被害の拡大を防ぐため、メンテナンスページへ切り替える、または公開を一時停止します。同じサーバーに複数のサイトがある場合は、他のサイトにも感染が及んでいないか調べます。JPCERT/CCは、CMSの脆弱性から侵入され、同一サーバー上の複数サイトが同時に改ざんされる事例を取り上げています。

3. パスワード・鍵の変更

警察庁は、攻撃者にアクセスされた可能性のある機器のパスワードを速やかに変更するよう案内しています。変更対象は、CMSの管理者、FTP/SSH、データベース、ホスティングの管理画面、APIキー、SSH鍵です。端末側の感染も疑い、変更はクリーンな端末から行ってください。

4. 原因の特定

前の章のコマンドとアクセスログで、侵入経路を探します。古いCMSやプラグインの脆弱性、流出したパスワード、不要に公開された管理画面などが典型です。原因を塞がないままの復旧は、再発を招きます。

5. 復旧

改ざん前の正常なバックアップがあれば戻すのが確実です。Googleも、直前の正常なバックアップへ戻す方法か、スパムのコンテンツやリンクを各ページから取り除く方法を示しています。バックアップが「感染後」のものでないか、日付を必ず確認してください。復旧後は、OSやCMS、プラグインを最新にします。Googleは、一部のページだけを直しても警告は解除されず、サイト全体で修正する必要があると説明しています。

6. 再審査のリクエスト

Search Consoleの「セキュリティの問題」から審査をリクエストし、何が問題だったか、どう直したかを具体的に書きます。Googleのヘルプによると、マルウェアの審査は数日、スパムを含むハッキングされたサイトは数週間かかる場合があります。審査結果が出る前の再送信は、かえって処理を遅らせる可能性があるため避けてください。

相談・届け出先

最寄りの警察への通報のほか、JPCERT/CCはWebサイト改ざんなどのインシデント報告を受け付けています。自力での対応が難しい場合は、IPAの情報セキュリティ安心相談窓口や、ホスティング事業者のサポートにも連絡してください。

図3　改ざん発覚後の初動
1ログ・現状を保全2公開を止め隔離3パスワード変更4侵入原因を特定5正常な状態へ復旧6Googleへ再審査

サイト改ざんを防ぐ予防策：更新・最小権限・WAF・バックアップ

改ざんの多くは、更新されていないソフトウェアや弱い認証が入口になります。IPAの「安全なウェブサイトの運用管理に向けての20ヶ条」は、対策を「ウェブアプリケーション」「ウェブサーバー」「ネットワーク」「その他」に分けて整理しており、どれが欠けても安全性は確保できないという考え方です。実務では、次の4点から手を付けると効果が大きくなります。

  • 更新を止めない: OS、Webサーバー、CMS本体、テーマ、プラグインを最新に保ち、サポートが終わった製品は移行します。使っていないプラグインやテスト用ページは削除します
  • 最小権限: 管理画面とSSH/FTPのパスワードを使い回さず、二要素認証を有効にします。サイト更新に使える端末やIPを絞り、ファイルの書き込み権限も必要な場所だけにします
  • WAF(Webアプリケーションファイアウォール): 既知の攻撃パターンを入口で遮断する仕組みです。脆弱性の修正が間に合うまでの時間稼ぎとして有効ですが、更新の代わりにはなりません
  • バックアップ: 世代を分けて、サーバーとは別の場所に保管します。実際に復元できるかも試しておきます

あわせて、サーバー側のセキュリティヘッダーやHTTPSの設定を見直すのも有効です。詳しくはHSTSとHTTPSの解説をご覧ください。

図4　改ざん予防の4つの層
バックアップ最後の砦。別の場所に世代保管WAF既知の攻撃を入口で遮断最小権限認証の強化と更新者の限定更新管理脆弱性を残さない土台

サイトスカウターの/server/でサイトのセキュリティ診断をする

サイトスカウターのサーバー情報調査は、URLまたはドメインを入力すると、公開されている情報だけを非侵襲的に調べます(DNS照会、WHOIS、TLSハンドシェイク1回、HTTP GET 1回など)。ポートスキャンや脆弱性の探索は行いません。調べられる項目は次のとおりです。

  • HTTPSと証明書: HTTPS対応、証明書の有効性(期限切れ・自己署名・ホスト名の不一致)、残り日数、認証レベル
  • セキュリティヘッダー: HSTS、CSP、X-Frame-Options、X-Content-Type-Options、Referrer-Policy、Permissions-Policyの有無
  • Cookieの属性: Secure、HttpOnly、SameSiteの付け忘れ
  • バージョン情報の露出: ServerやX-Powered-Byヘッダーにソフトウェアのバージョンが出ていないか
  • ブラックリスト(DNSBL): ドメイン向け(Spamhaus DBL、SURBL)とIP向けのリストを照会し、掲載の有無を確認
  • サーバーの所在地、IP保有者、DNSレコード、WHOIS、HTTPヘッダー

/server/はサイトのファイルの中身をスキャンするマルウェア検査ツールではありません。改ざんされたファイルや不正なスクリプトそのものを見つけることはできません。役割は、外から見える設定の弱点(HTTPS、ヘッダー、バージョン露出)と、ブラックリストへの掲載を手早く確認することです。前者は侵入されにくくするための点検、後者は既に悪い評判がついていないかの確認に使えます。ファイル内部の検査は、本記事のコマンドやセキュリティ製品、Search Consoleと併用してください。

DNSBLの掲載は、メール送信元の評判を主とするリストが多く、マルウェア感染そのものを示すわけではありません。掲載の意味や解除についてはブラックリスト確認の方法を参照してください。

サイトスカウターで調べる

自サイトのHTTPS・セキュリティヘッダー・ブラックリスト掲載を手早く点検したいときは、サイトスカウターのサーバー情報調査をお試しください。ファイル内部の検査はできませんが、外から見える弱点の確認に使えます。

サーバー情報調査を使う
DNSBLチェッカーのトップページ
DNSBLチェッカーで掲載状況を一括確認

IPアドレスまたはドメインを入力するだけで、約345件のDNSBLを一括で照会できます。完全無料・登録不要・回数制限なしです。

DNSBLチェッカーを使う

よくある質問

マルウェアに感染しているかをサイトのURLだけで調べられますか？

完全には調べられません。Googleのセーフブラウジング サイトステータスでURLを入力すると、危険なコンテンツが最近検出されたかを確認できますが、結果に表示が無くても安全の証明にはなりません。新しい攻撃サイトはまだ登録されていない場合があるため、ドメイン名の確認や、警告画面が出たら進まないといった基本動作と併用してください。

ブラウザに危険なサイトの警告が出たらどうすればよいですか？

警告を無視して進まず、タブを閉じてください。セーフブラウジングの警告は、マルウェアの配布、望ましくないソフトウェア、フィッシングなどのソーシャルエンジニアリングのいずれかが検出された場合に表示されます。自分が運営するサイトで出た場合は、Search Consoleのセキュリティの問題を確認し、改ざんの調査と復旧を進めてください。

自分のサイトが改ざんされたとき、最初に何をすべきですか？

まずアクセスログと改ざんされた状態のファイルを保存し、公開を止めて被害を拡大させないようにします。そのうえで、管理者やFTP、データベースなどのパスワードをクリーンな端末から変更し、侵入原因を特定してから復旧します。警察庁は、ログを保存したうえで最寄りの警察へ通報するよう案内しています。

Googleの警告が解除されるまでにどれくらいかかりますか？

Googleのヘルプによると、マルウェア感染の審査は数日、スパムを含むハッキングされたサイトの審査は数週間かかる場合があります。承認後も、警告が消えるまで1〜2日の反映遅れがあるとされています。問題が残ったまま再審査を繰り返すと、期間が延びる可能性があります。

ファイルの更新日時を見れば改ざんを検知できますか？

手がかりにはなりますが、確実ではありません。更新日時は攻撃者が書き換えられるためです。正常な状態でファイルのハッシュ値(sha256sumなど)の一覧を作ってサーバーの外に保管し、後で照合する方法のほうが確実です。WordPressなら、WP-CLIのverify-checksumsで配布元との差分を確認できます。

サイトスカウターの/server/でマルウェアに感染していないか分かりますか？

ファイルの中身を検査する機能はないため、感染そのものは判定できません。HTTPS、証明書、セキュリティヘッダー、Cookie属性、バージョン情報の露出といった外から見える設定と、DNSBLへの掲載有無を確認できます。感染の検査は、Search Consoleやサーバー上の確認と併用してください。

出典・参考資料

最終確認日：2026-10-06。制度・仕様は変更されることがあるため、実施前に各一次情報をご確認ください。

本記事は一般的な情報提供を目的としており、法的助言ではありません。被害に遭われた場合や判断に迷う場合は、消費者ホットライン（188）や警察相談専用電話（#9110）などの公的窓口にご相談ください。