ClickFixを使う攻撃で、改ざんサイトを通じた配信の広がりと、利用者にコードを実行させる場所の変化が相次いで確認された。Netskopeは2026年9月3日、同じブロックチェーン基盤へ接続する改ざんサイトを5,400件超観測したと公表し、Cisco Talosは9月8日、ブラウザ内で暗号資産を盗む派生手法を報告した。偽の認証や修復手順を信じた利用者が攻撃の実行役になる点は共通するが、その先にある被害は端末への侵入から送金先の改変まで異なる。なぜ攻撃を仕掛けやすくなったのか、そして実行先が変わると防御のどこを見直す必要があるのか。

AD

認証のつもりが、プログラムの実行になる

「人間であることを確認してください」。ClickFixの典型例は、こうした見慣れた認証を装って始まる。改ざんされたサイトに偽のCAPTCHAやCloudflareをまねた画面を重ね、操作した利用者のクリップボードへ不正な命令をコピーする。続いて、Windowsの実行画面やターミナルを開き、貼り付けて実行するよう促す。Microsoftが解析したTerminalFixでも、この流れが使われていた。

利用者の目的はサイトの続きを見ることなのに、途中から端末でプログラムを動かす操作へ切り替わる。Webページの表示だけで完結するはずの認証を口実に、別のアプリへ命令を持ち込ませるのが仕掛けだ。Cloudflareのロゴや処理完了の表示があっても、その命令の正当性は保証されない。

しかも、誘導元が明らかな偽サイトとは限らない。ニュージーランドの国家サイバーセキュリティーセンター(NCSC)は9月2日の警告で、改ざんされたWordPressサイトなどを通じた配布を取り上げた。正しいURLを開いていることと、そこで表示される操作指示を信頼できることは、別の判断になる。

Ars TechnicaのDan Goodin氏は9月11日の記事で、煩雑な認証やWeb操作に慣れた利用者ほど、不可解な指示にも従ってしまうという見方を示した。これは同氏の論評であり、感染の原因を測定した結果ではない。それでも、被害を利用者の不注意だけで説明すると、見慣れた画面や信頼していたサイトを攻撃者が利用する点を見落とす。

改ざんサイトと、署名を要しない配布

Netskopeが9月3日に公表した調査では、直近数カ月の観測期間中、BNB Smart Chain(BSC)のテストネットへ接続する改ざんサイトが5,400件を超え、関係する組織は世界で2,200超に及んだ。個別に調べたサイトの多くはWordPress、一部はPrestaShopで構築されていたが、最初にどう侵入されたかは不明だ。

この数字が示すのは、攻撃の配信に使われたサイトの広がりである。感染したPCやMacの台数でも、訪問者が指示に従った割合でもない。同じ調査にはClickFix画面の代わりにWebRTCで通信する別変種も含まれ、全サイトで同じ感染が成功したという意味にはならない。

配信の仕組みは、サイトに埋め込んだ短いスクリプトが、ブロックチェーン上のスマートコントラクトから次のコードを読み込むものだ。攻撃者はコントラクトを更新することで、多数のサイトが配る内容をまとめて変えられる。開発用テストネットでは実価値のある通貨を支払う必要もなく、Netskopeは削除しにくい配信基盤を低コストで使える点を指摘している。

入口を用意する負担が変わった例は、別の調査にもある。BlueVoyantは6月16日のLorem Ipsum分析で、偽のMicrosoft Teamsインストーラーを配っていた攻撃が、5月末にClickFixへ移ったと報告した。以前は署名付きの配布物や偽ダウンロードサイトに依存していたが、新しい入口は改ざんサイト上の偽ブラウザ更新画面だった。

同社は、Microsoftによる5月19日の不正署名サービスへの対処が転換を促したと、高い確信度で評価している。攻撃者は署名済みインストーラーの供給を失っても、利用者に命令を実行させる方式へ移れる。誘導する相手も、Teamsを探している人から、改ざんサイトを訪れた人へ広がる。

これは全攻撃者の費用や普及率を測った話ではない。ただ、配信コードをまとめて更新できる基盤と、署名付き配布物に頼らない入口は、ClickFixを広げやすくする条件としてつながる。

AD

実行する場所で、被害も変わる

Microsoftが8月末に分析を公表したTerminalFixでは、利用者をWindows TerminalやPowerShellへ誘導し、組織内ネットワークへの通信を中継するプログラムまで導入していた。一方、Talosの9月の事例では、コードを動かす場所がブラウザ内へ移っている。ClickFixは特定のマルウェア名ではなく、利用者を実行へ誘い込む手法として捉える必要がある。

調査と公表時期 利用者に実行させる場所・口実 確認された動作 読み違えてはいけない点
Microsoft/2026年8月末 Windows TerminalやPowerShell/偽認証 組織内の探索と、外部からの通信を中継する機能の導入 後続のランサムウェア展開などは解析対象で未観測
Microsoft/2026年5月6日 macOSのTerminal/容量最適化などの偽修復 認証情報などの窃取、一部でウォレットアプリ改変や常駐化 Finderからのアプリ起動とは検証経路が異なる
Cisco Talos/2026年9月8日 ChromeのアドレスバーやTampermonkey/架空の利益獲得法 ブラウザ内で送金先を書き換え、偽のボーナス表示を追加 OS感染の報告ではなく、特定の暗号資産利用者を狙った事例

出典:MicrosoftのTerminalFix分析macOS分析Cisco Talosの調査。別々の攻撃事例を実行先で比較したもので、感染率や危険度の順位を示す表ではない。

Windows Terminal、macOS Terminal、ブラウザ内の実行先を分けると、防御と被害の違いが見える。Windows側で重いのは、被害端末が社内への中継点になりうることだ。TerminalFixは正規プログラムに不正なDLLを読み込ませ、PNG画像に隠した追加プログラムを取り出す。さらに、組織の端末やアカウントを管理するActive Directoryを探索し、端末側から外部へ接続する「逆向きの通信トンネル」を作る。Microsoftは、解析した一連の動作では後続の横展開やランサムウェア展開を観測していないと明記しているが、感染端末だけを検査して終えるには危険な能力である。

clickfix-execution-paths-comparison.webp

Macでは、アプリの検証が働く場面を取り違えやすい。Microsoftの5月の分析によると、Finderで開くアプリと、Terminalから直接取得して動かすスクリプトは、Gatekeeperの同じ評価を受けない。従来のディスクイメージからアプリを入れる方式から、標準ツールでスクリプトを実行する方式へ移ることで、攻撃者は通常のアプリ配布への依存を減らしていた。Gatekeeper全体が無効になった、という話ではない。日本語で書かれた誘導ページも確認されている。

Talosが解析した暗号資産窃取では、存在しないAPIの欠陥で利益を得られると誘い、利用者にJavaScriptを入れさせた。コードは公開Google Sheetsから取得され、取引画面の送金先やクリップボードのアドレスを書き換える。正規の拡張機能Tampermonkeyを経由する版では、対象サイトへ戻るたびに動作する仕組みもあった。Googleや拡張機能そのものが侵害されたのではなく、利用者が取り込んだ不正コードが、正規サービスを配信と実行に使っていたのである。

したがって、Windowsの特定のショートカットだけを禁止しても、Macやブラウザ内の経路には届かない。何を開かせるかより、出所を確かめていないコードに何をさせるかが共通の判断点になる。

貼り付け警告と、サイト側に残る責任

MicrosoftはTerminalFixへの対策として、Windows Terminalの複数行貼り付け警告や、業務上不要な実行経路の制限を挙げている。Macでも対策は進んでおり、セキュリティー研究者のPatrick Wardle氏は3月31日の技術解析で、macOS 26.4のXProtectに貼り付け保護に関わる機能を確認した。

ただし、複数行への警告は命令の安全性を保証するものではなく、Terminalへの貼り付け対策もブラウザ内のコード実行まで一律に防ぐものではない。認証、更新、容量不足の解決などを理由に、見知らぬ命令を実行するよう求められたら、その操作を止めて、独立にたどった公式の案内を確認する。コピー済みでも、確かめるために実行してはいけない。

すでに不審な指示を実行した場合は、画面を閉じただけで解決したとは判断できない。NCSCは、誘導に触れた利用者へ端末のセキュリティー検査やパスワード変更、侵害の兆候の確認を促す案内を示している。業務端末なら、何を実行したかを管理担当へ伝えることが調査の出発点になる。

サイト運営者にも作業が残る。NCSCは、偽認証の表示を消すだけでなく、最初の侵入経路や再感染につながる仕組みを取り除くよう求めている。WordPress本体の更新、不要なプラグインの削除に加え、管理権限の見直しやファイル改変の監視も必要になる。スキャナーにだけ正常なページを見せる変種があるため、一度の自動検査で異常が出なかったことも、復旧の十分な証拠にはならない。

対策を評価する際は、偽の画面が消えたかに加え、利用者が別の場所で不正コードを実行する経路と、サイトが再び改ざんされる原因を断てたかまで確かめる必要がある。