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 にも対応しやすくなります。

古い導線や公開面の棚卸しをするなら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 への耐性を高めます。