【生成AIセキュリティ】GraphRAGの脆弱性と攻撃手法「GRAGPOISON」解説


## はじめに

最近、Stony Brook UniversityとDuke Universityの研究チームが発表した論文 [GraphRAG under Fire](https://arxiv.org/abs/2501.14050) によると、GraphRAGは従来のRAGと比べてより堅牢である一方、新たな攻撃ベクトルが存在することが明らかになりました。この研究では、GraphRAGの知識グラフ構造を悪用する「GRAGPOISON」という新たな攻撃手法が提案され、その脅威と影響が詳細に分析されています。

近年、LLM（大規模言語モデル）はRAG（Retrieval-Augmented Generation）技術を用いて外部知識を統合することで、知識不足や幻覚問題を軽減しています。その中でも **GraphRAG** は、従来のベクトル検索ではなく、**マルチスケール知識グラフ** を活用してLLMの推論能力を向上させる技術です。

しかし、GraphRAGは従来のRAGよりも頑強である一方、新たな攻撃ベクトルを生み出していることが判明しました。本記事では、GraphRAGの基本概念、攻撃手法「GRAGPOISON」の仕組み、および防御手法について解説します。

## GraphRAGとは？

GraphRAGは、RAGを拡張し、知識ベースを **知識グラフ（Knowledge Graph）** に変換する技術です。GraphRAGの基本的な仕組みは以下の通りです。

1. **インデックス作成**：

   - テキストコーパスを小さなチャンクに分割し、**エンティティ**（例：Stuxnet）と**関係**（例：「StuxnetはDLL Injectionを使用」）を抽出。
   - これらの関係を知識グラフとして構築し、関連する情報を階層的にまとめる。

2. **推論（Retrieval & Generation）**：

   - ユーザーのクエリを知識グラフ上のエンティティ・関係とマッチングし、関連情報を取得。
   - LLMが取得したコンテキストを元に回答を生成。

従来のRAGと比べ、GraphRAGは情報の一貫性を保ちやすく、推論能力が強化されるというメリットがあります。

## GraphRAGの脆弱性

GraphRAGは、単純なデータ汚染攻撃（Poisoning Attack）に対しては比較的頑強です。知識グラフの構造が、悪意あるデータの影響を軽減する役割を果たすためです。

しかし、GraphRAGには新たな攻撃ベクトルが存在します。特に、**関係共有の特徴** を悪用することで、1つの攻撃で複数のクエリを同時に汚染できることが明らかになりました。

## 攻撃手法「GRAGPOISON」

GRAGPOISONは、GraphRAGの知識グラフ構造を悪用した新しい攻撃手法です。この攻撃では、特定の関係をターゲットにし、**複数のクエリに影響を与える毒データ（Poisoning Text）** を注入します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3872898/5b037660-92c0-4626-b9fc-ed6aac8c0565.png)

### **攻撃のステップ**

1. **関係の選択（Relation Selection）**

   - まず、複数のクエリで共有される関係を特定（例：「StuxnetはDLL Injectionを使用」）。

2. **関係の注入（Relation Injection）**

   - 既存の関係を改変する偽情報を挿入（例：「StuxnetはProcess Hollowingを使用」）。
   - 時系列の変更、明示的な否定、文脈的な説明を加え、整合性を持たせる。

3. **関係の強化（Relation Enhancement）**

   - 偽の関係をより信頼性があるように見せるため、新しい関連情報を追加（例：「Process HollowingはProcess Creationで検出可能」）。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3872898/15fdfcbf-7601-4e50-9921-bffc81c8d093.png)

### **攻撃の例**

例えば、攻撃者がGraphRAGを利用するセキュリティ対策AIを騙し、誤ったインシデント対応を促すケースを考えます。

#### **Scenario: Stuxnetの検出手法を改ざん**
1. **関係の選択（Relation Selection）**  
   - 企業のSOC（セキュリティオペレーションセンター）が「Stuxnetの検出方法」をAIに問い合わせるとします。
   - 本来のGraphRAGは「StuxnetはDLL Injectionを利用する」と返答するべきです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3872898/fe18f4b1-367c-473d-afa2-0ec60d6626ab.png)

2. **関係の注入（Relation Injection）**  
   - 攻撃者は「StuxnetはProcess Hollowingを利用する」という誤った情報を知識グラフに注入。
   - さらに、「Process Hollowingを使うマルウェアは一般的にProcess Creationを伴う」という誤情報を追加し、より説得力を持たせます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3872898/e4b4de4b-aec3-4316-bd6f-6d4334beb595.png)

3. **関係の強化（Relation Enhancement）**  
   - GraphRAGの応答は次第に「StuxnetはProcess Hollowingを使用し、Process Creationによって検出可能」となります。
   - しかし、実際にはStuxnetはProcess Hollowingを使用しないため、SOCは誤った検出手法を適用し、脅威を見逃す可能性があります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3872898/19fc1d21-4113-4195-a751-12f01f94f8b8.png)

このように、GraphRAGが関係ベースで知識を整理する構造を悪用することで、攻撃者は少量の毒データを挿入するだけで、複数の検索結果を歪めることが可能になります。



### **攻撃の影響**

- GRAGPOISONは、**98%の成功率** で複数のクエリを同時に汚染できる。
- 汚染テキストは、通常のRAG攻撃より **68%少ないデータ量** で効果を発揮。
- 既存の防御手法（LLMの内部知識参照やクエリの言い換え）に対して高い耐性を持つ。

## 防御手法とその限界

GraphRAGの脆弱性を補うため、以下のような防御手法が提案されています。

### 1. クエリの言い換え（Query Paraphrasing）

クエリを多様な表現に変換することで、特定のパターンに依存する攻撃を回避できます。ただし、GraphRAGはエンティティと関係のマッチングを行うため、単純な言い換えでは影響を受けにくいという課題があります。

### 2. LLMの内部知識参照（LLM Knowledge Referencing）

GraphRAGが外部データを使用する際に、LLMの内部知識と比較し、矛盾を検出する仕組みを導入する方法です。しかし、GraphRAGは外部データを優先する設計になっているため、LLMの内部知識を十分に活用できない場合があります。

### 3. 一貫性検証（Consistency Verification）

LLMが生成する回答の一貫性をチェックし、異常な内容を検出する手法です。例えば、同じ質問に対して複数回回答を生成し、矛盾がないか確認することが考えられます。しかし、サイバーセキュリティ領域のデータではこの手法の効果が限定的であることが示されています。

### 4. 知識ベースの毒データ検出（Poisoning Text Identification）

汚染されたデータを検出するために、異常なテキストパターンやPerplexity（困惑度）を分析する方法があります。しかし、最新のLLMが生成した毒データは人間の書いたものと区別が難しく、従来の手法では検出率が低いことが確認されています。

### 今後の課題と展望

現時点では、GraphRAGの脆弱性を完全に防ぐ方法は確立されていません。今後の研究では、エンティティ・関係ベースの整合性検証や、グラフ構造の異常検出など、GraphRAG特有の防御手法の開発が求められます。


## 参考文献

- [GraphRAG under Fire論文](https://arxiv.org/abs/2501.14050)
- [GraphRAG Arxiv論文](https://arxiv.org/abs/2404.16130)