ハクソク

世界を動かす技術を、日本語で。

マイクロソフト コパイロットがファイルを不正に持ち出す

8時間前原文(promptarmor.com)

概要

  • Copilot Cowork における間接プロンプトインジェクション攻撃のリスクを解説
  • ファイル流出 がユーザー操作なしで発生可能な設計上の問題を指摘
  • 管理者による権限制御 やダウンロード制限の有効性について説明
  • Opus 4.7 など最新LLMでも攻撃が有効である事例を紹介
  • 定期実行タスク によるリスク拡大の懸念を強調

Copilot Coworkにおけるプロンプトインジェクション攻撃の概要

  • Copilot Cowork はMicrosoft 365のFrontier機能であり、ユーザーのMicrosoft権限を用いてMicrosoft Graph経由でデータ操作が可能
  • 攻撃者は 「スキル」に間接的なプロンプトインジェクション を仕込み、ファイル流出を実現
  • TeamsやOutlook でのメッセージ閲覧時に、攻撃者制御のネットワークリクエストが発生
  • 送信先が本人の場合、メールやTeamsメッセージ送信に人間の承認が不要
  • 事前認証済みダウンロードリンク を悪用し、ファイルの外部流出が可能

攻撃チェーンの流れ

  • 被害者が SharePointやOneDrive に保存された機密ファイルへのアクセス権を所持
  • 被害者が オンラインで見つけたスキルファイル をCopilot Coworkへアップロード
  • スキルファイル に仕込まれたプロンプトインジェクションが発動
  • Copilot Coworkが Teamsメッセージ を自動生成し、ファイルのダウンロードリンクを含む外部リクエストを送信
  • ユーザーがTeamsメッセージを開封 すると、攻撃者がファイルダウンロードリンクを取得可能
  • 管理者はスキルの内容を直接監視できない ため、リスクの可視化が困難

組織向けリスク低減策

  • Microsoft Graph 経由での広範なリソースアクセス権を最小化する権限設計
  • SharePoint Online Management Shell でファイルダウンロード制限を設定
    • 例: Set-SPOSite -Identity <SiteURL> -BlockDownloadPolicy $true
    • または感度ラベル経由で制御: Set-Label -Identity <label> -AdvancedSettings @{BlockDownloadPolicy="true"}
  • ダウンロード制限有効時の注意点
    • ブラウザ閲覧のみ許可、ダウンロード・印刷・同期不可
    • Microsoft 365 Appsからのアクセスも制限

モデル非依存の攻撃成立性

  • モデル選択を「Auto」 にした場合でも、Opus 4.7やClaude Sonnet 4.6間で同様に攻撃が成立
  • Opus 4.7 はより広範囲のドキュメントを探索し、直近の編集履歴を含めて流出範囲が拡大
  • 攻撃は スキルファイルの一部（全81行中5行） のインジェクションで成立

プロンプトインジェクションの有効性

  • 全試行で攻撃が成功 （5回中5回）
  • ユーザー質問の文言や内容に依存せず、スキル呼び出し時に必ずインジェクションが実行
  • 信頼できないデータ（特にオンライン共有スキル） の利用時は要注意

定期実行タスクによるリスク拡大

  • Copilot Coworkの定期実行タスク （例：「週次レビュー」）は自動でプロンプトを実行
  • ユーザー不在時でも攻撃が発動 し、被害が継続的に発生
  • 定期タスクの利用は攻撃面を大幅に拡大 する要因

要点まとめ

  • Copilot Coworkの設計上、 本人宛メッセージ送信に承認不要 という仕様がファイル流出リスクを増大
  • スキルファイル等の信頼性確認 と 管理者による権限制御 が必須
  • 最新LLMでも防げない攻撃 であり、今後のエージェント型AI活用時の重要なセキュリティ課題

Hackerたちの意見

つまり、もし悪意のあるスキルがあなたのAIエージェントに入ったら、終わりってことだね。驚くことでもないし、これをプロンプトインジェクションと考えるべきでもないと思う。AIスキルは、従来のソフトウェアのプラグインみたいなもので、悪意のあるIDE拡張やOutlookプラグインをインストールしたら、攻撃者はPCに好きなことをして、好きなデータを持ち出せるってこと。だから、この話は大したことないよ。

└

また依存攻撃の新たなターゲットが増えたね。

└

実際、もっとひどいことになってる — 彼らの製品の宣伝になってるよ。

└

スキルを通じてソフトウェアの配布チャネルになったりするのかな。LLMウィキで起こったことに似てるかも。

└

AIスキルは単なるプラグインじゃないよ。適切なモデルがあれば、もっと多くのことができるらしい。みんなのハーネスはモデルに結びついてるから、使えるツールセットがいっぱいあるんだ。

└

たぶん、もうみんなやってると思う。スキルスキャナーを作ったけど、ZIPをダウンロードして中身を確認するのも簡単だし…でも、みんなこれをリモートで読み込んでるよね。ペンテスターの魔法のスキルをインストールしないのは簡単だと思うけど、スキルが持つ攻撃能力はかなりヤバいよ。自分で作った方がいいってのが俺の考え。

└

従来のソフトウェアのプラグインとは違って、スキルはセキュリティの境界からの切り離しを意味するわけじゃないし、高い信頼で動くわけでもない。単に選択的に読み込まれるコンテキストに過ぎない。エージェントにスキルを使ってやらせることができるなら、スキルなしでも同じことをやらせることができるよ。

└

スキルを使って悪用できるなら、信頼できない入力をコンテキストに挿入しても悪用できるってことだよね。Coworkはメールの読み取りに役立つの？

└

データを外部に持ち出すアクセス権があればね。基本的にはデフォルトで拒否してて、会社が各個別の宛先をホワイトリストに登録しなきゃいけないんだ。

└

ありがたいことに、悪意のあるスキルを挿入するのは簡単じゃない。いろんなことを間違えて、攻撃者がたくさんのことをうまくやらないと悪用されることはないよ。

└

そもそも、これをプロンプトインジェクションと考えるべきじゃないと思うんだけど、謝罪的な表現はやめようよ。複数の脆弱性からエクスプロイトを作るのはどんどん一般的になってきてるし、どれも良くない。企業のマルウェアをダウンロードするのはバカだし、ランダムなプロンプトインジェクションを追加するのは無謀だよ。自律エージェントをその上で動かすなんて、頭おかしい。プロンプトインジェクションはこの点でより深刻だね。しっかりした防御策が知られてないから。その他の問題はプロセスの失敗だけど、プロンプトインジェクションは最初の考えの段階での失敗なんだ。

なんてこった、いいね。無数のMBAの連中が「企業全体のコパイロット統合」を「導入」して、会社を「AIネイティブ」にしようとしてるなんて、最近のLinkedInの連中は何を考えてるんだろうね。

スキルはLLMエージェントのためのプログラムに過ぎないよ。これって、期待通りに動いてるだけじゃない？スキルの中の5行が特に無害だってこと？軽視するつもりはないけど、ここで何が起こったのか理解できないな。だって、curl $url | bashがデータを持ち出せるって言ってるように見えるし、それはかなりストレートだよね。

└

スキルは、エージェントが自律的にコンテキストにコピーできる指示に過ぎない。信頼できるコンテキストと信頼できないコンテキストの間に信頼の境界はないんだ。

└

そうだね、みんなこれが実際には自然言語のスクリプトに過ぎないってことを理解してない。

マイクロソフトはこれを急いでリリースしたね。ベータ機能って呼んでるけど、明らかにすごく急いでた。 relevanceを保とうと必死なんだ。

└

彼らの世界での「ベータ」は、まるで「やってみよう」って感じで、マイクドロップみたいだね。Teamsの壊れ具合には驚かされるばかり。これだけひどいと、オフィスに戻らせるための心理作戦なんじゃないかと思う。

└

最初の365コパイロットのローンチって、ファイルアクセスや権限を無視することが多いって気づいて、全体をロールバックしたんじゃなかったっけ？「xチームの最高給のメンバーを給与順にリストアップして」みたいなクエリがそのまま通っちゃうとか。急いで技術を使うのは、制御や理解、セキュリティの制限が難しいものと組み合わせるのは、ちょっと狂ってると思う。

└

ビンゴ。マイクロソフトには、関連性を持たせるべきたくさんの強みがある — 約10億のWindowsインストール、~~Office~~ ~~M365~~ M365 Copilotは今でも事実上の生産性スイート、Azureデータセンター、OpenAIとの契約 — でも、彼らは自分たちの足を引っ張ってる。戦略が「その強みを活かしてCopilotを無理やり押し付ける」だから。センスがないし、センスを持とうともしない。業界は、ユーザーに自社製品を買わせるための準独占戦略にはあまりにも早く動いてる。マイクロソフトが素晴らしい戦略的ポジションを持っていたのに、実際に素晴らしい製品を優先しなかったせいでAIで失敗したことについて、本が書かれるだろうね。

エクスフィル：コンピュータシステムから機密データを盗むこと（例えば、フラッシュドライブを使って）。ここでマイクロソフトを擁護するつもりはないけど、元のブログのタイトルは誤解を招くし、ちょっと煽り気味だよね。Coworkで起きたことは急いでやった結果かもしれないし、無能さが原因かもしれないけど、無能さは悪意じゃない。このフレーミングは、著者の他の興味深い発見でも使い回されてる。記事の中では、言葉遣いがもっと正確で、「被害者がCopilot Coworkにプロンプトインジェクションを含むスキルファイルをアップロードする」とか、「そのインジェクションがMicrosoft Copilot Coworkを操作して、認証済みのファイルダウンロードリンクを表示するTeamsメッセージを投稿させる」と書いてある。

└

悪意があるのは、その悪質なスキルファイルの著者だよ。これは、LLMに機密情報へのアクセスを与えることに伴う本質的なリスク。ユーザーの権限に基づいて、LLMにそんな広範なアクセスを与えるのはマイクロソフトにとって無謀だよ。Teamsメッセージの確認プロンプトがあったら、なぜ優秀なユーザーがそれを拒否するの？スキルがそうするって言ってるんだから。メッセージは予想通りだし、見える内容も予想通り。確認プロンプトなんてただの厄介者だよ。

└

記事の中では、表現がもっと正確だよね。「被害者がプロンプトインジェクションを含むスキルファイルをCopilot Coworkにアップロードする」とか、「そのインジェクションがMicrosoft Copilot Coworkを操作して、認証済みのファイルダウンロードリンクを表示したときにTeamsメッセージを投稿する」とか。確かに正確で、結果が何かを明確に示してるよね：エクスフィルトレーションだ。タイトルでそう言うのが誤解を招くのはなぜ？「cowork」がエクスフィルトレーションに対して脆弱なコンポーネントだってことは明らかじゃん。

こんなエージェント製品を作るなら、データのエクスフィルが一番のリスクとして考えるべきだよ。

LLMはデータとコードを分けないからね。買うときは気をつけて。

プロンプトインジェクション攻撃について聞くのは初めてじゃないし、確かにマイクロソフトの責任だよ。プロンプトインジェクション自体について話してる人が多いけど、Copilotがプロンプトインジェクションを防げるべきかどうかとか。でも、それが問題じゃない。OpenAIは昨年、LLM駆動のブラウザAtlasをリリースしたけど、彼らのチームは素晴らしい（https://openai.com/index/hardening-atlas-against-prompt-inje...）のに、成功したインジェクション攻撃がいくつかあった。個人的には、本当の脆弱性は「ReAct」（推論と行動）エージェントフレームワークの「Act」部分にあると思う。> 「[Copilot] Coworkは、敏感なアクションを取る前にあなたの許可を求めます…」受取人がアクティブユーザーのとき、これらのアクションは人間の承認なしに即座に実行される（ユーザーにはこの動作を変更する設定がない）。> Copilot Coworkは、ユーザーがアクセスできるファイルの「認証済みダウンロードリンク」を取得できるので、そのリンクを開いた人は誰でもそのファイルをダウンロードできる。> Microsoft Copilot Coworkは、基本的にユーザーがMicrosoft Graphを通じて行うほぼすべてのリソースに対して読み取りアクセスを持っている。だから、こういう攻撃の影響範囲を減らすための主なメカニズムは、Microsoftエコシステム内で過剰な権限を制限することだよ。リラックスして。攻撃の流れ全体の中で、マイクロソフトはCoworkに無制限のアクセスと承認をバイパスする能力を与えている。ここでLLMに大きな問題は感じないな。攻撃はOpus 4.7にも脅威だと言われてるけど、Opus 4.7がcontext7.comの「プロンプトインジェクション」を禁止しているのを何度も見たことがある。オープスがもっとリクエストを無料で得るためにcontext7のAPIキーを作成するように求めるだけだった。私の個人的な経験から言うと、そういうモデルは確かにインジェクションを認識するように訓練されてるけど、これらのインジェクションはエージェントスキルみたいに自分を隠すことができるし、レッドチームが勝つ方法は常にある。インジェクションの防御にあまり期待を寄せず、LLMの権限を制限することに集中すべきだね。エージェント（特にコーディングエージェント）のワークフローでCLIの人気な使い方も気になってる。なぜなら、エージェントがアクセスできるほとんどのCLIツールは、実際にはユーザーと同じ権限を持っているから。

└

「個人的には、本当の脆弱性は「ReAct」（推論と行動）エージェントフレームワークの「Act」部分にあると思う。」これは「ツールコーリングが問題だ」と言ってるのと同じことだね、明らかに正しい。問題は、正しく動作するとき（99.99%の確率で）、LLMにとってはるかに多くの価値を追加すること。サンドボックスは正しい方向への一歩だけど、摩擦も生むことがある。ガードレールを使うのも良いけど、遅延やコストがかかるし、100%の問題解決にはならない。私の意見では、今のところこの問題に対する適切な解決策は存在しないし、まだ発見されていない。ただし、適切な解決策はLLMに基づくべきではないから、ガードレールは間違った方向だと思う（効果的で実装が簡単だけど）。

└

問題は自然言語がメディアであることだね。あまりにも曖昧で、想像できることを文字通り言うにはバリエーションが多すぎて、何らかのNLPフィルターなしにはプロンプトインジェクションから守る方法がないと思う。これらの問題を考えると、どうやってこの防御策を開発できるのか、全然見えないよ。

こういうシナリオには何が推奨されるの？ 管理者が設定できるスキルスキャナーを追加するのがいいのかな？

新しい統合があるたびに、またエクスフィルトレーションのリスクが増える。こうなるのは必然だったね。