Blue41 × Bunq: 「0.02 ユーロの振込」が引き起こした AI 用フィッシング攻撃の実態

欧州の大手デジタル銀行である Bunq（顧客数 2,000 万人以上）に対し、Blue41 は AI アシスタントへの標的型フィッシング（スーパークライミング）リスクに対する支援を行いました。本記事では、同ケーススタディに基づき、金融機関における間接的なプロンプトインジェクションの脆弱性と対策について解説します。

問題背景：AI アシスタントへの共通するアーキテクチャ上の課題

Blue41 は、単一の銀行振込取引がトリガーとなり、AI アシスタントを信頼性の高いフィッシング攻撃の伝播経路へと転化させる脆弱性を Bunq で確認しました。この問題は特定のベンダーに限定されず、金融機関全体が直面する共通のアーキテクチャ上の課題です。

特に以下の要素を処理する AI アシスタントを導入する組織にとって、広範なセキュリティ挑戦となっています。

• 取引データ
• 顧客レコード
• ドキュメント
• メッセージ
• その他の信頼できない入力データ

攻撃の仕組み：0.02 ユーロから始まるフィッシングシナリオ

現代の Banking アプリでは、大規模言語モデル（LLM）が文脈に基づいて自然言語回答を生成します。しかし、取得されたすべての文脈が等しく信頼できるわけではありません。取引の説明欄のような外部データは「指示」として解釈されるリスクがあり、これが間接的なプロンプトインジェクションの核心的な問題です。

攻撃プロセス

本概念実証（PoC）では、被害者デバイスのアクセスやマルウェア導入は一切不要でした。攻撃者は以下の手順のみで攻撃を遂行します。

• ステップ 1：悪意のあるデータ投入
  • 攻撃者はターゲットに対し、金額が極小な振込（例：0.02 ユーロ）を行います。
  • 振込の**「取引説明欄」**に、プロンプトインジェクションペイロードを埋め込みます。
• ステップ 2：自動的な攻撃実行
  • 被害者がアプリ内で「最近の取引を見せてください」と質問します。
  • AI アシスタントは回答生成のために、悪意のある取引データを含めて LLM に渡します。
  • LLM は注入された指示を処理し、正規の銀行業務として見せかけないまま標的型フィッシング攻撃を開始させます。

攻撃メカニズムの核心

1. 攻撃者が取引説明欄を通じて悪意のある指示を注入する。
2. ユーザーが日常的な質問を入力する。
3. LLM が取引データ（＝悪意ある指示を含む）を取得し、コンテキストとして使用する。
4. AI アシスタントの回答に注入されたコンテンツの影響が出る。

重要点: 生成されたメッセージは銀行アプリ内に表示され、銀行自らの AI アシスタントからのものとして見えます。そのため、実際の取引詳細やユーザー固有の情報に基づく極めて説得力の高いフィッシング攻撃となります。

なぜこの脅威が金融機関にとって致命的なのか？

このタイプの攻撃は、 banking 分野において特有の特性により特に深刻です。

• インジェクション表面が普遍的
  • 取引説明欄、支払い参照番号、商売元メタデータ、サポートメッセージ、アップロードドキュメント、メール、CRM 注釈など、多くのデータフィールドが AI の文脈に組み込まれますが、これらはもともと「指示境界」として設計されていません。
• 低コストかつ高説得力な配信
  • 極めて少額の送金で攻撃者のテキストを被害者の履歴に挿入できます。そのペイロードは、ユーザーが信用するチャネル（銀行アプリ）を通じて直接表示されます。
• 特権的なコンテキストの存在
  • フィッシングメールと異なり、AI アシスタントは実在の口座情報へのアクセス権限を持ちます。これにより生成されたメッセージは個人的でタイムリーなため、信頼されやすくなります。
• 能力向上に伴うリスク増大
  • 読み取り専用でも誤導可能です。ツールや運用へのアクセスを持つアシスタントになると攻撃表面（Attack Surface）がさらに広がります。AI の有用性が高まるほど、セキュリティモデルの重要性も高まります。

ガードレールだけでは解決できない理由

入力フィルタリングやプロンプトインジェクション検出器といった静的な対策だけでは不十分です。Bunq の事例では、以下の理由から対策が機能しませんでした。

• 悪意のある検知の困難さ: 取引説明欄内のデータは「通常の取引情報」であり、単独で見れば悪意あるものと区別できません。「以前の指示を無視せよ」といった明らかな攻撃パターンが含まれていなくても、文脈内での解釈がリスクとなります。
• 静的分類の限界:
  • 単純なインジェクションは検出可能ですが、巧妙に設計されたペイロードは通常のデータと混同されます。
  • リスクはテキスト自体だけでなく、信頼できないデータの取得ロジックやモデルの振る舞いから発生します。

階層化されたセキュリティモデルが必要

ガードレールを単独で依存せず、以下の多層的なアプローチが必要です。

1. 入力フィルタリング: 明らかな攻撃を弾く。
2. 出力制約: 有害な回答やデータ漏洩を防ぐ。
3. 最小権限の原則: 影響範囲を制限する。
4. ランタイムモニタリング: アシスタントが意図したプロファイルから逸脱した行動を検出する。

効果的な緩和策：4 つの階層

間接的なプロンプトインジェクションへの対策として、以下の 4 つの階層的なコントロールを検討すべきです。

1. 不要なコンテキストを最小化する
   • ユーザータスクに必要なもの以外（例：取引説明欄など）は、デフォルトでモデルのコンテキストに含めない。
2. 取得データを「データ」として扱う
   • 取引説明欄や顧客メッセージなどは決して「指示」ではない。アーキテクチャ上で明確な区別を保持する。
3. 機密出力とアクションを制約する
   • リンクの生成、認証情報の要求、機密ワークフローの開始、高インパクトツールの呼び出しなどを無条件で許可しない。
4. ランタイム挙動を監視する
   • 新しい攻撃手法に対応するため、アクセス元、回答パターン、使用ツールなどが意図された範囲内かを常に監視する。

結論：行動ベースのモニタリングが不可欠な理由

可能なすべてのインジェクションペイロードを防ぐのは現実的ではありません。しかし、AI アシスタントが侵害された際の「振る舞いの変化」は観察可能です。

• 外部 URL の埋め込み
• 情報の抑制
• 予期せぬデータソースへのアクセス
• 通常と異なるツールの使用

Blue41 は、AI エージェントのランタイム挙動を監視し、「行動プロファイル」を作成することでセキュリティを強化します。これにより、セキュリティチームは AI アシスタントがビジネスワークフローの一部となる際に必要な可視性を確保できます。

より大きな文脈

金融サービスにおける AI アシスタントは実験段階を超え、機密データを扱い意思決定に影響を与えています。従来のアプリセキュリティでは「コードとデータの境界」がありましたが、AI はこれを曖昧にします。テキストフィールドもまた強力な指示チャネルへと変貌していることを認識し、新しい信頼境界とモニタリング要件を持つシステムとして扱う必要があります。

広範な教訓：

プロンプトインジェクションはモデルだけの問題ではありません。アプリケーションセキュリティの問題であり、データフローの問題であり、ランタイムモニタリングの問題です。

貴社の AI イノベーションを進める際は、Blue41 へご相談ください。不信任データがエージェントコンテキストに進入する地点を特定し、必要なコントロールを導入するためのサポートが可能です。