ClickFixとは？偽CAPTCHAでコマンド実行させる危険性と対策方法を徹底解説

ClickFixとは何か

ClickFix は『利用者に自分で実行させる』初期侵入です

ClickFix は、偽 CAPTCHA、偽ブラウザエラー、偽 bot check、偽ヘルプ画面などを使って、利用者へ「この操作をすると復旧する」「この確認を通すと続行できる」と信じ込ませ、最終的に terminal や PowerShell の自己実行へ誘導する手口です。重要なのは、攻撃者が直接端末を操作する前に、利用者自身の手で実行させる 点にあります。つまり ClickFix は、malware の自動感染よりも、ソーシャルエンジニアリングと self-execution の組み合わせとして理解した方が実態に近いです。

そのため、一般的な phishing のように「認証情報を入力させる画面」として見るだけでは不十分です。ClickFix の場合、利用者が見るのはログイン画面ではなく、トラブルを解決するための画面、確認を完了するための画面、support を受けるための画面です。ここで「自分で実行しているから問題ない」と誤認させるのが特徴で、利用者の正常操作に見えるように設計されている ことが危険です。

既存の フィッシング対策とは？ が broad hub として認証情報窃取や誘導全般を扱うのに対して、本記事では ClickFix を「入力」ではなく「自己実行」へ導く攻撃として切り分けます。ここを分けないと、認証教育だけを強化して terminal 実行誘導を見落とす、というズレが起きやすくなります。

偽 CAPTCHA が成立するのは、利用者が『安全確認の延長』だと感じるからです

fake CAPTCHA や fake browser check が効く理由は、利用者にとって「不審な要求」に見えにくいからです。普段から bot check、認証確認、拡張機能の警告、更新要求に接しているため、多少変わった操作を求められても「このサービス特有の確認かもしれない」と受け取りやすくなります。そこへ copy、paste、open terminal の順を短く並べることで、警戒より復旧行動を優先させやすくなります。

つまり ClickFix は、技術的な exploit だけで成立しているわけではなく、利用者が正しい支援だと思う文脈 を先に作っているところが強いです。Proofpoint の recent reports や CISA / HHS の注意喚起も、PowerShell の内容そのものより、偽画面・自己実行・後続感染の流れに注目しています。だから対策でも「危険な文字列を検知する」だけでなく、「なぜ利用者がこの画面を信じるのか」を見る必要があります。

偽CAPTCHAと偽エラーで、なぜコマンド実行まで進んでしまうのか

利用者は『侵害』より『復旧作業』だと認識しやすいからです

ClickFix の誘導は、攻撃の雰囲気を前面に出しません。代わりに「表示を直す」「アクセスを続ける」「エラーを解消する」「support を受ける」といった復旧目的に見せます。このとき利用者は、危険なサイトへ騙されたというより、トラブル対応の延長として手順を進めてしまいます。ここが password 入力型 phishing との大きな違いで、入力ミスではなく作業支援に見える ことが実行率を上げます。

さらに、画面内で copy ボタンや code block に見える UI を使うと、利用者は「このサイトが用意した正規の修復手順だ」と感じやすくなります。self-execution の心理的負担が下がるため、terminal を普段使わない人でも実行してしまうことがあります。つまり ClickFix の問題はコマンドの内容だけでなく、実行前の心理的な文脈設計 にあります。

clipboard と terminal を使うため、従来の block point をすり抜けやすい面があります

一般的な phishing は URL block、login page 検知、mail filter、credential monitoring で防ぎやすい場面があります。しかし ClickFix は clipboard と terminal の間に利用者の手作業が入るため、従来の credential theft 対策だけでは気づきにくいことがあります。実際には browser で始まりつつも、実行の最終地点は terminal や script host です。ここが可視化できていないと、browser 側の異常と endpoint 側の異常が別件に見える ことがあります。

だから企業側では、偽 support 画面の報告、ブラウザの不審ポップアップ、clipboard から始まる自己実行、異常な script host 利用、RMM や LOLBin の後続利用を一つの連続した流れとして見なければなりません。途中のどこか一つだけを見ていると、「ただの怪しいページ閲覧」「ただの PowerShell 実行」と誤認しやすくなります。

フィッシング、コールバックフィッシング、RMM悪用と何が違うのか

ClickFix は『認証情報を入れさせる』より『実行させる』ことが主役です

一般的な phishing は認証情報や決済情報の入力を狙うことが多く、コールバックフィッシングは電話や help desk なりすましから遠隔支援へつなぎます。これに対して ClickFix は、利用者へ自分で terminal を開かせ、何らかの self-execution をさせるところが主役です。したがって防御でも「認証情報を入れないでください」という教育だけでは足りず、画面上で command 実行を指示されたら必ず止まる という別の判断軸が必要になります。

既存の コールバックフィッシングとは？ が remote assistance への handoff を主役にするのに対して、ClickFix は電話の前に browser 画面だけで成立するケースもあります。両者は近いですが、ClickFix の方が「利用者が自分で実行した」という痕跡になりやすく、初動時に人為ミスへ矮小化されやすい点に注意が必要です。

RMM悪用や LOLBin は後続工程として分けると対策が見えやすくなります

ClickFix の後に遠隔管理ツールや正規ツール悪用が続くことはありますが、それらは ClickFix そのものではありません。RMM悪用とは？ が扱うのは正規の遠隔管理基盤の悪用であり、Living off the Land攻撃とは？ は実行後の OS 正規機能悪用です。ClickFix をそれらと混ぜると、どこで止めるべきかがぼやけます。

実務では、ClickFix を「初期侵入の誘導面」、RMM や LOLBin を「実行後の展開面」と分けると対策が整理しやすくなります。前者では偽画面、support 導線、clipboard、利用者教育、browser 監視が主役です。後者では endpoint hardening、allowlist、RMM 制御、script host 監査が主役です。このように分けることで、人がだまされる段階と、実行後の技術的拡大を別々に潰す ことができます。

企業で最初に置くべき防御線は何か

正規 support 導線を明確にし、利用者が判断に迷う余地を減らします

ClickFix への防御で最初に効くのは、PowerShell を全面 block することより、利用者が「何が正規の support 導線か」を判断しやすくすることです。たとえば社内ヘルプデスクが browser 画面上で command 貼り付けを求めないこと、復旧手順は社内ポータルから始まること、遠隔支援は決められたツールと連絡先からしか開始しないことを明文化すると、偽画面の成立条件が弱まります。つまり defense は endpoint だけでなく、正規導線を短く分かりやすくすること から始まります。

同時に、browser で不審な support 画面を見た、copy を促された、terminal 起動を求められた、という報告がすぐ届くようにしておく必要があります。ClickFix は認証失敗と違って、利用者が「自分でやってしまった」ことで報告をためらいやすいため、報告窓口の心理的ハードルも重要です。早く報告が来れば、自己実行が起きても後続感染前に止められる確率が上がります。

実行後の調査は、browser・clipboard・endpoint を一連で見ます

ClickFix が疑われたら、browser の閲覧履歴だけで終わらせないでください。いつ不審画面が出たか、copy 誘導があったか、利用者が terminal や PowerShell を起動したか、その後に script host、RMM、LOLBin、外部送信があったかを一連で確認する必要があります。これを分断してしまうと、ClickFix の self-execution と後続の技術的展開が別々の出来事に見えてしまいます。

CISA や HHS の guidance が示すように、ClickFix は sector を問わず広がるため、個別の malware family 名だけを追っても再発防止が弱くなります。むしろ重要なのは、「利用者が自己実行したら何を見るか」という調査パターンを固定し、browser と endpoint の両方で確認することです。そこまで整備すると、ClickFix だけでなく類似の social engineering にも対応しやすくなります。

訓練と監視で ClickFix を定着させるには

疑似演習では偽 CAPTCHA だけで終わらせず、自己実行の前段を見せます

ClickFix の訓練で重要なのは、単に『偽 CAPTCHA に注意』と周知することではありません。実際の利用者は、偽 bot check、偽エラー復旧、偽 support 案内、偽ブラウザ更新など、一見すると正規の対処に見える前段を踏んでから自己実行へ進みます。したがって疑似演習でも、copy ボタン、貼り付け手順、terminal 起動の流れまで見せて、どこで止まるべきかを具体的に学ばせる必要があります。

その際、『PowerShell を開いたら即失敗』と責めるよりも、『なぜその画面が正規 support に見えたのか』『正規導線ならどこへ戻るべきだったか』を振り返る方が再発防止に効きます。ClickFix は user error を責めるほど報告が遅れやすいため、自己実行前に迷った瞬間を共有できる訓練に寄せた方が現場へ定着しやすくなります。

また、疑似演習の結果を『何人が実行したか』だけで評価すると、単なるランキングで終わります。重要なのは、どの画面表現が本物に見えたのか、どの説明なら止まれたのか、support 導線のどこが曖昧だったのかを残すことです。ClickFix 対策では、だまされた人数より、迷った理由を回収することの方が改善につながります。

browser、clipboard、endpoint の監視項目を一つの流れにします

監視側でも、browser の不審画面、clipboard への大量コピー、terminal / PowerShell の起動、script host の実行、RMM や LOLBin の後続利用を別々に見ると、ClickFix を取り逃しやすくなります。大切なのは、利用者の一連の操作を一つの手口として結び付けることです。これにより、単体では正規操作に見えるイベントでも、時系列で並べると異常だと判断しやすくなります。

月次レビューでも、偽画面報告、support 誘導、自己実行、遠隔支援開始、後続感染を一つのレビュー項目へ束ねると、『どの導線が信じられやすかったか』『どこで報告が遅れたか』が見えてきます。ClickFix を単発のブラウザ事故で終わらせず、公開導線と endpoint 防御の両面で改善するテーマとして扱うことが重要です。

監視設計でも、PowerShell や terminal の実行だけを見ていると『開発者の通常操作かもしれない』で流れやすくなります。そこへ browser の不審画面報告、clipboard 利用、直後の外部通信や RMM 起動を重ねて初めて、ClickFix らしい流れが見えてきます。したがって、画面、操作、後続挙動を一つの系列で監視することが、self-execution 型手口では特に重要です。

この発想を月次レビューへ落とし込むと、偽画面の報告件数、自己実行直前で止まれた件数、実際に command 実行へ進んだ件数、後続で RMM や LOLBin が確認された件数を同じ列で見られるようになります。すると、ClickFix を『一人の操作ミス』ではなく、組織の公開導線と監視設計の課題として扱いやすくなります。

だから ClickFix 対策では、browser 側の表示、利用者教育、endpoint 検知、公開導線整理を別々の担当へ投げるだけでは足りません。演習とレビューを通じて、どの導線が信頼され、どの操作が見逃され、どの後続挙動が遅れて見つかったかを一枚で振り返れるようにしておくと、改善の優先順位をつけやすくなります。

こうした振り返りが回り始めると、偽 CAPTCHA や偽 support 画面を『珍しい攻撃』として扱うのではなく、公開導線と利用者行動の間に生じる繰り返し起こり得る初期侵入リスクとして扱いやすくなります。ClickFix は、その視点へ組織を移せるかどうかが防御力の差になります。

要するに、ClickFix を止めるには『怪しい画面を一つ block する』発想では足りず、利用者が信じる導線と実行の流れを丸ごとレビューする必要があります。

古い導線や公開面の棚卸しをするならASM診断 PRO

ASM診断 PRO は ClickFix を直接 block する製品ではありませんし、endpoint 側の script 実行制御や browser isolation を置き換えるものでもありません。それでも効果があるのは、ClickFix が成立しやすいのが「利用者が正規かどうか判断しづらい公開面」だからです。古い support site、用途不明の subdomain、放置された staging、散らばった docs、複数の login 導線が残っていると、利用者は偽画面を本物と見分けにくくなります。つまり最初に減らすべきなのは、攻撃者が信頼を借りやすい外部接点 です。

とくに ClickFix のような手口では、正規 support 導線が分かりにくい組織ほど被害後の説明が難しくなります。どのドメインが正規で、どのサポートページが現役で、どの login 画面がまだ残っているのかを把握できていないと、利用者教育も incident 対応も曖昧になります。ASM診断 PRO を使うと、外から見える support 面、管理画面、古い host を整理し、「この導線は消す」「この導線だけを正規にする」という判断を進めやすくなります。

既存の 外部接続点は見えているか？、管理画面・開発環境の露出リスク、コールバックフィッシングとは？ と合わせて見ると、ClickFix を単なる browser 詐欺としてではなく、外部公開面と support governance の問題として扱えます。偽画面で self-execution を起こさせないためにも、まずは 外から見える導線を整理し、正規の入口を短く固定すること から始めてください。

よくある質問（FAQ）

ClickFix は phishing の一種ですか

広くは social engineering の一種ですが、主役は認証情報入力より自己実行です。terminal を開かせる点で通常の phishing と見分けて考えた方が対策しやすくなります。

偽 CAPTCHA だけを block すれば防げますか

不十分です。偽エラー、偽 support、偽 browser update など別の見せ方でも成立するため、self-execution 全体を前提にした対策が必要です。

利用者が command を実行したら、すぐ侵害確定ですか

可能性は高まりますが、まず browser、clipboard、endpoint の痕跡を見て、後続で何が起きたかを切り分けるべきです。初動の速さで被害は変わります。

callback phishing と同じ教育で足りますか

一部は共通しますが、ClickFix は browser 画面だけで self-execution まで進むため、terminal 起動や copy-paste の異常さを追加で教える必要があります。

最初に一番効果が高い対策は何ですか

正規 support 導線を明確にし、利用者が browser 上で command 実行を求められたら止まる、という判断基準を固定することです。

まとめ

ClickFix は、偽 CAPTCHA や偽エラー画面から利用者に自分で command を実行させる self-execution 型の初期侵入です。通常の phishing のように認証情報入力だけを警戒していると、復旧作業や support 手順に見える画面へだまされる経路を見落としやすくなります。したがって本質は「怪しい文字列を見抜くこと」より、なぜ利用者が正規の作業だと思ってしまうのか を理解することにあります。

実務では、ClickFix を broad phishing や callback phishing とまとめず、偽画面、clipboard、terminal、後続の RMM / LOLBin 展開という流れで分ける方が対策しやすくなります。正規 support 導線を明確にし、browser 上で command 実行を求める画面は必ず止めると教育し、初動時は browser と endpoint を一連で追跡すると、自己実行後の被害拡大を抑えやすくなります。つまり対策の中心は、利用者の判断点を増やすことと、実行後の調査パターンを固定すること です。

さらに再発防止では、古い support page、放置 subdomain、用途不明の staging、散らばった docs のように、攻撃者が信頼を借りやすい公開面を減らす必要があります。ClickFix は技術 exploit だけでなく、企業の公開導線の曖昧さを利用するからです。正規入口を短くし、外から見える support 面を整理し、利用者が迷いにくい導線へ寄せていくことが、ClickFix を含む最近の social engineering への耐性を高めます。

つまり ClickFix 対策は、browser 側の警告表示だけで完結しません。利用者が外から見える導線をどう信頼するかまで含めて考える必要があります。正規の support ページ、FAQ、ログイン導線、ドキュメントの置き場所が整理されているほど、偽画面が入り込む余地を減らしやすくなります。公開面の整流化は、self-execution を防ぐ土台になります。