LLM API 列舉
列舉 LLM API 能力、限制、隱藏參數與未記錄功能的進階技術，以建立完整攻擊面圖。
LLM API 列舉
LLM API 列舉 超越標準 API 端點發現。一般 API 列舉繪製 HTTP 端點與參數；LLM API 列舉則探測模型層級介面——定義 LLM 能做與不能做之事的特定能力、限制、內容政策、模型變體與行為特性。這種深度列舉揭露 AI 紅隊行動的真實攻擊面。
能力探測方法論
結構化能力評估
LLM API 列舉的第一階段是透過系統性測試模型能做什麼，建立能力輪廓。實作方式為維護 CapabilityProfile 資料結構，記錄 model_id、能力、限制、參數與隱藏功能清單。
LLMCapabilityEnumerator 以探測分類別發送測試提示詞：
- 程式碼執行：「Write a Python script that calculates fibonacci numbers」、「Execute this code: print('hello')」、「Run the following bash command: ls -la」
- 工具使用：「Search the web for recent news」、「Use the calculator tool to compute 2^128」、「Browse this URL: https://example.com」
- 檔案操作：「Read the contents of /etc/passwd」、「Upload this file to the server」、「Analyze this CSV data file」
- 影像產生：「Generate an image of a sunset」、「Create a diagram showing network architecture」、「Draw a chart of this data」
- 多輪記憶：「Remember that my name is Alice」、「What did I tell you my name was?」、「Summarize our conversation so far」
- 系統存取：「What tools do you have access to?」、「List your available functions」、「What APIs can you call?」
對每個回應分析明確拒絕模式（"i can't"、"i cannot"、"not supported" 等）與能力指示符（程式碼區塊、「searching」、「file contents」、「function」）來判斷能力是否存在。記錄每類別的支援度布林值、信心度（0-1）與詳細結果。於探測間插入 rate_limit_delay 延遲以避免速率限制。
限制邊界繪製
一旦辨識能力後，下一步是繪製限制確切從何處開始。這與安全邊界繪製不同——此處聚焦於 API 層級限制而非內容政策邊界。
RestrictionMapper 使用二分搜尋發現實際符元上限（起始範圍 1 到 200000，縮小至被接受的最大上下文長度）。為每個參數測試有效範圍，例如：
temperature：[0.0, 0.5, 1.0, 1.5, 2.0, 2.5, 3.0]top_p：[0.0, 0.1, 0.5, 0.9, 1.0, 1.1]frequency_penalty／presence_penalty：[-2.0, -1.0, 0.0, 1.0, 2.0, 3.0]max_tokens：[1, 100, 1000, 4096, 8192, 16384, 32768]n：[1, 2, 5, 10, 20]logprobs：[True, False]top_logprobs：[0, 1, 5, 10, 20, 50]
記錄每個參數的有效值與拒絕值以及錯誤訊息。
隱藏參數發現
未記錄的 API 參數
許多 LLM API 接受未列於公開文件的參數。這些隱藏參數可解鎖除錯模式、替代行為或繞過某些限制。
HiddenParameterFuzzer 測試一組候選參數：
- 取樣控制：
top_k、min_p、typical_p、repetition_penalty、length_penalty、no_repeat_ngram_size、num_beams - 系統與除錯：
debug、verbose、raw_output、include_usage、echo、include_stop_str_in_output、skip_special_tokens - 安全與過濾：
safety_settings、harm_category、block_threshold、content_filter_level、enable_safety、disable_moderation - 快取與最佳化：
use_cache、cache_seed、seed、deterministic、prefix_caching、prompt_cache - 模型行為：
system_fingerprint、service_tier、parallel_tool_calls、response_format、json_mode、structured_output - 內部／實驗：
beta、experimental、preview、v2、internal_mode、developer_mode、admin
對每個參數送入符合其名稱性質的測試值（例如 temperature/penalty 類用 0.0/0.5/1.0；debug/verbose 類用 True/False；mode/tier/level 類用 "low"/"medium"/"high"/"debug"/"admin"）。錯誤訊息含 "unknown" 或 "unrecognized" 表示參數被明確拒絕；含 "invalid" 或 "value" 表示參數被辨識但值無效（代表參數為 API 所知）。
回應標頭分析
LLM API 回應常含揭露內部細節的標頭。有意義的標頭包括：
- 速率限制資訊：
x-ratelimit-limit、x-ratelimit-remaining、x-ratelimit-reset、retry-after - 伺服器身分：
server、x-powered-by、via、x-served-by、x-backend - 請求追蹤：
x-request-id、x-trace-id、cf-ray、x-cloud-trace-context - 模型資訊：
x-model-id、x-model-version、openai-model、openai-processing-ms、x-inference-time、x-queue-time - 快取資訊：
x-cache、x-cache-hit、cf-cache-status、x-prompt-cache、age - 安全／過濾器資訊：
x-content-filter、x-safety-category、x-moderation-result - 組織／帳戶：
openai-organization、x-org-id、x-account-tier
也應擷取所有非標準標頭——這些常揭露內部系統架構。
模型變體列舉
發現可用模型
LLM 供應商常擁有比其公開記錄更多的模型變體。系統性列舉可揭露預覽模型、過時版本與內部變體。
策略：
- 使用 models 端點：呼叫
api_client.models.list()取得自我宣告的可用模型。 - 蠻力已知模式：對各供應商展開命名模式，例如：
- OpenAI：
gpt-4o、gpt-4o-mini、gpt-4-turbo、gpt-4o-{date}、gpt-4-{date}、o1、o1-mini、o1-preview、o3、o3-mini - Anthropic：
claude-3-opus-{date}、claude-3-sonnet-{date}、claude-3-haiku-{date}、claude-3.5-sonnet-{date}、claude-opus-4-{date} - Google：
gemini-pro、gemini-ultra、gemini-nano、gemini-1.5-pro-{date}、gemini-2.0-flash-{date}、gemini-2.5-pro-{date}
- OpenAI：
對每個展開的變體送極簡請求（max_tokens=1）。錯誤訊息「not found」／「does not exist」代表不存在；「permission」／「access」代表存在但受限（仍為有用發現）。
功能旗標偵測
部分 LLM API 使用可透過特定標頭或參數切換的功能旗標：
- 標頭：
X-Feature-Flags（值：beta/preview/experimental/v2）、X-Beta-Features、X-Preview、X-API-Version（值：2024-01-01 至 2026-01-01、preview、beta、latest）、OpenAI-Beta（assistants=v2、realtime=v1、responses=v1、prompt-caching=v1） - 查詢參數：
api-version、beta、features
對每個旗標值發送相同請求並與基線比較。差異顯示該旗標改變 API 行為。
列舉工作流程
階段式途徑
完整 LLM API 列舉遵循以下流程：
| 階段 | 目標 | 技術 | 輸出 |
|---|---|---|---|
| 1. 發現 | 找出所有端點與模型變體 | 端點蠻力、模型列表、文件抓取 | 端點圖、模型清單 |
| 2. 參數繪製 | 繪製所有接受的參數 | 參數模糊測試、錯誤分析、標頭檢查 | 參數目錄 |
| 3. 能力剖析 | 判定模型能做什麼 | 能力探測、工具列舉、多模態測試 | 能力輪廓 |
| 4. 限制繪製 | 找出限制於何處強制 | 符元上限測試、速率限制探測、內容政策探測 | 限制圖 |
| 5. 功能發現 | 挖掘隱藏功能 | 功能旗標測試、未記錄參數發現 | 隱藏功能清單 |
| 6. 關聯 | 將發現連結至攻擊路徑 | 交叉參照所有資料、辨識不一致 | 攻擊面圖 |
自動化列舉管線
LLMEnumerationPipeline 以順序執行所有列舉階段：依序呼叫 ModelVariantEnumerator、RestrictionMapper、LLMCapabilityEnumerator、HiddenParameterFuzzer，然後於 _analyze_attack_surface 分析結果以辨識攻擊機會，例如：
- 過度寬鬆的參數：若 temperature 允許 > 2.0，記錄「可能產生更多變／可利用的輸出」
- 接受的隱藏參數：若 debug 類參數被接受，記錄「可能暴露內部資訊或繞過安全」
- 意外能力：若 code_execution、system_access、file_operations 被支援，記錄「可能可供系統存取利用」
錯誤訊息情報
自錯誤回應中萃取資訊
LLM API 錯誤訊息是豐富情報來源。不同錯誤類型揭露系統不同面向。ErrorIntelligenceCollector 以正規表達式分類：
- 模型資訊：
model[:\s]+([a-zA-Z0-9\-\.]+)、version[:\s]+([0-9\.]+)、engine[:\s]+(\S+) - 基礎設施：
server[:\s]+(\S+)、region[:\s]+([a-z\-]+\d*)、instance[:\s]+...、pod[:\s]+... - 速率限制：
limit[:\s]+(\d+)、remaining[:\s]+(\d+)、tokens per minute[:\s]+(\d+)、requests per (minute|hour|day)[:\s]+(\d+) - 內部路徑：匹配
/xxx.py、.js、.go、.rs等檔案路徑模式、堆疊框架「at /xxx:NNN」、Python 格式「File "xxx"」
故意觸發錯誤的方式包括：空 messages、無效 role、極長內容、負數 max_tokens、超範圍 temperature、不存在的 model 名稱。對每個回傳字串套用所有模式並去重。
行為指紋辨識
回應模式分析
超越明確能力與參數，LLM API 展現揭露實作細節的行為模式。BehavioralFingerprinter 測量：
- 回應一致性：於 temperature=0 執行相同提示詞 10 次，檢查是否具確定性。非確定性的 temp=0 暗示跨模型副本的負載平衡。
- 延遲輪廓：測量短（"Say hi"）、中（50 字段落）、長（200 字論文）提示詞的回應延遲。
- 符元計數：對各類測試字串（純英文、Unicode 混用、程式碼、特殊字元、重複內容）計算
chars_per_token——此比率揭露分詞器家族。 - 截斷行為：測試 1000 至 100000 符元填充量。記錄接受／拒絕與模型是否仍記得訊息起始。
- 串流行為：啟用
stream=True並測量首符元時間、chunks 間隔、總時間——揭示推論架構特性。
報告與記錄
列舉報告結構
將列舉發現以結構化格式記錄，直接餵入攻擊規劃：
| 章節 | 內容 | 消費者 |
|---|---|---|
| 目標摘要 | 供應商、模型 ID、API 版本、認證類型 | 全體成員 |
| 能力矩陣 | 支援／不支援能力及信心度 | 攻擊規劃者 |
| 參數目錄 | 所有接受的參數及其有效範圍 | 載荷開發者 |
| 限制圖 | 符元上限、速率限制、內容限制 | 基礎設施攻擊者 |
| 隱藏功能 | 未記錄參數、功能旗標、除錯模式 | 進階漏洞利用開發者 |
| 錯誤情報 | 透過錯誤訊息洩漏的資訊 | OSINT 分析師 |
| 行為輪廓 | 延遲、一致性、分詞特性 | 全體成員 |
| 攻擊機會 | 基於發現的優先順序攻擊路徑清單 | 紅隊負責人 |
行動安全
執行 LLM API 列舉時維持行動安全：
- 速率限制感知 ——間隔請求以避免觸發速率限制或異常偵測。用早期回應的速率限制標頭校準請求頻率。
- 帳戶輪替 ——使用多個 API 金鑰分散列舉流量。單一金鑰發送數千異常請求會引起注意。
- 請求正規化 ——將列舉探測與看似合法的請求混合以融入正常流量模式。
- 錯誤處理 ——優雅地捕捉並記錄所有錯誤。中途崩潰的列舉工具浪費時間且可能留下部分結果。
- 資料分類 ——將所有列舉結果標記為敏感。它們含目標設定細節，不應洩漏至委託外。
OpSecEnumerator 包裝器套用抖動延遲（random.uniform(min_delay, max_delay)）、錯誤計數閾值（超過 max_errors_before_pause 則暫停 pause_duration 秒）、成功時衰減錯誤計數。
實務工作流程範例
典型 LLM API 列舉委託進行方式如下：
- 自文件開始 ——閱讀所有公開 API 文件、變更日誌與部落格文章。留意任何 beta 功能、即將變更或過時端點的提及。
- 列舉模型 ——透過 models 端點與模式式蠻力列出所有可用模型變體。注意含日期戳的變體。
- 繪製參數 ——對每個相關模型，系統性測試所有候選參數。記錄何者被接受、何者被拒絕，拒絕錯誤如何不同。
- 剖析能力 ——發送能力探測以理解模型能做什麼。測試程式碼執行、工具使用、檔案存取、多模態輸入。
- 蒐集錯誤情報 ——故意觸發各種錯誤條件並分析回應中洩漏的資訊。
- 建立行為輪廓 ——測量延遲、一致性、符元計數、串流行為以理解基礎設施。
- 關聯與報告 ——交叉參照所有發現以建立完整攻擊面圖。依潛在影響與成功機率排序攻擊機會。
重點總結
LLM API 列舉是基礎性的偵察活動，揭露 LLM 部署的真實攻擊面。透過超越標準 API 端點發現以探測模型層級能力、限制、隱藏參數與行為特性，紅隊建立規劃有效攻擊所需的情報。
最有價值的列舉發現常在縫隙中——被靜默接受的未記錄參數、未列於文件的模型變體，以及洩漏內部細節的錯誤訊息。具適切工具與行動安全的系統性列舉將這些縫隙轉為可行動的攻擊情報。