
3行で読む結論
偽Claude Codeインストーラは、AIコーディングツールを探す開発者に偽ページを見せ、PowerShell経由でブラウザ情報を盗む攻撃として報告されました。
問題はClaude Codeだけではなく、AIツール導入時に「検索して出たコマンドを貼る」文化そのものが攻撃面になったことです。
社内では、正規配布元、許可済みCLI、禁止コマンド例、PowerShell実行ポリシー、拡張機能棚卸しを、導入研修と同じ粒度で管理すべきです。
ニュース概要: 偽ページが正規インストーラの顔をしていた
CSO Onlineは2026年5月12日、偽Claude Codeインストーラが開発者を狙い、ChromeのIElevator interfaceを悪用して保護されたブラウザ情報を盗む攻撃を報じました。報告元のOntinueによれば、攻撃者はClaude Codeなど人気の開発者向けツールを模した偽インストールページを用意し、正規のワンラインインストーラを攻撃者管理のPowerShellコマンドへ差し替えていました。
Ontinueの技術分析では、被害者が検索結果からスポンサー表示の偽ページへ入り、表示されたコマンドをPowerShellへ貼り付ける流れが確認されています。貼り付けられたコマンドは、短いPowerShell段階を経て約4.6KBのネイティブヘルパーをChromium系ブラウザへ注入し、IElevator2 COM interfaceを通じてApplication-Bound Encryptionの鍵を回収する構成でした。
盗まれる対象も重いです。Ontinueは、Chrome、Edge、Brave、Vivaldi、Opera、Opera GXなどのChromium系ブラウザを列挙し、Cookie、保存パスワード、支払い方法などを復号・収集して外部送信する流れを記録しています。CSO Onlineも、PowerShell loader側にSQLiteアクセス、アーカイブ作成、HTTPS送信、永続化、プロセス注入を寄せることで検知を難しくしている点を紹介しています。

ここで押さえるべきなのは、「偽インストーラをダウンロードした」ではなく、「開発者が普段どおり、便利な導入コマンドを貼った」だけで入口が成立していることです。今日の行動は、Claude Code、Codex、Cursorなどの導入コマンドを社内ナレッジで固定することです。
なぜ重要: 開発端末はソースコードの玄関であり、クラウドの鍵箱でもある
開発端末は、一般的な業務PCよりも攻撃者にとって価値が高い場所です。ローカルにはソースコード、Git認証情報、クラウドCLIのセッション、パッケージ公開権限、CI/CDの設定、社内ドキュメントへのブラウザセッションが集まりやすいからです。
CSO Onlineは、開発者が組織の知的財産、クラウド基盤、CI/CDパイプラインに近いこと、さらに業務上ソフトウェアを導入する自由度が必要なことを、標的価値の理由として整理しています。つまり「開発者はインストールする人」だからこそ狙われます。

AIコーディングツールの普及で、この構造はさらに強くなりました。新人や非エンジニアがClaude Code、Codex、Cursorを試すとき、検索結果、ブログ記事、SNSのコマンドをそのまま貼り付ける場面が増えます。AI導入で最初に教えるべきなのは「便利な使い方」だけではなく、「どの導入経路を正として扱うか」です。
ブラウザ情報は、なぜここまで危ないのか
Googleは2024年7月、Chrome 127でWindows向けのApplication-Bound Encryptionを導入しました。Googleの説明では、従来のDPAPIは他ユーザーやコールドブート攻撃からの保護には役立つ一方、ログイン中ユーザーとして実行される悪意あるアプリには十分ではありませんでした。そこでChromeは、Cookieから順に、データをアプリの同一性に結びつけて暗号化する方向へ移しました。
ただし、Google自身も、攻撃者がシステム権限を得るかChromeへコード注入すれば回避余地があることを説明しています。今回のOntinue報告が重要なのは、まさにその「ブラウザの保護機構を上回ろうとする実装」が、偽AIツール導入という入口と結びついた点です。
ブラウザのCookieやセッション情報が盗まれると、パスワードを知らなくてもログイン後の状態を悪用される可能性があります。クラウド管理画面、GitHub、GitLab、Slack、Notion、社内SaaSにログイン済みの開発端末では、ブラウザは単なる閲覧ツールではありません。小さな鍵箱です。

今日の行動は、開発端末のブラウザで保存パスワード、支払い情報、自動入力、拡張機能、ログイン済みSaaSを棚卸しし、「盗まれたときにどの権限へ届くか」を1枚で見える化することです。
正規配布元を、社内ナレッジとして固定する
偽インストーラ対策は、従業員に「気をつけて」と言うだけでは足りません。正規の入口を社内で固定し、検索結果やSNS投稿からの導入を例外扱いにする必要があります。
| ツール | 正規確認先 | 社内で決めること |
|---|---|---|
| Claude Code | https://code.claude.com/docs と https://claude.ai | Windows、macOS、npm、Homebrewのどれを許可するか |
| Codex CLI | https://developers.openai.com/codex/cli | npm経由、Homebrew経由、ChatGPTログインの扱い |
| Cursor | https://cursor.com と https://docs.cursor.com | デスクトップアプリ、Cursor CLI、cursor-agentの許可範囲 |
Anthropicのヘルプは、Claude CodeのWindows PowerShell導入として claude.ai ドメインのinstall.ps1を案内し、npmでは @anthropic-ai/claude-code を示しています。OpenAIのCodex CLIドキュメントは、npm i -g @openai/codex でのインストールと、初回起動時のChatGPTアカウントまたはAPIキー認証を説明しています。Cursorの公式ドキュメントは、アプリのダウンロードはcursor.com、Cursor CLIはcursor.com/installを使う流れを示しています。

禁止コマンド例も、抽象ではなく社内ナレッジに書いておきます。たとえば、検索広告からコピーしたPowerShellワンライナー、Set-ExecutionPolicy Bypassを含む導入手順、正規ドメイン以外へのirmやcurl、内容未確認のスクリプトを直接実行するパイプ付きコマンドは、原則としてチームレビュー対象にします。今日の行動は、許可URLと禁止例を同じページに並べることです。
PowerShell実行ポリシーは確認する。ただし、それだけに頼らない
PowerShell実行ポリシーは見直す価値がありますが、それ自体を完全な防御壁として扱うのは危険です。Microsoftの公式説明では、実行ポリシーは悪意あるスクリプトの実行を防ぐための安全機能である一方、ユーザーの行動を制限するセキュリティシステムではなく、ユーザーが簡単に回避できることも明記されています。
Microsoftの同じ文書では、RemoteSignedはインターネットから取得したスクリプトに信頼済み発行元の署名を求める一方、Invoke-RestMethodやInvoke-WebRequestのような取得方法では、ファイルにインターネット由来の印が付かない場合があるとも説明されています。今回のような「irmで取得してiexで実行する」型の攻撃では、ここが重要な確認点になります。
Microsoft Defender for EndpointのAttack Surface Reduction rulesには、「potentially obfuscated scripts」の実行ブロックがあり、Intune、Configuration Manager、Group Policy、PowerShellで構成できる項目として整理されています。CSO Onlineも、追加対策としてPowerShell Constrained Language Mode、フィッシング耐性のあるMFA、AMSI tamper protectionの検証、新規登録ドメインのブロックを挙げています。

今日の行動は、Get-ExecutionPolicy -Listで現状を確認し、チームのWindows端末でMachinePolicy、UserPolicy、CurrentUserのどこに実効設定があるかを記録することです。あわせて、EDR/MDM側で難読化スクリプト、未知ドメインへのPowerShell通信、ブラウザプロセスへの注入がどう検知されるかを検証します。
コピペするプロンプト本体
社内ナレッジを作る前に、AIにレビューさせるためのプロンプトです。公式URL、許可コマンド、禁止例、確認手順を1枚にそろえる用途で使ってください。
textあなたは開発組織のエンドポイントセキュリティとAIツール導入を同時に見られるレビュアーです。これから、社内でClaude Code、Codex、Cursorなどを導入するためのナレッジ記事を点検します。対象ツールは {対象ツール一覧}、対象OSは {社内OS}、端末管理は {MDM/EDRの名称}、利用者は {利用者の職種とスキル感} です。記事内の正規URLが公式ドメインに固定されているか、検索広告やSNS投稿からコピーしたコマンドを実行しない注意があるか、PowerShellの実行ポリシー確認手順があるか、Set-ExecutionPolicy Bypassや未知ドメインへのirm/curlなどの禁止例が明示されているかを確認してください。出力は、最初に重大リスクを最大5件、その次に修正すべき本文案、最後に公開前チェックリストを表で返してください。判断に迷う箇所は「確認待ち」として残し、公式URLを推測で補完しないでください。
今日の行動は、上のプロンプトに自社の対象ツール、OS、MDM/EDR名を入れて、既存のオンボーディング資料をレビューすることです。資料がまだない場合は、まず許可URL、禁止例、問い合わせ先だけの1ページから始めます。
AITOWA視点: AI導入支援は「使い方研修」から「入口設計」へ広がる
AITOWAでは、AI導入支援を「どのツールが便利か」の紹介だけで終わらせません。既存サイトのAI導入支援でも、業務フローの深部へAIを組み込むAX、Pythonを使った自動化、Claude CodeやChatGPT/Codexを個人環境やチーム環境へ統合する支援を扱っています。だからこそ、導入初日に見るべき範囲は、プロンプトの書き方だけではありません。
今回の攻撃から逆算すると、AIツール導入支援のチェックリストは次の5つへ広がります。
- 正規配布元の固定
- 許可済みCLIとバージョン更新手順
- 禁止コマンド例と例外申請ルート
- PowerShell、ブラウザ、拡張機能、EDRログの確認
- セッションCookieやAPIキーが漏れた場合の失効手順
特に非エンジニアや新人にAIコーディングツールを配る場合、「検索して上位の手順を見る」は禁止ではなく、別の安全な行動に置き換える必要があります。社内ポータルに「Claude Codeを入れるならこのページ」「Codexはこのページ」「Cursorはこのページ」と置く。そこにスクリーンショット付きの手順、更新日、担当者、緊急時の連絡先を載せる。これだけで、偽ページへ迷い込む確率は大きく下がります。
今日の行動は、AIツール導入研修の最後に「正規配布元をブックマークする5分」を入れることです。地味ですが、こういう地味な導線こそ、開発端末を守ります。
まずできそうなこと
今週中に開発チームでやるなら、次の順番が現実的です。
- Claude Code、Codex、Cursorの正規URLを社内ナレッジに固定する
- Windows端末でGet-ExecutionPolicy -Listを確認し、グループポリシーの有無を記録する
- PowerShellで未知ドメインから取得して即実行するコマンドを禁止例として明文化する
- ブラウザの保存パスワード、自動入力、拡張機能、ログイン済みSaaSを棚卸しする
- GitHub、クラウド、CI/CD、npmなどのトークン失効手順を1枚にまとめる
- 新しいAIツールを試すときは、チームのSlackやNotionで公式URLを確認してから導入する
完璧なゼロトラスト基盤を待つ必要はありません。まず「どのURLから入れてよいか」と「どのコマンドは貼ってはいけないか」を決めるだけでも、攻撃者が作った偽の近道を踏みにくくなります。
関連記事
出典・参考
- CSO Online: Fake Claude Code takes the IElevator to your browser secrets
- Ontinue: Behind a Fake Claude Code Installer
- Claude Code Docs: Setup
- OpenAI Developers: Codex CLI
- Cursor Docs
- Google Online Security Blog: Improving the security of Chrome cookies on Windows
- Microsoft Learn: about_Execution_Policies
- Microsoft Learn: Attack surface reduction rules reference
CTA
AIコーディングツールを社内に広げたい方は、ツール選定だけでなく、導入URL、端末防御、ブラウザ拡張、権限、ログ、緊急時の失効手順まで一緒に設計しましょう。AITOWAでは、Claude Code、Codex、Cursorなどの導入支援を、現場の業務フローとセキュリティ運用の両面から整理します。
- 相談: AI導入支援ページ
- note: AITOWA公式note
AI生成開示
本記事はAIエージェントが下書きを生成し、aitowa編集部の方針・知見に基づき構成しています。公開前に一次情報、表記、内部リンク、画像、導線、内容の妥当性を確認しています
