あなたのサイトが知らない間に加害者になる偽CAPTCHAの手口

偽CAPTCHAとは何か

偽CAPTCHAは、「私はロボットではありません」に似た確認画面を装い、閲覧者に操作を指示する手口です。「確認のためにこのコマンドを実行してください」といった案内を表示し、閲覧者自身にコマンドを実行させます。そのコマンドがマルウェアを取得して起動します。

セキュリティ企業の報告では、この種の手口をまとめて「ClickFix」と呼びます。画面に出た問題を閲覧者自身に操作させて解消させる、という形の総称です。偽CAPTCHAはそのうちの一つで、Proofpointは「偽CAPTCHAを題材にしたClickFixの手法」と位置づけています。ほかに偽のエラー表示や、偽の会議参加画面を使う形も報告されています。

2024年から確認されており、目新しいものではありません。Proofpointは2024年9月、GitHubの通知を装って偽の警告サイトへ誘導し、閲覧者にコマンドを実行させて情報窃取型のマルウェアに感染させるキャンペーンを確認したと報告しています。世界で少なくとも300の組織に影響したとされています。

件数も増えています。ESETの2025年上半期の脅威レポート（外部サイト）では、偽CAPTCHAとして検知された件数が2024年下半期から2025年上半期にかけて500%を超えて増え、2025年上半期のテレメトリではフィッシングに次いで2番目に多い攻撃手口になりました。

閲覧者が指示に従ってしまうのは、画面が本物の確認手続きに似ているためです。「エラーを解消するため」「人間であることを確認するため」といった、断る理由の見つけにくい名目が添えられます。正規の操作に見えるため、警告が出ても閲覧者がそれを回避して実行してしまうおそれがあります。

この画面をどこに置くかも報告されています。攻撃者が自分で用意したサイトのほか、正規のサイトを侵害して埋め込む形が使われます。閲覧者が普段から見ているサイトに表示されるほうが、警戒されにくいためです。

侵害されたWordPressサイトは、この配信場所として使われます。運営者が気づかないうちに、閲覧者を攻撃する側に立たされます。

直接感染するのは自社ではなく閲覧者

侵害と聞くと、自社のデータが持ち出される、サイトが止まる、といった被害を思い浮かべます。偽CAPTCHAの表示そのものは、そうした形では表に出ません。サイトは普段どおりに動き、記事も注文データも見た目には変わりません。同じ侵入から別の被害が起きている場合もありますが、この手口だけでは目に見える症状が出ないため気づきにくくなります。

マルウェアに直接感染するのは、そのサイトを訪れた閲覧者です。指示に従った人の端末が感染します。つまり自社は、侵害された側でありながら、攻撃を届ける場所を提供した側にもなります。

被害の届く先が変われば、あとで求められる説明も変わります。自社の被害だけなら復旧して終われますが、閲覧者に実害が出た場合は、いつからいつまで、どの範囲に配信していたのかを示すことになります。取引先や顧客が対象に含まれていれば、その相手への説明も必要になります。

自社サイトが踏み台になるまでの流れ

攻撃者は、WordPress本体やプラグインの脆弱性、あるいは盗まれた管理画面の認証情報を使ってサイトに侵入します。次に、偽CAPTCHAを表示するコードを埋め込みます。以後、サイトを訪れた閲覧者にその画面が表示され、指示に従った人の端末がマルウェアに感染します。

配信先として使われるのに、サイトの知名度は要りません。Proofpointが報告した2024年のキャンペーンでは、少なくとも300の組織が影響を受けたとされています。訪問者の少ないサイトでも、閲覧した人に届けば踏み台としては機能します。

この間、管理画面の見た目は普段と変わらないことが多く、運営者は異常に気づきにくいです。気づく手がかりは、閲覧者からの問い合わせや、検索エンジンからの警告であることが少なくありません。同じ侵入経路は、閲覧者への攻撃だけでなく、スパムメールの大量送信の踏み台にも使われることがあります。スパム送信警告への対処方法もあわせて確認してください。

運営者の画面では正常に見えることがある

偽の確認画面は、訪れた全員に表示されるとは限りません。Proofpointは、攻撃者が独自の絞り込みと確認を行い、実際の人物に届くようにしていると報告しています。どの条件で絞るかは公開されていませんが、訪問者を選んで表示する場合があることは確認されています。

そのため、運営者が自分でサイトを開いたときに正常な画面が表示されることがあります。「自分で見て確認したから大丈夫」という判断が成り立たないのは、このためです。

サーバーのアクセスログだけでも判断しきれません。埋め込まれたコードが外部から読み込まれる形をとる場合、閲覧者の端末で起きた処理までは、自社サーバーの記録には現れないためです。ログに何も出ていないことは、配信していない根拠になりません。

気づくためのサイン

• 見覚えのないリダイレクト：自社サイトを開くと別のページや確認画面に転送される。
• 検索エンジンからの警告：Search Consoleや検索結果で「危険なサイト」と表示される。
• 身に覚えのないファイル：サーバー内に覚えのないJavaScriptやPHPファイルが増えている。
• 閲覧者からの指摘：「変な画面が出た」「別のサイトに飛ばされた」という連絡が届く。運営者の画面には出ないことがあるため、これが最初の手がかりになる場合がある。
• 広告やブラウザの警告：広告出稿の審査で止まる、ブラウザが警告画面を先に出す、といった形で外部から知らされる。いつから配信していたかは、この時点では分からない。

あとで説明を求められること

閲覧者や取引先から問われるのは、たいてい3つです。いつから配信していたのか。どの範囲の訪問者に届いたのか。そして、いまは止まっているのか。

いつからかを答えるには、改ざんが行われた時刻が要ります。手がかりはファイルの更新日時ですが、攻撃者が元の値へ戻していることもあり、それだけでは確定しません。バックアップや配信の記録と突き合わせる必要があります。

どの範囲かは、さらに難しくなります。表示する相手を絞る条件が付いていた場合、訪問者の全員が対象とは限りません。条件が分からなければ、範囲も絞り込めません。「全員に出ていたかもしれない」としか言えない状態になります。

止まっているかどうかも、見た目では答えられません。表示が消えたことと、配信の仕組みが取り除かれたことは別です。この3つに答えられる状態を作れるかどうかが、専門家に相談するかどうかの分かれ目になります。

表面を消しても配信は止まらない

見つかったファイルを削除すれば止まる、と考えたくなります。しかし、侵入した経路とは別の場所に足がかりが残っていれば、表面だけを消しても同じ改ざんが繰り返されます。削除で消えるのは表示であって、侵入経路をふさぐものではありません。

削除だけで対処しようとすると再発する仕組みは、改ざん検知・不正ファイル検出への対応で説明しています。

また、改ざんされた状態を先に消してしまうと、いつから配信していたのかを後から確かめる材料も失われます。閲覧者や取引先への説明が必要になったとき、範囲を示せなくなります。削除の前に何を残しておくべきかは、初動の確認項目としてまとめてあります。

改ざんに気づいたときの確認項目を見る →

緊急対応へ切り替える判断

閲覧者に不審な画面が表示されている、別サイトへ転送されている、検索エンジンから警告が出ている。このいずれかに当てはまる場合、配信が止まったとは判断できません。自分で画面を確認できたなら、その時点でまだ続いています。検索エンジンの警告だけが手がかりのときは、警告が出た時期と現在の状態が一致しているとは限らないため、まず現状を確かめます。

止まっていないなら、原因を調べている時間がそのまま配信の継続時間になります。閲覧者の被害は、調査が終わるまで待ってはくれません。自力での試行錯誤が被害を広げるのは、切り分けの手順を探している間も配信が続くためです。

緊急対応では、当日中に切り分けから進めます。まず配信を止め、そのうえで侵入経路を調べる順序になります。閲覧者への配信を止めることが最優先で、原因の特定はそのあとです。

当てはまるものがない場合でも、前節の3つ（いつから・どの範囲に・いまは止まっているか）に答えられないなら、確認しておく価値はあります。答えられない状態のまま時間が経つと、あとから範囲を絞る材料が失われます。