海外の掲示板Redditに投稿されたMacユーザーの報告と、
そこに集まったコメントを読んで、要点を整理したものです。
読んでいて背筋が冷えました。
特殊な操作をしたわけではないからです。
また、怪しいサイトを掘り当てたわけでもありません。
やったことは3つだけ。
検索して、上位に出てきた公式っぽいページを開いて、書かれていたコマンドを実行した。
それだけです。
何が起きたのか
投稿者は、Claude Codeのインストール方法を検索しました。
すると、検索結果の1ページ目に公式のインストール手順そっくりのページが並びます。
URLを見ても、違和感はなかったそうです。
正体は、Anthropicのドメイン上で公開されたアーティファクトでした。
Claudeが生成した成果物を、ページとして共有できる機能です。
つまり、ドメインは本物。
しかし中身は、ユーザーが作ったものでした。
ページには、curlでスクリプトを取得してbashに渡す形式のコマンドが載っていました。
見慣れた形です。
普段のインストール手順と大きく違わない。
そう判断した投稿者は、コマンドをそのまま実行します。
直後に、macOSのパスワード入力を求めるダイアログが出ました。
ただ、公式ドメインから来た手順です。
そのため、ここでも強くは疑わなかったといいます。
数秒後、「やってしまった」と気づいてWi-Fiを切断。
そこから数時間かけて、パスワードを変更し、接続中の機器を切り離し、各アカウントの設定を洗い直しました。
落ち着いてからマシンを調べると、常駐用のlaunch agentが複数仕込まれていました。
さらに、追加の権限まで要求してくる状態だったそうです。
最終的に、ディスクを消して環境を作り直しました。
なお、問題のページはその後削除されたと投稿者が報告しています。
ドメインは、もう判断材料の全部ではない
コメント欄で何度も指摘されていたのが、この点でした。
「公式ドメインかどうか」だけを信頼の根拠にする時代は、もう終わっています。
似た構図は、前からありました。
google.comの配下で公開されたGoogleドキュメントに、偽のログイン画面を作り込む詐欺です。
ホスト元が大手でも、そこに置かれた中身までは保証されません。
ユーザー生成コンテンツを共有できるサービスは、原理的に同じリスクを抱えています。
しかも今回は、そのページが検索結果の上位に出ていました。
攻撃者からすれば、信頼されたドメインと検索流入を同時に手に入れたことになります。
よくできた手口だと言わざるを得ません。
コメント欄は真っ二つに割れた
反応は、綺麗に二分されました。
片方は批判です。
「curlの結果をbashに流すなんて論外だ」「Homebrewを使え」。
もう片方は、「注意喚起してくれてありがとう」という感謝でした。
その批判に対して、なかなか痛烈な返しがあります。
ではそのHomebrewは、公式サイトでどうインストールを案内しているのか。
curlで取得したスクリプトを、その場で実行する形式です。
まさに同じでした。
さらに、Claude Code側の推奨インストール方法も同じ構造だと複数のコメントが指摘しています。
つまり、開発者側が長年その手順を「普通のこと」として提示し続けてきたわけです。
ユーザーだけを責めても、この構造は変わりません。
ここは、個人的にもうなずくところでした。
擁護側で印象に残ったコメントも紹介します。
ミスを認めた投稿には、必ず晒し上げが来る。
それがSNSというもの。ただし今回批判している人の半分は、条件がそろえば同じ引っかかり方をするだろう、と。
一方で、厳しめながら本質を突いた意見もありました。
投稿者は「誰もが四六時中警戒していられるわけではない」と書いています。
これに対し、まさにその油断こそが狙われているのだ、という指摘です。
だから注意力に頼るのではなく、自分を止める仕組みを先に作っておけ、と。
人間の集中力を前提にした防御は、いつか必ず破られます。
明日からできること
コメント欄で挙がっていた対策のうち、手間の割に効くものをまとめます。
- スクリプトをその場で実行しない：一度ファイルとして保存し、エディタで開いて中身を読む。かかるのは30秒程度です
- ドメインだけでなくパスを見る：公式の手順は、たいていドキュメント用のパス配下にあります。共有ページのような場所にあれば、そこで一度止まりましょう
- 直後のパスワード要求を警戒する：何かを常駐させようとしている可能性があります
- 検索から入る癖を見直す：公式サイトはブックマークしておき、そこから辿る。検索結果の最上部にある広告枠は踏まない
- パッケージマネージャを経由する：Homebrewやアプリストアから入れられるものは、そちらで済ませる
最後の項目には、補足が要ります。
前述のとおり、Homebrew自体のインストールは同じ形式です。
ただし一度入れてしまえば、その後に判断を迫られる機会は確実に減ります。
ツールで守る方法もあります。
macOSには、標準でXProtectとGatekeeperが備わっています。
それに加えて、コメントではObjective-See製のツールが紹介されていました。
- BlockBlock：新しい常駐の仕組みを検知する
- LuLu：想定外の外向き通信を遮断する
- KnockKnock：常駐プログラムを手動で棚卸しする
今回のように「気づかないうちに常駐させられる」パターンには、こうした層が効いてきます。
共有機能そのものへの問い
議論は、もう一段深いところにも及びました。
生成物を公開共有できる機能を、公式と同じドメインで提供してよいのか。
そういう問題です。
アーティファクトは、既定では非公開になっています。
共有するには、自分で設定を変える必要があります。
だから騒ぎすぎだ、という意見も出ました。
実際その仕様は、Googleドライブの共有リンクと大きくは違いません。
それでも、投稿者の反論には説得力がありました。
共有されたページが検索結果に載る。
しかも「これは第三者が作ったものです」と明示されない。
それなら、リスクは残ります。
実際、投稿者が見た画面にはユーザー生成コンテンツだと分かる手がかりが見当たらなかったそうです。
Googleドキュメントを使った詐欺は、今も無くなっていません。
そう考えると、事業者側の対応は結局「見つけ次第消す」に落ち着きがちなのでしょう。
今回のページも、そうやって削除されました。
ただし削除されるまでの間に何人が踏んだのかは、誰にも分かりません。
まとめ
この事例が怖いのは、途中のどの操作にも異常さがなかった点です。
検索して、公式ドメインのページを開いて、書いてあるコマンドを実行する。
多くの人が、毎週やっていることでしょう。
だからこそ、判断を注意力に預けないでください。
スクリプトは保存してから読む。
公式サイトはブックマークから開く。
ドメインだけでなく、パスまで確認する。
どれも地味です。
しかし地味な手順ほど、疲れているときに効きます。
そして、開発者側にも宿題が残りました。
「curlで取ってbashに流す」を推奨手順として提示し続ける限り、ユーザーはその形を安全だと学習していきます。
今回引っかかったのは一人。
でも、そう学習させたのは業界全体です。
