偽CAPTCHAで“コピー→Win+R→Enter”を誘導する「ClickFix」——ブラウザキャッシュ潜伏で検知面をすり抜ける新手口です

今日の深掘りポイント

• 攻撃は「私は人間です」型の偽CAPTCHAを使い、ユーザーにクリップボードの内容をWindowsの実行ダイアログ（Win+R）へ貼り付け実行させる、人力実行型の社会工学です。
• ペイロードはダウンロードフォルダではなくブラウザキャッシュに潜み、従来の「ダウンロード検知」やゲートウェイ側のファイル検査をバイパスします。
• 実行連鎖は cmd.exe → VBScript → PowerShell とLOLBinを踏み台に進み、スクリプトベース検知の盲点を狙います。
• 現場での対策はアプリケーション制御（WDAC/Applocker）、PowerShell制限、ASRルールの適用、ブラウザ/EDRの監視強化の“多層”が決め手です。
• 新奇性と即応性が同居する脅威で、発生確度が高い一方で運用で潰せる要素が多いのが特徴です。ハンティングとユーザー教育を同時に回すべき局面です。

はじめに

CAPTCHAは、人間とボットを見分ける“守り”の象徴でした。しかしClickFixは、その直感的な信頼を逆手に取りました。画面に現れるのは、一見もっともらしい検証プロンプト。指示は「コピーしてWin+Rに貼り付け、Enterを押してください」。いわば、攻撃者がユーザー自身を“ローダー”に仕立てる設計です。

この設計が厄介なのは、検知の構図をズラす点です。ファイルを明示的に落とさず、ブラウザキャッシュから素材を拾い、OS標準のスクリプト実行環境を継いでいく。セキュリティ基盤の“想定”を数センチずつ外す巧妙さが光ります。だからこそ、SOCは検知の視点を一段横にずらす必要があるのです。

深掘り詳細

事実関係（公開情報からの整理）

• Microsoftの脅威インテリジェンスが、偽のCAPTCHA風検証プロンプトでWindowsユーザーに悪性コマンドの実行を促すClickFixキャンペーンを特定しています。
• ユーザーには「クリップボードにある内容をWindowsの実行ダイアログへ貼り付けてEnter」するよう誘導が行われます。実行の主体はユーザー自身です。
• 攻撃者はブラウザのキャッシュ内にペイロードを配置し、ダウンロード検知やセキュアWebゲートウェイのファイル検査を回避します。
• 実行フローは、cmd.exeでブラウザプロファイルを探索→特定ファイルをVBScriptに変換→PowerShellで追加ペイロード取得という段階的ローディングを取ります。
• Microsoft Defenderはこの活動に対して多層の保護を提供し、関連する不正活動を「Trojan:Win32/ClickFix」として検出します。
• 参考（報道）：GBHackers on Security: Microsoft warns ClickFix attacks use fake CAPTCHA です。

編集部のインサイト（なぜ効くのか／何が新しいのか）

• 人力実行で“最初の関門”を突破します。ファイルレスではないものの、初動はユーザー操作に擬態し、EDRやAVにとって「ユーザー意図のある実行」に見えやすいです。Win+Rはヘルプデスク手順や正規アプリでも用いられるため、行動の異常性が埋もれます。
• ブラウザキャッシュは“検査の死角”になりがちです。ダウンロード監視やDLPはDownloads/Tempのモニタリングが中心で、Cacheディレクトリ起点の読み出しは監視網が粗くなりやすいです。キャッシュを“デッドドロップ”として再利用するのは、検知面で理にかなっています。
• LOLBinsを多段で使うことで検知特徴量を薄めます。cmd.exe、wscript/cscript、powershellと、どれも企業ネットワークで日常的に観測されるコンポーネントです。単体しきい値では埋もれやすく、プロセス系譜（parent-child関係）とファイルI/Oの“組み合わせ”で初めて浮かびます。
• マクロ封じ・添付ファイル検査の強化後に出てきた“別動線”です。メールを介さずWeb、ダウンロードせずキャッシュ、ユーザー主体で実行という3点セットは、近年の強化策が作った壁の“間隙”を丁寧に縫っています。

脅威シナリオと影響

以下は公開情報と一般的な侵害パターンからの仮説ベースのシナリオです。環境により挙動は異なる可能性があります。

• シナリオA：情報窃取型（初期アクセス仲介）

  • ユーザーが正規サイト閲覧中に偽CAPTCHAへ誘導→Win+R実行→ブラウザキャッシュ由来のVBScript/PowerShell連鎖→インフォスティーラ投下→ブラウザCookie/セッショントークン収集→C2へ送信→IABが横流し、の流れです。
  • 影響はSaaSアカウントの乗っ取りやMFA疲労攻撃の足掛かり、広告/決済の不正利用です。

• シナリオB：ラテラルムーブ前提のフォータ（多段ローダ）

  • 初期ローダは環境偵察と持続化（タスクスケジューラ）に留め、後段でRAT/リモートシェルを取得します。SOCの“初動封じ”を狙い、夜間・週末に段階を進める運用が想定されます。
  • 影響はファイルサーバの暗号化準備、AD偵察、バックアップ妨害などの前段階確立です。

• シナリオC：狙い撃ちの業務妨害（短期的破壊）

  • 初動ローダ後にスクリプトでポリシー改変やアンチウイルス無効化を試行し、限定範囲での業務停止を引き起こします。ヘルプデスクを装うソーシャルと相性が良いです。

想定MITRE ATT&CKマップ（仮説）

• Initial Access
  • Drive-by Compromise（T1189）です。
  • User Execution（T1204）です。
• Execution
  • Command and Scripting Interpreter: Windows Command Shell（T1059.003）です。
  • Command and Scripting Interpreter: PowerShell（T1059.001）です。
  • Command and Scripting Interpreter: Visual Basic/VBScript（T1059.005）です。
• Defense Evasion
  • Masquerading（T1036）です。
  • Obfuscated/Compressed Files and Information（T1027）です。
• Discovery
  • File and Directory Discovery（T1083）です。
• Persistence（可能性）
  • Scheduled Task/Job（T1053）です。
• Command and Control
  • Ingress Tool Transfer（T1105）です。
• Collection/Abuse
  • Clipboard Data（T1115）を初動の“伝達路”として悪用する可能性です。

組織的影響としては、Webゲートウェイ偏重の検査構成や、標準スクリプトホストの実行制御が緩い環境で成功率が高まります。国内でもゼロトラスト移行過程の“グレーゾーン”に刺さりやすい類型であり、MFAやメール防御の堅牢さとは別軸での曝露が増えることに注意が必要です。

セキュリティ担当者のアクション

“設定で積む”と“監視で拾う”の両輪で、短期・中期の優先順位を整理します。

• すぐに着手（1〜2週間）

  • アプリケーション制御
    • WDACまたはApplockerで、標準ユーザーの wscript.exe / cscript.exe / mshta.exe / powershell.exe の実行を明示許可制にします。業務影響の大きいPowerShellはConstrained Language Modeを標準ユーザーに適用します。
  • Microsoft Defender/EDRの強化
    • クラウド保護・PUA保護・ネットワーク保護を有効化します。
    • Attack Surface Reduction（ASR）で「JavaScript/VBScriptからのダウンロード済み実行ファイルの起動ブロック」をブロックモードにします（GUID: D3E037E1-3EB8-44C8-A917-57927947596D）です。
  • ログと可視化
    • PowerShell Script Block Logging（4104）/Module Logging（4103）/トランスクリプションを有効化します。Windowsのプロセス作成（4688）でコマンドライン取得を必須化します。
    • MDEなどで parent=explorer.exe → child=cmd.exe / powershell.exe / wscript.exe の系列を可視化します。
  • ブラウザ/エンドポイント
    • Edge/Chromeの企業ポリシーで拡張導入の許可リスト運用、SmartScreen/Enhanced Securityの強制を行います。
    • 高リスク部門ではWindows Script Host（WSH）をレジストリで無効化する運用も検討します（影響範囲の事前精査が前提）です。
  • ユーザー教育・ヘルプデスク連携
    • 「Web画面の指示でWin+Rにコマンドを貼り付けさせる」事例は即時エスカレーション、というワンポイント教育を配信します。ヘルプデスク台本にも盛り込みます。

• ハンティングの着眼点（継続）

  • ブラウザ直後のスクリプト連鎖
    • chrome.exe / msedge.exe の実行直後5分以内に、explorer.exe→cmd.exe/wscript.exe/powershell.exe が出現する端末を抽出します。
  • コマンドライン特性
    • AppData\Local\Google\Chrome\User Data*\Cache や AppData\Local\Microsoft\Edge\User Data*\Cache を参照するcmd/powershellの出現を拾います。
    • PowerShellのIEX、FromBase64String、Invoke-WebRequest/Start-BitsTransferの併用、あるいはwscript //E:vbscriptの痕跡を相関します。
  • ファイルI/O
    • Cacheディレクトリからの読み出し直後に生成される .vbs/.tmp の短命ファイルと、その後続プロセス（wscript/powershell）をひとつのケースとして束ねます。
  • ネットワーク
    • 二段階目以降のHTTP/S外向き取得先（初見ドメイン、カテゴリ不明CDN、パスにupdate/verify/fixなどを含むもの）を、前段のスクリプト連鎖と関連付けてスコアリングします。

• 中期（30〜90日）

  • ベースラインの再定義
    • 「標準ユーザーはスクリプトホストを原則実行しない」を方針化し、例外は申請・期限・監査ログ必須とします。
  • 検知ロジックの多要素化
    • 単一の技術シグナルではなく、プロセス血統＋コマンドライン＋ファイルI/O＋時系列の“4点セット”で相関する検知を構築します。
  • インシデントレスポンスの手順化
    • ブラウザキャッシュ由来のローディングに備え、キャッシュの保全（取得→分析→削除）手順とE2Eの証跡確保（AMSI/4104/4688）が確実に回ることを演習します。

最後に、今回のメトリクスが示唆するのは“実装は軽く、効果は鋭い”というタイプの脅威が増えている現実です。新奇性と即効性があり、攻撃の成立確率も高い一方で、現場で手を入れられる余地も大きいです。だからこそ、設定・検知・教育の三位一体で「人力実行を設計に組み込む攻撃」に備えることが、組織のレジリエンスを最短距離で高める道筋になります。

参考情報

• Microsoft warns ClickFix attacks use fake CAPTCHA (GBHackers) です。

（注：本稿は公開報道および提供情報に基づく分析で、技術的詳細の一部は仮説を含みます。一次情報の追加公開があれば更新します。）