無数の開発者向けドキュメントに埋め込まれてきた、ありふれたサンプルURLが、実際の攻撃インフラへと変貌しました。問題のドメインthird-party[.]comは、長年にわたり外部サービスを示す無害なプレースホルダーとして開発者に使われてきました。ところが少なくとも2026年6月以降、このドメインは悪意あるコンテンツを配信しています。標的はWindows環境です。ドメインにアクセスすると偽のCloudflare認証画面が表示され、巧妙なソーシャルエンジニアリングによって、ユーザーがWindowsの「ファイル名を指定して実行」ダイアログから破壊的なコマンドを手動で実行するよう仕向けられます。
この異常を最初に検知したのは、Manifoldのセキュリティ研究者です。AIエージェントの公開機能と、Model Context Protocol（MCP）サーバーを支えるドキュメントを調査していた際、自動システムがthird-party[.]comを参照するファイルを検出しました。同社の脅威インテリジェンスフィードが、このドメインをすでにフィッシングの指標として分類していたためです。その後のフォレンジック調査で、元のドキュメントやコード例は一切改ざんされていないことが確認されました。変化があったのは、参照先のアドレスで公開されているコンテンツだけです。無害だったプレースホルダーが、攻撃の誘い文句を配信する仕掛けに変わっていました。技術的な詳細は、Manifold Securityのブログ記事「third-party.com placeholder domain now serves ClickFix」で読めます。
影響範囲の広さ
当初の控えめな見積もりでは、このドメインは約1,700の公開GitHubリポジトリにまたがる、1,500以上のファイルに存在していました。対象にはChromium、Sanity、Vercelといった信頼性の高い組織の資料も含まれます。その後、より厳密なURL解析を行った結果、ヒット数は672ファイルに絞り込まれました。ただしGitHubは、この種の検索結果を概数として扱っています。したがってこれらの数字は網羅的な一覧ではありません。それでも、予約されていないこのドメインが、世界中の開発現場で「無害なサンプル」として深く浸透していた規模の大きさがわかります。
Windows OSでアクセスすると、悪意あるページはCloudflareの標準的なセキュリティチェックを完璧に模倣します。隠されたJavaScriptが、PowerShellコマンドを即座にユーザーのクリップボードへ書き込みます。同時に画面上の偽の指示が、被害者に「Win+R」キーを押し、クリップボードの内容をダイアログに貼り付けて「Enter」を押すよう促します。このコマンドはelxxvvx[.]xyzに静かに接続し、Invoke-RestMethodコマンドレットで第2段階のスクリプトを取得します。続いてInvoke-Expressionにより、そのペイロードをメモリ上だけで実行します。エラーメッセージも意図的に抑制し、完全な隠密性を保つ仕組みです。
一方、macOSやLinuxから同じアドレスにアクセスすると、サーバーは「アクセスにはWindows PCが必要です」と表示するだけの無害なページを返します。User-Agentに応じたこの出し分けにより、多くの自動セキュリティスキャナーや静的解析ツールの検知をすり抜けています。実際、IPFireのブロックリストは7月7日にこのドメインを悪意あるものとして一時的に登録しました。ところが10日後には、理由が不明なまま登録を解除しています。この間もページは、標的であるWindowsユーザーに悪意あるペイロードを配信し続けていました。
ClickFixの手口と対策
Manifoldが技術的な検証を行った時点では、第2段階のコマンド＆コントロール（C2）サーバーelxxvvx[.]xyzは応答しませんでした。このため研究者は、感染チェーンの最終段階や最終的なペイロードを確認できていません。それでもthird-party[.]comは、9月23日の時点でもWindowsの訪問者に偽の誘導画面を配信し続けていました。幸い現時点では、特定のリポジトリ内のリンクが原因で開発者やアプリケーションが実際に感染したという事例は、セキュリティ機関から確認されていません。
根本的なリスクは、リポジトリ自体の侵害ではありません。予約されていない現実のドメインを、永遠に中立なサンプルとして扱ってきた危うい習慣にあります。Chromiumプロジェクトでは、このドメインが膨大なドキュメントのあちこちに登場します。SanityはPlaywrightのテスト例で使い、VercelのTurborepoはオリジン検証テストに直接組み込んでいました。さらに懸念されるのは、一部のAIエージェントのスキルにthird-party[.]com/widget.jsを取得せよという明示的な指示が含まれていることです。自動化ツールがこれを文字どおり実行すれば、深刻な事態を招きかねません。開発者向けリソースの悪用については、「placeholder domain used in dev docs now serves ClickFix attacks」も参照してください。
ClickFixの手口は、信頼できる文脈と、ユーザー自身が自発的に実行する悪意あるコマンドとの心理的な隔たりを埋めることに根本的に依存しています。9月初旬には、別の攻撃者グループが、Cloudflareのインフラを利用した正規のWebページを同様に乗っ取りました。訪問者に「Win+R」の実行を求める、同じ偽の認証画面を表示していました。third-party[.]comの場合、攻撃手法そのものに新しさはありません。しかし、被害者の信頼の源は他に例がありません。このアドレスは長年、無害な技術的プレースホルダーを装ってきたからです。
過去のWHOISレコードによれば、このドメインが最初に登録されたのは1996年です。今回の悪意あるキャンペーンより数十年も前で、当初から悪意があったことを示す証拠はありません。広く知られるexample.com、example.org、example.netとは異なり、third-party[.]comはInternet Assigned Numbers Authority（IANA）によってドキュメント用に予約されていません。そのため、運用されるコンテンツは現在の正当な登録者の意向に完全に左右されます。予約されていないアドレスの基盤が変われば、数十年分の過去のコード例が自動的に、しかも危険な形で向きを変えます。ユーザーは、新たに構築された敵対的なリソースへと誘導されることになります。
セキュリティ専門家は、ドキュメントやテストのシナリオには、IANAが正式に予約したドメインだけを使うよう、開発者、テクニカルライター、AI設計者に強く勧めています。あわせて各組織には、公開済みの資料を積極的に監査することが求められます。自組織が管理していない、予約外のサードパーティ製アドレスへの参照を洗い出し、排除してください。また、セキュリティチームは、自動アラートを止めるためだけに、見慣れない稼働中のドメインを無差別にホワイトリストへ登録することは避けるべきだとしています。最後に、社内のURL検証では、開発者は厳密な構文検証と、未検証の外部サーバーへ実際に接続する危険な行為とを、きちんと切り分ける必要があります。
翻訳元: https://meterpreter.org/weaponized-placeholder-domain-clickfix-malware/
