ClickFixは、偽のCAPTCHA画面や偽エラーを見せて「修復手順」を装い、利用者自身にWin+Rからコマンドを貼り付け・実行させるソーシャルエンジニアリング攻撃です。マルウェア本体を利用者がダウンロードするのではなく、クリップボードに仕込まれたコマンドを本人の手で走らせる点が特徴で、ファイル検査中心の防御をすり抜けます。この記事では、ClickFixの定義とMITRE ATT&CK上の分類、偽CAPTCHAからコマンド実行に至る攻撃連鎖、FileFixやWindows Terminal型などの亜種、RunMRUレジストリやプロセス系譜での検知、そしてPowerShell制御・AppLocker・EDR相関ルールといった実装者向けの防御を、優先度を付けて整理します。手元で痕跡を確かめるPowerShellスクリプトとKQLクエリ、実行ダイアログを止める設定例も添えました。
まとめ：ClickFixはユーザー操作を悪用する攻撃連鎖と実装側の防御優先度
ClickFixの核心は、正規のダウンロードやマクロを介さず、利用者にpowershell.exeやmshtaを直接実行させる誘導にあります。「ファイルを開かせない」型の防御だけでは止まりません。実装側でまず固めるのは、PowerShellの実行制御とログ取得、AppLockerやWDACによるスクリプトエンジンの許可制御、そしてEDRのプロセス系譜相関の3層です。利用者への注意喚起は入口を狭める補助であって、単独の防波堤にはなりません。
検知では、実行ダイアログの履歴が残るRunMRUと、explorer.exeからpowershell.exeが起動する不自然な親子関係が起点になります。攻撃はFileFixやWindows Terminal経由型へと枝分かれしており、単一の文字列シグネチャやRunMRUだけに依存する構えは早晩崩れます。組織としては、盗まれる資格情報の被害を局限するために多要素認証やISMSの運用と接続して考えるのが妥当です。
ClickFixとは何かを定義と名前の由来・MITRE ATT&CKの分類で整理
ClickFixは特定のマルウェア名ではなく、感染させるための「手口」の呼び名です。どのマルウェアを最後に送り込むかは攻撃者ごとに違い、共通しているのは利用者の手で正規ツールを動かさせる誘導の部分にあります。
ClickFixという呼び名の由来と2024年初頭から広がった観測の経緯
呼び名は、偽のエラー画面に置かれた「修正（Fix）」ボタンをクリックさせ、直すつもりの利用者にコマンドを実行させる誘導に由来するとされる呼び名です。Microsoft Security Blogの2025年8月21日付の分析記事によると、Microsoftは2024年初頭からこの手口の増加を追っており、2024年3月から6月にかけてStorm-1607によるメール経由のキャンペーンを確認しています。同記事は、企業と個人の端末を合わせて毎日数千台を狙うキャンペーンを観測していると述べ、配信経路としてフィッシングメール、不正広告、改ざんサイトを介したドライブバイを挙げています。
国内でも2025年3月に警視庁のサイバーセキュリティ対策本部が偽のCAPTCHA画面への注意喚起を出し、トレンドマイクロが2025年6月11日に公開した調査では、フィッシングメール・不正広告・SEOポイズニングの3経路から偽CAPTCHAへ誘導する事例が報告されました。手口の骨格は、人をだまして操作させるソーシャルエンジニアリングの手口の分類と実装者向けの技術的対策で整理した類型のうち、「操作の代行」にあたります。
MITRE ATT&CK T1204.004における悪性コピー＆ペーストの定義
攻撃手法の共通辞書であるMITRE ATT&CKでは、ClickFixはT1204.004「User Execution: Malicious Copy and Paste」に分類されています。親技術のT1204は「利用者の操作による実行」で、その下に悪性リンク・悪性ファイルと並んでコピー＆ペースト型が独立した副技術として置かれた構造です。対象プラットフォームはWindowsに限らず、Linuxと macOS も含まれます。
分類が決まっていると、検知ルールや演習シナリオに同じIDで紐づけられます。SIEMの相関ルールやEDRのアラートにT1204.004のタグを付けておけば、亜種が増えても「手動実行を誘う攻撃」という単位で件数を追えます。
ClickFixの仕組みと偽CAPTCHAからコマンド実行に至る攻撃連鎖の全体像
ClickFixは3つの動作を連鎖させます。偽の確認画面で利用者を焦らせ、クリップボードに悪性コマンドを忍ばせ、キーボード操作で実行させる、という流れです。攻撃者はコード署名やダウンロードの警告を避けられ、利用者は「自分で入力した操作」と認識するため被害の自覚が遅れます。
攻撃の起点となる偽CAPTCHA・偽Windows Update・偽エラーの誘導画面
入口は複数あります。「私はロボットではありません」を模した偽のBot確認、偽のブラウザ更新、偽のドキュメント表示エラーなどで、いずれも「認証を完了するには次の手順を実行してください」と指示します。偽CAPTCHAが置かれるのは攻撃者が用意したサイトだけではありません。正規の企業サイトが改ざんされ、そこへ偽の確認画面を差し込まれる例もあり、画面のデザインは正規サービスに酷似します。URLだけで真偽を見分けるのは困難です。偽のウイルス感染警告で電話をかけさせ、遠隔操作ソフトを入れさせる近縁の手口は、サポート詐欺とは？業務端末で偽警告が出たときの初動と再発防止策で組織の初動とあわせて整理しています。
Win+Rとクリップボード改ざんを組み合わせるコマンド実行の流れ
典型手順は、Win+Rで「ファイル名を指定して実行」を開かせ、Ctrl+Vで貼り付け、Enterを押させる3ステップです。貼り付け内容は、偽ページのJavaScriptがnavigator.clipboardで事前に書き換えています。利用者は短い「確認コード」を貼ったつもりでも、実際には長いダウンロード実行コマンドが走る仕掛けです。表示上は無害な文字列に見せ、末尾に本命のコマンドを隠す手法も観測されています。
mshtaとPowerShellが担うコマンド実行とLOLBinの悪用
実行に使われるのは、OS標準の正規バイナリ、いわゆるLOLBinです。mshtaにリモートのHTAを読ませる型と、powershell.exeでiwr（Invoke-WebRequest）やirm（Invoke-RestMethod）でペイロードを取得しiex（Invoke-Expression）で即時実行する型が中心になります。トレンドマイクロの前掲調査も、mshta経由とBase64エンコードしたPowerShellによるメモリ内実行の2方式を挙げ、ファイルベースの検出を回避する点を指摘しました。rundll32・wscript・curlが使われる例もあり、いずれも「正規ツールの範囲内」で完結するため、実行ファイルの評判ベースの検知が効きにくいのが厄介な点です。
最終ペイロードのLumma Stealer・NetSupport RATへの感染
最終段は情報窃取型が目立ちます。Microsoftの前掲記事では、2024年初頭以降に最も多く見られたペイロードとしてLumma Stealerを挙げ、ほかにNetSupport・AsyncRAT・XWormといった遠隔操作ツール、Latrodectusなどのローダー、銀行情報を狙うLampionを確認しています。macOS向けには2025年6月にAtomic macOS Stealerを配る事例が報告されました。盗まれるのはブラウザ保存の資格情報、Cookieやセッショントークン、暗号資産ウォレットで、多要素認証を回避するセッション奪取につながる点が実害を大きくします。
FileFixなど亜種の広がりとEDRテレメトリで見抜く検知の着眼点
ClickFixは単一の手口ではなく、実行トリガーを差し替えた派生が続きます。検知を1つの起点に固定すると取りこぼすため、痕跡が残る場所と挙動の相関で押さえます。
FileFix・WebDAV net use型・Windows Terminal型の派生
FileFixは、実行ダイアログの代わりにファイルエクスプローラーのアドレスバーへ貼り付けさせる派生です。研究者mr.d0xが2025年6月23日に公開した概念実証では、ブラウザのファイルアップロード画面からエクスプローラーを開かせ、#以降をコメントとして扱うPowerShellの仕様を使ってコマンドの後ろに偽のファイルパスを並べ、利用者には社内文書の場所に見せる手口が示されました。さらに、net useでWebDAVをマウントしてpowershell.exeやmshtaを経由しない亜種も報告され、スクリプトエンジン監視だけに寄せた防御を回避します。
2026年3月には、Microsoftの脅威インテリジェンスが、Win+Xに続けてIを押させてWindows Terminal（wt.exe）を直接開かせる亜種を報告しました。実行ダイアログを経由しないため、Win+Rを無効化した環境や「実行ダイアログを開くな」という社内教育をすり抜けます。「Win+Rを塞げば安全」という前提は成り立ちません。
RunMRUレジストリに残る実行痕跡とLOLBin混入の見分け方
実行ダイアログを使う型なら、HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRUに入力履歴が残ります。ここはインシデント後の有力な調査源です。値にpowershell・mshta・rundll32・wscript・curl・wgetといったLOLBinが混ざっていれば、手動実行を伴う侵害を疑います。逆に、FileFixやWindows Terminal型はRunMRUを通らないため、この経路に記録が無いことは「侵害されていない」根拠になりません。
explorer.exeからpowershell.exeが起動するプロセス系譜の検知
挙動側の強いシグナルは親子関係です。explorer.exeが直接powershell.exeやmshtaを起動する系譜は、通常のアプリ操作では稀で、EDRやWindowsイベントで捕捉できます。Event ID 4688（プロセス作成）の監査を有効にすると親プロセス名とコマンドラインが記録されるため、親がexplorer.exeのスクリプト実行を洗い出すことが可能です。Windows Terminal型ではwt.exeとWindowsTerminal.exeの配下でPowerShellが動くので、この2つも親プロセスの監視対象に加えます。系譜を端末横断で追う仕組みはEDRとは？EPP・XDRとの違いと検知の仕組みで詳しく扱いました。単発のプロセス名ではなく、系譜と直後の外部通信をひとまとまりで見るのが検知の勘所です。
クリップボードの貼り付け内容とコマンド文字列を突き合わせる監視
入口に近い層では、クリップボード経由の異常を拾えます。ブラウザ操作の直後に、長いエンコード文字列やLOLBin名を含む内容が貼り付けられ、そのまま実行に至る流れは正常業務ではまず起きません。DLPやEDRのクリップボード可視化機能があれば、貼り付け文字列とその後の子プロセス起動を突き合わせる相関ルールが有効です。ここは万能ではなく、あくまでプロセス系譜検知を補う二次シグナルと位置づけます。
RunMRUの点検とKQLの追及クエリでClickFixの実行痕跡を確かめる手順
ここからは、手元の端末と管理基盤で実際に痕跡を確かめる作業です。端末単位で見るならPowerShellのスクリプト、組織全体を見るならMicrosoft Defender XDRの高度な追及（Advanced Hunting）のクエリを使います。
PowerShellでRunMRUの履歴を読みLOLBin混入を判定するスクリプト
次のスクリプトは、ログオン中の利用者のRunMRUを読み、LOLBin名を含む履歴を上に並べます。管理者権限は不要で、Windows PowerShell 5.1とPowerShell 7.6系のどちらでも動きます。PowerShell 7系を入れていない端末への導入はPowerShellのインストール手順｜7.6 LTSをwinget・MSIで入れる方法を参照してください。
# RunMRU（実行ダイアログの入力履歴）を読み、LOLBinを含む行を先頭に表示する
$path = 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU'
$lolbin = 'powershell|pwsh|mshta|rundll32|wscript|cscript|curl|wget|certutil|bitsadmin|msiexec'
$item = Get-ItemProperty -Path $path -ErrorAction SilentlyContinue
if (-not $item) { Write-Output 'RunMRUなし（実行ダイアログ未使用か履歴削除済み）'; return }
$item.PSObject.Properties |
Where-Object { $_.Name -match '^[a-z]$' } | # a〜zの値だけが履歴本体（MRUListは並び順）
ForEach-Object {
$cmd = $_.Value -replace '\\1$', '' # 末尾に付く「\1」を除去
[pscustomobject]@{
Slot = $_.Name
Suspect = [bool]($cmd -match $lolbin)
Command = $cmd
}
} |
Sort-Object Suspect -Descending |
Format-Table -AutoSize -WrapSuspectがTrueの行があれば、そのコマンドの宛先URLとファイル名を控え、同じ時刻帯のプロセス作成ログと突き合わせます。開発者が日常的にpowershellを実行ダイアログから起動する端末では誤検知が増えるため、宛先が外部URLかどうかを2段目の判定に加えると絞り込めます。
Defender XDRの高度な追及でRunMRU書き込みを洗うKQLクエリ
組織全体を一度に見るなら、Microsoftの前掲記事が示した追及クエリが出発点になります。前半4行は同記事の記述どおりで、後半はLOLBin名での絞り込みと出力列を足したものです。
DeviceRegistryEvents
| where ActionType =~ "RegistryValueSet"
| where InitiatingProcessFileName =~ "explorer.exe"
| where RegistryKey has @"\CurrentVersion\Explorer\RunMRU"
| where RegistryValueData has_any ("powershell", "mshta", "curl", "rundll32", "wscript")
| project Timestamp, DeviceName, InitiatingProcessAccountName, RegistryValueData
| order by Timestamp descRunMRUを通らない亜種には、プロセス系譜側のクエリを並走させます。次は、エクスプローラーとWindows Terminalを親に持つPowerShellやmshtaのうち、ダウンロードや動的実行の語を含むものを抜き出す例です。
DeviceProcessEvents
| where InitiatingProcessFileName in~ ("explorer.exe", "wt.exe", "WindowsTerminal.exe")
| where FileName in~ ("powershell.exe", "pwsh.exe", "mshta.exe")
| where ProcessCommandLine has_any ("iwr", "irm", "iex", "Invoke-WebRequest", "Invoke-Expression", "FromBase64String", "http")
| project Timestamp, DeviceName, AccountName, InitiatingProcessFileName, ProcessCommandLine
| order by Timestamp descDefender XDRを使っていない環境でも、Sysmonやイベント4688をSIEMへ集めれば同じ条件で相関を組めます。収集と相関の設計はSIEMとは？仕組みとIPS・SOC・EDRとの違いにまとめています。
ClickFix対策で実装者が先に固める防御と過剰になりやすい線引き
対策は数を並べるより順序が要点です。ClickFixは「利用者が正規ツールを実行する」構造なので、実行そのものを制御・記録する層から着手し、次に検知、最後に入口の封鎖と教育へ広げます。何を優先し、どこで過剰になるかを条件付きで示します。
先に固める3層はPowerShell制御・AppLockerとEDR相関ルール
最初に効くのは実行制御と可視化です。PowerShellで実行された中身を記録するための設定は、ScriptBlockログ（Event ID 4104）の有効化です。about_Language_Modesの公式ドキュメントによると、AppLockerやWDACのポリシー下ではPowerShellが自動で制約言語モード（ConstrainedLanguage）になり、許可された型以外の.NETとCOMの呼び出し、任意のC#コードを読み込むAdd-Typeが使えなくなります。iexで流し込まれたスクリプトもこの制約下で動くため、.NETを直接呼ぶローダーは失敗しやすくなります。実行ポリシーの変更だけでは容易に迂回されるため、それ単独に頼りません。
次にAppLockerやWDACで許可制のスクリプト・バイナリ実行に寄せ、業務で不要ならmshtaを止めます。最後にEDRで前述の系譜相関を常時稼働させる。この3層の並びが費用対効果の軸になります。
| 防御レイヤ | 具体策 | 位置づけ |
|---|---|---|
| PowerShell制御 | ScriptBlockログ・制約言語モード | 実行と痕跡の可視化 |
| 実行許可制御 | AppLocker・WDAC・mshta停止 | 正規ツール悪用の遮断 |
| 挙動検知 | EDRの親子プロセス相関 | 亜種横断の最終網 |
| 入口・人 | 実行ダイアログ制限・教育 | 入口を狭める補助 |
表の上2層を止めると被害の実行自体が起きにくく、下2層は取りこぼしと未知亜種への保険になります。予算が限られるなら上から埋めるのが妥当です。
実行ダイアログの無効化とScriptBlockログ有効化を設定する記述例
Microsoftの前掲記事は、業務で使わないなら実行ダイアログを止めるよう勧めており、グループポリシーでは「ユーザーの構成＞管理用テンプレート＞スタートメニューとタスクバー＞［ファイル名を指定して実行］メニューをスタートメニューから削除する」が該当します。ドメイン外の検証端末では、同じ設定をレジストリで入れられます。ScriptBlockログの格納先はWindows PowerShell 5.1のabout_Loggingに記載されたポリシーキーです。
:: 実行ダイアログ（Win+R）を無効化する（対象ユーザーで実行・再ログオン後に反映）
reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer" /v NoRun /t REG_DWORD /d 1 /f
:: Windows PowerShell 5.1のScriptBlockログを有効化する（管理者で実行）
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 /f有効化した後は、次のPowerShellで動的実行やBase64復号を含むスクリプトブロックを拾えます。記録されるのは新しく起動したセッションからです。
Get-WinEvent -FilterHashtable @{ LogName = 'Microsoft-Windows-PowerShell/Operational'; Id = 4104 } -MaxEvents 200 |
Where-Object { $_.Message -match 'iex|Invoke-Expression|FromBase64String|mshta' } |
Select-Object TimeCreated, @{ n = 'Head'; e = { $_.Message.Substring(0, [Math]::Min(200, $_.Message.Length)) } }ScriptBlockログには、スクリプトが扱った資格情報が残る場合があります。公式ドキュメントも診断以外の用途ではProtected Event Logging（ログの暗号化）の併用を勧めているため、ログを集約する前に暗号化の要否を決めておきます。
mshtaやスクリプトエンジンの無効化を採用する条件と見送る場面
ここは立場を明確にします。mshtaを業務で使っていない環境では、AppLockerやWDACで実行を止めるべきです。HTA型ClickFixの実行段を丸ごと断てるうえ、正規業務への影響がまず出ません。一方、レガシー社内ツールがHTAやVBScriptに依存している環境で一律無効化に踏み切るのは見送ります。業務停止のリスクが検知強化の効果を上回りやすく、この場合は許可リストでの限定と監視ログの厚みで代替するのが現実解です。全環境で一律禁止、という設計は過剰になりがちです。
実行ダイアログの無効化も同じ考え方で判断します。一般の事務端末なら採用してよく、管理者や開発者の端末は運用負荷が上がるので対象から外します。ただし前述のWindows Terminal型には効かないため、これを主対策に据えるのは誤りです。
自社サイトが偽CAPTCHAの配信元にされる改ざんと脆弱性診断の要否
ClickFixは「被害者の端末」の問題として語られがちですが、Webサイトを運営する側は加害の踏み台にされる立場でもあります。CMSのプラグインや管理画面の脆弱性を突かれて改ざんされると、訪問者に偽CAPTCHAを表示するスクリプトを埋め込まれ、自社ドメインの信用で利用者をだます配信元になってしまう構造です。改ざんの入口は端末側の対策では塞げないため、公開サイトを持つ組織では、Webアプリケーションとサーバーの弱点を定期的に洗う脆弱性診断・セキュリティ診断を検討の対象に入れます。外部からスクリプトを読み込む箇所が多いサイトほど、改ざん検知とあわせて点検の優先度を上げる判断になります。
注意喚起の限界とISMS・多要素認証で被害を局限する組織側の防御
利用者教育は入口を狭めますが、巧妙な偽画面を全員が見抜く前提は置けません。だからこそ、突破された後の被害を局限する設計を組織側で持ちます。窃取された資格情報の悪用を抑えるうえで、多要素認証の導入判断は二段階認証とは何か、二要素認証・多要素認証との違いと導入判断の整理が土台になります。セッショントークンごと盗まれる攻撃には、フィッシング耐性のある方式を選ぶ必要があり、実装方式は多要素認証（MFA）とは？3要素と実装方式・耐フィッシングMFAで比較しました。盗まれたIDの不正利用を検知する側の仕組みはITDRとは？EDRとの違い・検知の仕組みと導入判断が扱っています。
検知ルールの整備や運用体制を外部へ相談する場合の要件は、情報セキュリティの3要素とISMSの基本、外注時の要件にまとめており、ここが発注検討の入口です。偽CAPTCHAへの誘導はメールから始まる例も多く、入口側の対策はフィッシング詐欺の成立の仕組みと実装者向けの技術的対策と重なります。ClickFixが上位に食い込む脅威地図は情報セキュリティ10大脅威2026とIPAの読み方と合わせて確認すると、対策の優先度を経営層と共有しやすくなります。
よくある質問
ClickFixの検知・対応・亜種について、実務でよく挙がる質問に答えます。
ClickFixに感染したかもと思ったら何をすればよいですか？
まず端末をネットワークから切り離し、電源は切らずに揮発情報を保全します。RunMRUの履歴、直近のプロセス作成ログ、外部通信の宛先を確認し、ブラウザに保存した資格情報やセッションを侵害前提で無効化・再発行します。情報窃取型はセッショントークンごと盗むため、パスワード変更だけでなく該当アカウントのサインアウトと多要素認証の再登録まで行うのが安全です。RunMRUに記録が無くても、FileFixやWindows Terminal型の可能性は残ります。
偽のWindows Update画面が出たらClickFixですか？
その可能性が高い誘導です。偽のWindows Update、偽のブラウザ更新、偽のCAPTCHAは、いずれもClickFixの入口として使われます。共通点は「更新や認証を完了するにはコマンドを実行してください」と手作業を促す点にあります。正規の更新でユーザーにWin+Rやターミナルへコマンドを貼り付けさせる運用は存在しないため、その指示自体が危険信号だと判断してください。
MacやスマートフォンもClickFixの標的になりますか？
手口の中心はWindowsですが、考え方は他OSにも及びます。MITRE ATT&CKのT1204.004はLinuxとmacOSも対象に含め、2025年6月にはmacOSのターミナルへコマンドを貼らせてAtomic macOS Stealerを入れる事例が報告されました。「利用者に正規機能を手動実行させる」という骨格は共通で、OSごとの実行経路が違うだけと捉えておくのが妥当です。
ウイルス対策ソフトやEDRだけでClickFixを防げますか？
単体では不十分です。ClickFixは正規のLOLBinを使うため、ファイル評判ベースの検知は回避されやすく、EDRも親子プロセスの相関ルールを整えて初めて効きます。AppLockerやPowerShellの実行制御と組み合わせ、実行段を止める層と挙動を捕える層を重ねる前提で構えてください。製品の導入だけで完結する対策ではありません。
ClickFixとFileFixは何が違いますか？
誘導先の入力欄が違います。ClickFixは実行ダイアログ（Win+R）へ貼り付けさせるのに対し、FileFixはファイルアップロード画面から開いたエクスプローラーのアドレスバーを使わせる派生です。狙いと最終ペイロードは同系統ですが、FileFixはRunMRUを通らないため、検知の着眼点がずれます。両者を同じ「手動実行を誘う攻撃」として扱い、プロセス系譜で横断的に監視するのが実務的です。
関連記事
- 二段階認証とは？二要素認証・多要素認証との違いと企業の導入判断：ClickFixで窃取された資格情報の悪用を抑える被害局限策として。
- 情報セキュリティとは？3要素・ISMSの基本と外注時の要件：検知ルール整備や運用体制を外部に相談する際の要件整理に。
- 情報セキュリティ10大脅威2026とIPAの読み方：ClickFixを含む脅威の全体像と対策優先度の共有に。
- サプライチェーン攻撃とは？起点別3類型と最新事例・対策の優先順位：ClickFixが初期侵入として連鎖する攻撃の広がりの理解に。
- ITDRとは？EDRとの違いと検知の仕組み・導入判断を実装者向けに解説：ClickFixで窃取された資格情報の不正利用を検知・対応する仕組みとして。
- OWASPとは？主要プロジェクトの全体像とアプリ開発への組み込み方：セキュア開発の観点で防御を設計に組み込む参考に。
