AIに「こんなことができるソフトはある?」と尋ね、勧められたものを入れる。開発の現場では当たり前になった流れが、攻撃の入り口にもなりえます。セキュリティ会社のIslandは、遠隔操作の不正プログラムを仕込んだGitHubのソフトが、ChatGPTの推薦やGoogle検索の「AIによる概要」に出てきたと報告しました。攻撃者は、ソフトを本物らしく見せる工夫を重ねていました。Islandの報告から整理します。
何が見つかったか
Islandは2026年10月13日、遠隔操作の不正プログラム「MicrosoftSystem64」を送り込む攻撃を調べた報告を公開しました。この名前は、不正プログラムがWindows・macOS・Linuxで居座るときに使う名前から付いたもので、Microsoft社とは関係ありません。不正プログラムは、コマンドの実行、ファイルへのアクセス、居座り、追加の仕込みができるとしています。
攻撃は、npmの依存パッケージを通じて不正なプログラムを入れる仕組みでした。Islandは、9月20日時点で、この攻撃に関係するGitHubの公開のリポジトリを少なくとも88件見つけています。テーマは、投資・売買、AI、金融、暗号資産などが多く、AIのエージェントがつなぐMCPサーバーを名乗るものもありました。
Islandの報告の図。関係するリポジトリのテーマの内訳(重複あり)出典: Island「How Attackers Built Software an AI Would Recommend」(引用)
Islandは、そのうちの1件で、Shopifyの店の管理をAIとつなぐ非公式のMCPサーバーを名乗るソフトを試しました。ログインしない新しいセッションのChatGPTに、そのソフトの名前や攻撃のことを伝えずに、ふつうに「ShopifyをAIから管理できるソフト」を尋ねたところ、推薦の上位に出てきたといいます。Googleでも、検索の個人向けの調整を切ったシークレットモードで、同じソフトが「AIによる概要」に出てきました。
本物らしく見せた4つの手口
Islandは、AIが勧めてもおかしくない見た目は、次の積み重ねでできていたとしています。
- 本物のソフトを写して、機能を残す: 既存のオープンソースのソフトを写し、ふつうに動く機能を残した。そのうえで、不正なパッケージにつながる部品に、それらしい役目を与えた。たとえばShopifyのソフトでは、Redisで店のアクセスの鍵を保存する処理を足し、その処理に、名前の似たパッケージ(ioredis-xyz)を使わせていた
- 開発の履歴を偽る: 2022年からあるように見えるアカウントで、25件の公開のリポジトリが、実は2026年6月24〜26日にまとめて作られていた。他人のプロジェクトの履歴を取り込んで作者の名前を書き換えたり、57段の履歴を自動で作るスクリプトを使ったりしていた
- 人気を偽る: 88件の合計で、スターは9,881、フォーク(複製)は65,681。7件のAI・MCPのリポジトリでは、続けて作られたフォークの673回の間隔のうち664回が179〜182秒で、ほぼ3分おきに自動で作られていた。あるリポジトリのフォークは、ほとんどが22の組織のアカウントに、ほぼ同じ数ずつ持たれていた
- 中身だけ入れ替える: リポジトリや説明書はそのままに、つながるパッケージの名前を、ioredis-xyzからoscar-redis、oracle-redisへと入れ替えていた。パッケージの名前で探す方法は、すぐに古くなる
フォークが約3分(180〜182秒)おきに作られていた記録出典: Island「How Attackers Built Software an AI Would Recommend」(引用)
Islandは、こうした手口の一つひとつは新しくないものの、AIを使ったソフト探しと結び付くと危うさが増すとしています。「探して」から「入れる」までが、数回の問いかけで済むようになったためです。ただし、どの手がかりがAIの推薦につながったか、攻撃者がAIに勧められることを狙っていたかは、分かっていないとしています。
同じIslandは、以前に、AIのスキルやMCPサーバーを装った偽のリポジトリの攻撃も報告しています(GitHubの偽AIスキル・MCPサーバー800件超 FakeGitと社内の入手ルール)。今回は、説明書に指示を書き込むのではなく、本物の機能を持つソフトの依存の先に不正な部品を置いた、別の経路です。
影響する会社・しない会社
- 影響する: 社員がAIのアシスタントやAIの開発の道具に勧められたソフト、とくにGitHubのソフトやnpmのパッケージ、MCPサーバーを、業務のパソコンに入れている会社です。
- 影響する: AIのエージェントに、ソフトの検索や導入まで任せている開発の部署がある会社です。人が依存の中身を見る前に入ってしまうおそれがあります。
- 影響しない(今のところ): 業務のパソコンに入れてよいソフトを決め、申請と確認を通してしか入れられない会社です。ただし、開発者のパソコンだけ例外にしていないかは確かめます。
情シスが今日やること
- 痕跡を探す。開発者のパソコンとCIで、依存の一覧(package-lock.jsonなど)に、ioredis-xyz、redis-type-xyz、ulid-xyz、oscar-redis、redis-type-intel、oracle-redis、ioredis-os、os-ulid-voidが無いかを確かめます。端末では、「MicrosoftSystem64」という名前の予定のタスクやMicrosoftSystem64.vbs、macOSのcom.launchkeeper.MicrosoftSystem64.plist、Linuxの利用者のsystemdのMicrosoftSystem64.service、一時フォルダーの.pkg-agent.lockを探します。見つかったら、その端末の鍵や認証情報を替えます。
- AIに勧められたソフトも、申請の対象にする。「AIが勧めたから」は、入れてよい理由になりません。とくにMCPサーバーは、会社のサービスの鍵を扱うため、許可した一覧から選ぶ決まりにします。
- リポジトリの見分け方を共有する。アカウントの公開のリポジトリが短い期間にまとめて作られていないか、フォークの数がスターよりずっと多くないか、元になったプロジェクトがあるならそちらと依存の一覧が違わないか、名前の似たパッケージが入っていないかを、開発の部署と確かめる点として共有します。
- 入れ方の決まりを作る。試すときは、本番のパソコンとは分けた環境で、インストールのときに動くスクリプトを止めて中身を見ます。使うことに決めたら、版を固定し、社内の登録所(プライベートのレジストリ)や許可の一覧を通して入れます。AIのエージェントに導入まで任せる場合は、入れてよい範囲をあらかじめ絞ります。
npmのパッケージを使った別の手口は、偽のWeb3支援を装うnpmパッケージ AIの鍵と開発PCを狙う手口でも整理しています。
