ClickFix 攻撃の仕組みと多層防御｜FileFix・ConsentFix への備え

はじめに

近年、企業や個人を標的とするサイバー攻撃の手法は多様化しており、その中でも「ClickFix（クリックフィックス）」と呼ばれるソーシャルエンジニアリング攻撃が急速に拡大しています。Microsoft が公開した 2025 年の年次レポートでは、観測された初期侵入手法の 47% を ClickFix が占め、従来型フィッシング（35%）を上回った と報告されており、すでに「主流の攻撃手法」と位置づけられています。

ClickFix は、偽のエラー画面やロボット認証（CAPTCHA）画面を用いて、利用者自身に悪意のあるコマンドをコピー＆ペーストさせる手法です。利用者の操作を介して実行されるため、PC 上のセキュリティ製品の検知をすり抜けやすいという特徴があります。さらに 2025 年後半以降は、FileFix・ConsentFix・DNS 版 ClickFix などの亜種が次々と登場しており、防御側の対策も継続的なアップデートが求められる状況です。

本記事では、ClickFix 攻撃の全体像と従来のフィッシング（Phishing）との違い、急増している亜種の特徴、被害を防ぐための多層防御の考え方について整理します。

参考: Microsoft Digital Defense Report 2025
“This year, we saw the widespread adoption of ‘ClickFix,’ a social engineering technique that tricks users into executing malicious code themselves, bypassing traditional phishing protections.”
（今年、従来のフィッシング対策を回避し、利用者自身に悪意のあるコードを実行させるソーシャルエンジニアリング手法「ClickFix」が広く採用される動きが確認されました。）
https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/microsoft/msc/documents/presentations/CSR/Microsoft-Digital-Defense-Report-2025.pdf

ClickFix（クリックフィックス）とは？

ClickFix（クリックフィックス）は、Web サイト上で偽の警告画面や認証画面を表示し、利用者自身に悪意のあるスクリプトを実行させるソーシャルエンジニアリング攻撃です。利用者の心理的な隙を突き、システム標準機能を用いてコマンドを実行させる点に特徴があります。

利用者自身に不正なコマンドを実行させる攻撃手法

ClickFix の特徴は、マルウェアを含むファイル（実行ファイルやマクロ付きドキュメントなど）を直接ダウンロードさせない点にあります。

攻撃者は、改ざんされた Web サイトや悪意のある広告（マルバタイジング）を経由して、利用者を不正なページへ誘導します。誘導先のページでは「文字化け修正のためのフォントが不足しています」「Chrome の表示エラーが発生しました」といった偽のエラー画面、あるいはロボット認証（CAPTCHA）を装った画面が全画面で表示されます。続いて、その「解決手順」として PowerShell スクリプトをコピーさせ、「ファイル名を指定して実行（Windows キー + R）」やコマンドプロンプトに貼り付けて実行するよう誘導 します。

この手法は 利用者自身が Windows の標準機能でコマンドを実行する ため、メールゲートウェイや EDR（Endpoint Detection and Response）における従来型の検知シグネチャをすり抜けやすい性質があります。

急増の背景と最新の脅威動向

ClickFix は 2024 年 11 月以降に急増し、2025 年から 2026 年にかけて主要な脅威インテリジェンス各社が支配的な初期侵入手法として位置づけています。主要な計測データは以下の通りです。

国内でも、2025 年 5 月に株式会社ラックの JSOC が 国内複数組織における ClickFix 被害を観測 したと報告しています。ClickFix が日本語環境でも実害を出している段階に入ったと考えられます。

参考: ClickFix の被害を JSOC の複数のお客様にて観測（ラック）
ClickFix によって実行させられたコマンドは、EDR 製品などのログでは「ユーザによる意図した実行」として見えることが特徴です。
https://www.lac.co.jp/lacwatch/alert/20250519_004380.html

配布されるペイロードはランサムウェアに限らず、情報窃取型マルウェア（インフォスティーラー）と RAT が中心です。Microsoft の調査では Lumma Stealer が 2025 年に観測された情報窃取型の 51% を占めており、ClickFix の代表的なペイロードとなっています。その他、AsyncRAT、Rhadamanthys、SocGholish/NetSupport RAT、Latrodectus、MintsLoader、Cobalt Strike なども ClickFix 経由で配布される事例が報告されています。

従来のフィッシング（Phishing）との違い

ClickFix と従来のフィッシング（Phishing）は、利用者を誘導するという点では共通していますが、攻撃の 目的とアプローチが根本的に異なります。

従来型フィッシングが「情報を入力させる攻撃」であるのに対し、ClickFix は「利用者にコードを実行させる攻撃」である点が決定的な違いです。

ClickFix 攻撃の典型的な流れ

ClickFix 攻撃は、利用者が日常の Web ブラウジングで頻繁に目にする画面を模した表示で、不正な操作へ誘導します。ここでは代表的な誘導パターンと感染経路を整理します。

偽の CAPTCHA・偽システムエラーによる誘導

攻撃者は、脆弱性のある正規 Web サイトを改ざんしたり、悪意のある広告（マルバタイジング）を利用したりして、利用者を不正なページへ誘導します。誘導先では、以下のような画面が全画面で表示されます。

偽の CAPTCHA（ロボット認証）

「私はロボットではありません」「人間であることを証明してください」といった認証プロセスを装い、通過するための操作として特定のキー入力を求めます。Cloudflare や Google reCAPTCHA を模した画面が代表的です。

偽のシステムエラー

「Google Chrome でエラーが発生しました」「Word のフォントが見つかりません」「証明書の更新が必要です」といった警告を表示し、問題解決の手順として操作を指示します。Booking.com や LinkedIn の求人ページを偽装する事例も報告されています。

利用者は「早く目的のページを開きたい」「エラーを解消したい」という心理状態にあるため、画面の指示を疑わずに従ってしまう傾向があります。Revel8 が 2026 年第 1 四半期に実施した約 30,000 通のシミュレーションでは、Microsoft 関連を装った ClickFix ルアーで 23.6% が偽サイトを開封、1.4% が実際に端末でコマンドを実行 したという結果が報告されており、ペイロードを認識していても誘導文脈の作り込みによって警戒心が機能しなくなることが示されています。

クリップボード経由のコマンド注入と実行経路

偽画面には「解決策」や「認証手順」として具体的な PC 操作が記載されています。典型的な感染の流れは以下の通りです。

参考: Security Brief – ClickFix Social Engineering Technique Floods the Threat Landscape（Proofpoint）
“Most often, when navigated to the malicious URL or file, a dialog box will appear suggesting there was an error when trying to open the document or webpage.”
（多くの場合、悪意のある URL やファイルに誘導されると、文書や Web ページを開こうとした際にエラーが発生したことを示すダイアログボックスが表示されます。）
https://www.proofpoint.com/us/blog/threat-insight/security-brief-clickfix-social-engineering-technique-floods-threat-landscape

配布される代表的なマルウェア

ClickFix は 特定のマルウェアと結びついた攻撃ではなく、複数の攻撃者がペイロードを差し替えて利用する「配布手段」 として機能しています。2025 年から 2026 年第 1 四半期にかけて、ClickFix 経由で配布が確認されている主なマルウェアは以下の通りです。

特に インフォスティーラー → ローダー → ランサムウェア という多段攻撃チェーンの初期段階として、ClickFix が利用される事例が増えています。

進化する亜種: FileFix・ConsentFix・DNS 版 ClickFix

ClickFix は 2024 年 11 月の急増以降、防御側の対策に合わせて手口が継続的に進化しています。OPSWAT の表現を借りれば「攻撃者が描き直し続けるキャンバス」のような状態にあり、2025 年から 2026 年にかけて複数の亜種が確認されています。ここでは、防御の前提条件を変えるインパクトを持つ 3 つの主要な亜種を整理します。

FileFix: エクスプローラーアドレスバーを悪用

FileFix は、コマンド実行画面を Windows キー + R（ファイル名を指定して実行）からエクスプローラーのアドレスバーへ移した亜種 です。2025 年 7 月に概念実証（PoC）が公開され、わずか 2 週間以内に実際の攻撃で悪用 された経緯があります。

FileFix の特徴は、従来 ClickFix の対策として有効とされていた 「Win+R 無効化」の GPO を回避する 点にあります。さらに、エクスプローラーから起動されたプロセスには Mark of the Web（MOTW）属性が付与されない ため、SmartScreen やオリジンベースの保護機構が機能しません。エクスプローラーは利用者が日常的に開くツールであることから、ルア（誘導文脈）の心理的ハードルも下がります。

ConsentFix: OAuth 同意フローの悪用（パスキー無効化）

ConsentFix は、Push Security が 2025 年末に報告した亜種で、エンドポイントではなくアイデンティティ層を狙う 点が最大の特徴です。攻撃の流れは以下の通りです。

1. 利用者を偽の認証ページへ誘導する
2. 利用者は 正規の Microsoft ログイン画面 で本人認証を完了する（ここまでは正規の OAuth 2.0 認可コードフロー）
3. リダイレクト先 URL に含まれる 認可コードをコピーさせ、フィッシングページに貼り付け させる
4. 攻撃者は得られた認可コードを使い、Azure CLI 等の権限でクラウド環境へ持続的にアクセスする

認証自体は正規の OAuth フロー で行われるため、パスキー（FIDO2）や Authenticator アプリといったフィッシング耐性 MFA を導入していても防げません。発行されたトークンはパスワードリセットや MFA 設定変更を経ても有効であり、監査ログ上は「正規 OAuth アプリの認可」として記録されるため、検知も困難です。

参考: New ConsentFix Technique Tricks Users Into Handing Over OAuth Tokens（KnowBe4）
“Because there’s no login required, phishing-resistant authentication controls like passkeys have no impact on this attack.”
（ログインを必要としないため、パスキーのようなフィッシング耐性のある認証制御もこの攻撃には影響を与えません。）
https://blog.knowbe4.com/new-consentfix-technique-tricks-users-into-handing-over-oauth-tokens

DNS 版 ClickFix: nslookup を介したペイロード取得

Microsoft Threat Intelligence が 2026 年 2 月に公開した亜種で、ペイロードの取得経路を HTTP から DNS へ切り替えた タイプです。

従来の ClickFix はコマンド実行後に Web 経由でペイロードをダウンロードしますが、DNS 版では cmd.exe 経由で ハードコードされた外部 DNS サーバーへ nslookup を実行 し、応答内の Name: フィールドから次段ペイロードを抽出して実行します。システム既定のリゾルバを経由しない ため、社内 DNS のロギングや Web プロキシでの検知も回避されます。

DNS は通常業務でも常時発生する通信であり、悪意のあるトラフィックを正常通信に紛れ込ませる効果があります。Web 系の境界防御（URL フィルタ・Web プロキシ）が前提だった防御モデルでは検知が困難となるため、DNS レベルでの監視・脅威インテリジェンス連携 の重要性が増しています。

参考: Microsoft Discloses DNS-Based ClickFix Attack Using Nslookup for Malware Staging（The Hacker News）
“The initial command runs through cmd.exe and performs a DNS lookup against a hard-coded external DNS server, rather than the system’s default resolver.”
（最初のコマンドは cmd.exe を介して実行され、システム既定のリゾルバではなくハードコードされた外部 DNS サーバーに対して DNS ルックアップを実行します。）
https://thehackernews.com/2026/02/microsoft-discloses-dns-based-clickfix.html

亜種ごとの特徴比較

このほか、Microsoft は CrashFix（クラッシュダイアログを偽装）、JackFix、GlitchFix、TerminalFix、DownloadFix などの亜種も報告しています。「攻撃面が常に拡張されている」前提で防御を設計する ことが、今後の運用において重要なポイントとなります。

ClickFix が検知困難な構造的理由

ClickFix への対策を設計する際には、「単一の防御策では完全に防げない」 という前提が重要です。これは運用の怠慢ではなく、ClickFix の手法自体が以下のような構造的特性を持つためです。

EDR ログ上は「利用者意図の操作」として記録される

ClickFix で実行される PowerShell コマンドや mshta.exe / wscript.exe は、ログインユーザーが対話的に起動したプロセス として EDR・SIEM に記録されます。攻撃由来の実行と、利用者本人が業務上行った操作を、ログのメタ情報だけで機械的に区別することは困難です。

シグネチャベースの検知では限界があるため、プロセスの親子関係（例: explorer.exe → powershell.exe → 外部通信）や、コマンドラインに含まれる難読化パターン、Base64 デコード処理、外部 IP への即時通信 といった「振る舞い」を起点にした検知ロジックの設計が重要となります。

ペイロードが多様化し、シグネチャベースの検知が追いつかない

ClickFix は 配布手段（デリバリーチェーン）であり、ペイロードを差し替えやすい構造 を持ちます。インフォスティーラー（Lumma Stealer、Rhadamanthys 等）、ローダー（Latrodectus、MintsLoader）、RAT（AsyncRAT、QuasarRAT）など、多数のマルウェアファミリが ClickFix 経由で配布されている状況では、ペイロード単位での検知が後追いになりがちです。

さらに、Bitdefender の調査では 悪意のあるドメインの多くが、ブロックリストへ登録される前に役目を終えて廃棄されている ことも指摘されており、URL レピュテーションだけでは防御として不十分な状況です。

亜種ごとに対策の前提が異なる

前章で整理した通り、亜種ごとに 回避する防御層 が異なります。

「これさえ入れれば防げる」という万能の対策は存在しないため、複数の防御層を組み合わせ、いずれかが突破されても他の層で検知・遮断できる設計 が、ClickFix 対策の基本方針となります。

ClickFix への多層防御アプローチ

ClickFix は、人間の心理的な隙と OS の標準機能を悪用するため、単一の対策で完全に防ぐことは困難です。被害を抑えるには、利用者教育・端末側の予防制御・ネットワーク境界での検知遮断・EDR/SIEM での事後検知 を組み合わせた多層的なアプローチが重要となります。

利用者教育と運用ルールの周知

最初の防衛線は、攻撃の手口を組織内で共有し、利用者のリテラシーを高めることです。

• Web ブラウジング中に「警告画面」や「ロボット認証」が表示されても、画面の指示に従わないよう周知する
• 「Windows キー + R（ファイル名を指定して実行）」や「PowerShell」を開き、コピーした文字列を貼り付けて実行するよう求める正規 Web サービスは存在しない ことを社内ルールとして明文化する
• フィッシングシミュレーション訓練に ClickFix 型のシナリオ（偽 CAPTCHA・偽 Chrome エラーなど）を組み込む ことを推奨します
• 不審な操作を求められた際には、即時情報システム部門・セキュリティ窓口へ連絡するエスカレーション経路を整備する

一般的なフィッシング訓練では偽メール対応のみを扱うケースが多いですが、ClickFix は Web ブラウジング中に発生する ため、Web ベースのシナリオを取り入れることが効果的です。

Windows GPO による予防策

利用者教育と並行して、端末側で 不正コマンドが実行されにくい構成 を作っておくことが効果的です。代表的なポリシー設定を整理します。なお、後述のとおり一部のポリシーは業務利用への影響もあるため、適用範囲とテストを慎重に検討することを推奨します。

「ファイル名を指定して実行」ダイアログの無効化

ClickFix（原型）の主要な実行経路である「Win+R」を無効化する GPO 設定です。

ポリシーパス:

ユーザーの構成
  └ 管理用テンプレート
    └ スタート メニューとタスク バー
      └ [スタート] メニューから [ファイル名を指定して実行] メニューを削除する

該当ポリシーを 「有効」 に設定すると、Win+R ショートカット、スタートメニューの「ファイル名を指定して実行」、タスクマネージャーの「新しいタスクの実行」が無効化されます。

ただし、このポリシーは 副作用が大きい ことに注意が必要です。Win+R の無効化に加えて、エクスプローラーや IE のアドレスバーへの UNC パス入力、ローカルドライブ・フォルダの参照経路にも影響 が及ぶケースが報告されています。業務上ファイルサーバへ UNC パスでアクセスする運用がある環境では、適用前の動作検証を強く推奨します。

参考: 管理用テンプレート – Remove Run menu from Start Menu（admx.help）
“Allows you to remove the Run command from the Start menu, Internet Explorer, and Task Manager.”
（[スタート] メニュー、Internet Explorer、タスクマネージャーから [ファイル名を指定して実行] コマンドを削除できます。）
https://admx.help/?Category=Windows_10_2016&Policy=Microsoft.Policies.StartMenu::NoRun

なお、FileFix（エクスプローラーアドレスバー経由）はこの GPO では防げないため、本ポリシーは ClickFix 原型に対する一次防御 と位置づけ、後述の AppLocker / WDAC と組み合わせることが推奨されます。

PowerShell 言語モードの制限（Constrained Language Mode）

PowerShell には、利用可能なコマンドレットや .NET API を制限する Constrained Language Mode が用意されています。このモードを有効化すると、ClickFix で多用される複雑な難読化スクリプトや、.NET 経由のメモリ展開処理が大幅に制限されます。

ただし、Microsoft Learn の公式ドキュメントが明示しているとおり、Constrained Language Mode は単独で運用するのではなく、AppLocker または WDAC（Windows Defender Application Control）と組み合わせる ことが前提です。環境変数や対話的なセッション設定だけで有効化したモードは、容易に解除されてしまいます。

参考: about_Language_Modes（Microsoft Learn）
“PowerShell automatically runs in ConstrainedLanguage mode when it’s running under a system application control policy.”
（PowerShell は、システムアプリケーション制御ポリシー下で実行されている場合、自動的に ConstrainedLanguage モードで動作します。）
https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_language_modes

AppLocker / WDAC によるスクリプト実行制御

AppLocker および WDAC は、実行可能ファイル・スクリプト・MSI を、ハッシュ値や署名・パスベースのルールで制御 する仕組みです。AppLocker のスクリプトルールを有効化すると、PowerShell が自動的に Constrained Language Mode に切り替わり、ClickFix 経由で投下される未署名のスクリプトの実行を抑制できます。

AppLocker の有効化パス:

コンピューターの構成
  └ ポリシー
    └ Windows の設定
      └ セキュリティの設定
        └ アプリケーション制御ポリシー
          └ AppLocker

AppLocker のルールコレクションから「スクリプトのルール」を選択し、強制を有効化します。なお、Windows 11 24H2 環境では 2025 年 5 月のセキュリティ更新までスクリプト強制が機能しない不具合があったことも報告されており、最新の Windows Update 適用は前提条件 となります。

WDAC（現 App Control for Business）はより新しい仕組みで、コード整合性ポリシーによってより強固な制御が可能です。新規導入であれば WDAC を、既存環境への追加であれば AppLocker から段階的に導入する構成が現実的です。

参考: Application Control for Windows（Microsoft Learn）
“App Control for Business policies provide rules to control which apps can run on Windows endpoints.”
（App Control for Business のポリシーは、Windows エンドポイントで実行できるアプリを制御するルールを提供します。）
https://learn.microsoft.com/en-us/windows/security/application-security/application-control/app-control-for-business/

FortiGate を活用したネットワーク多層防御

利用者教育による人的対策に加え、誤って不正コマンドが実行された場合に備えたシステム的な防御も重要です。統合脅威管理（UTM）機器である FortiGate を導入することで、ClickFix 攻撃の各フェーズで多層的な検知・遮断を実現できます。

特に SSL/TLS インスペクション は、ClickFix 経由の通信の多くが HTTPS で行われている現状において、上記の防御機能を機能させる前提条件となります。FortiGate の UTM 機能の全体像については「FortiGate UTM 機能の仕組みと IPS 誤検知のリスクと対処」を、SSL インスペクションの具体的な設定手順については「FortiGate SSL Deep Inspection の設定手順｜証明書警告の回避」を参照してください。

参考: Fortinet / Web Filter Configuration Guide
“FortiGate web filtering uses FortiGuard URL categorization and dynamic threat intelligence to block access to malicious and policy-violating websites.”
（FortiGate の Web フィルタリングは、FortiGuard の URL カテゴリ分類と動的脅威インテリジェンスを用いて、悪意のあるサイトおよびポリシーに違反するサイトへのアクセスをブロックします。）
https://docs.fortinet.com/document/fortigate/7.6.0/administration-guide/954635/web-filter

EDR / SIEM での検知観点

予防制御をすり抜けて実行された場合に備え、検知・対応の観点でもログ分析の設計が重要です。ClickFix 攻撃チェーンで現れやすい特徴的な振る舞いとして、以下が挙げられます。

プロセスの親子関係に着目する

正規業務で発生しにくい親子関係をハイライトする検知ルールが効果的です。

• explorer.exe の子プロセスとして powershell.exe / cmd.exe / mshta.exe / wscript.exe が起動している
• ブラウザプロセス（chrome.exe / msedge.exe / firefox.exe）の子孫として上記のスクリプトホストが起動している
• powershell.exe の起動直後に、外部 IP への HTTPS 通信、または通常使用しない DNS サーバーへの問い合わせが発生している

コマンドラインに含まれる特徴的なパターン

ClickFix で配布される PowerShell コマンドには、検知の手がかりとなる特徴が現れます。

• -EncodedCommand、-enc、FromBase64String といった Base64 デコード処理
• -WindowStyle Hidden、-NoProfile、-ExecutionPolicy Bypass の組み合わせ
• Invoke-WebRequest、Net.WebClient、Invoke-Expression（IEX）の組み合わせ
• IEX (New-Object Net.WebClient).DownloadString(...) のような典型的なダウンローダ構文

侵害発生時の調査観点

万一の侵害が疑われる場合は、以下の観点でログ調査を行うことを推奨します。

• イベントログ（PowerShell Script Block Logging: イベント ID 4104）における不審なスクリプトブロックの実行履歴
• AppLocker / WDAC のイベントログ（イベント ID 8005 / 8007）における拒否ログ
• Sysmon が導入されている場合、プロセス作成イベント（イベント ID 1）と、ネットワーク接続イベント（イベント ID 3）の相関分析
• プロキシ・DNS ログにおける、過去 24 時間以内の不審な外部通信履歴

これらのログを長期保管し、相関分析できる基盤（SIEM）を整備しておくことが、ClickFix のような 検知後の対応速度がカギとなる攻撃 への備えとなります。

まとめ

本記事では、急増を続けるサイバー攻撃「ClickFix」の仕組みと、亜種への対応を含む多層防御の考え方について整理しました。要点は以下の通りです。

• ClickFix は偽のエラー画面・CAPTCHA 画面を介し、利用者自身に PowerShell 等のコマンドを実行させる攻撃手法である。
• Microsoft Defender Experts の観測では、2024〜2025 年に初期侵入の 47% を占め、従来型フィッシングを上回る主要手法となった。
• 国内でもラック JSOC が複数組織での被害を観測しており、日本語環境でも実害が発生している
• 2025〜2026 年にかけて、FileFix（アドレスバー経由）、ConsentFix（OAuth 悪用）、DNS 版 ClickFix（nslookup 経由）などの亜種が登場している。
• EDR ログ上「利用者意図の操作」と区別がつかないなど、構造的に検知が困難な特性を持つ。
• 利用者教育・GPO による予防制御・FortiGate を活用したネットワーク防御・EDR/SIEM での検知の組み合わせが基本となる。
• 万能の対策は存在しないため、突破される前提で防御層を冗長化する設計が重要となる。

以上、最後までお読みいただきありがとうございました。