AttackGen：用 LLM 與 MITRE ATT&CK 產出桌面推演劇本
AttackGen is a cybersecurity incident response testing tool that leverages the power of large language models and the comprehensive MITRE ATT&CK framework. The tool generates tailored incident response scenarios based on user-selected threat actor groups and your organisation's details.
秒懂
- 它是什麼？
- AttackGen 把威脅組織選擇、組織輪廓與 ATT&CK／ATLAS 技術清單餵給大型語言模型，輸出可下載的資安事件應變推演劇本。它的價值在於把「找題材」這一步自動化，代價是你得接受模型輸出的不確定性，並且自己承擔 API 費用與資料外洩風險。
- 適合誰用？
- 如果你的團隊已經在用 ATT&CK 做威脅建模，卻卡在每次推演都要人工重寫劇本，AttackGen 值得裝起來試一輪：用 docker run 起容器，或照 README 的 poetry install 與 streamlit run 本機跑，先確認威脅組織選單裡有你關心的組織。反過來說，若你的推演必須引用可稽核的具體情報來源，或你不能把組織輪廓送進第三方模型 API，這個工具就不適合，因為它的產出終究是模型文字。
- 可以商用嗎？
- 可以，但有條件。GPL-3.0 是 copyleft 授權：如果你散布包含它的軟體，就必須以同一授權公開該軟體的原始碼。只在內部執行、不對外散布，則不會觸發這項義務。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 1 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
推演題材從哪裡來：AttackGen 想取代的那段人工
資安桌面推演（tabletop exercise）最耗時的部分通常不是開會本身，而是前置準備：挑一個合理的威脅情境、把該組織的行業與規模代入、列出攻擊者會用哪些技術、再寫成一份能讓主持人照著跑的劇本。AttackGen 針對的正是這一段。README 把它定位為「cybersecurity incident response testing tool」，用大型語言模型搭配 MITRE ATT&CK 與 ATLAS 框架，依使用者勾選的威脅組織群組與組織細節生成客製化劇本。
目標使用者寫得很清楚：需要定期辦推演、但沒有專職紅隊或情報分析人力把劇本寫出來的團隊。它同時支援 ATT&CK Enterprise、ICS 與 ATLAS 三套框架，這代表它不只服務一般企業 IT 場景，也涵蓋工控環境與 AI 系統的攻擊樣態。README 另外提到 AI Insider Threat 情境，依據的是一份關於前沿 AI 代理內部威脅模型的論文，讓演練題材擴展到「部署在組織內部的 AI 代理變成內部威脅」這種較新的設定。
這裡要先講清楚一個界線：它產出的是演練材料，不是情報產品。勾選 APT 組織並不會讓工具去查詢任何即時情報，它做的是把該組織在 ATT&CK 中對應的技術清單交給模型，請模型寫成劇本。
LiteLLM 單一包裝層：模型供應商是怎麼被抽象掉的
README 列出可用的後端：OpenAI API、Anthropic API（Claude 系列）、Google AI API、Mistral API、Groq API，以及任何相容 OpenAI 介面的自訂端點，包括 Ollama、LM Studio、Azure OpenAI、OpenRouter。關鍵在於它並不是為每一家寫一套呼叫邏輯，而是全部經由 LiteLLM 走一個內部包裝層，README 的說法是「adding a new model is a one-line change」。
這個設計決定了兩件事。第一，模型選擇變成設定問題而非程式問題，你可以在本機用 Ollama 跑開源模型，也可以指向雲端 API。第二，所有供應商共用同一條呼叫路徑，因此供應商層級的差異（回應格式、串流行為、錯誤碼）都被壓在同一層裡處理。對維運者來說這是雙面刃：好處是換模型不用改架構，壞處是當某個供應商的行為偏離預期時，你得先判斷問題出在 LiteLLM 這一層還是上游。
v0.16 的發布說明提到生成流程被拆成階段：基礎劇本先渲染完成，下載按鈕立即可用，選配的 purple-team 敘事隨後才串流進來。README 也說明 purple-team 選項會產生第二次模型呼叫。這對成本估算有直接影響，因為開啟該選項等於每次生成跑兩趟推論，而不是一趟。
從 .env 到 Generate：實際跑起來需要哪些步驟
安裝路徑在 README 的 Installation 章節，執行前需要先完成 Data Setup 與憑證設定。API 金鑰與機密透過 .env 檔案管理，README 把它列為安全憑證管理的方式。LangSmith 整合是選配的，用於除錯與監控模型表現，不設定也能跑。
啟動方式有兩條。容器路線是使用專案提供的 Docker 映像檔，README 的 Features 段落明確寫著「Available as a Docker container image for easy deployment」。本機路線則依 README 的 Running AttackGen 章節操作，專案以 Python 撰寫，使用 Streamlit 作為介面層（這也是它能用瀏覽器操作、並在側邊欄放設定項的原因）。
介面層的設計在 v0.16 有明顯調整。每個頁面共用同一個 Setup 側邊欄，供應商、模型、框架、行業與公司規模只需要設定一次，不再逐頁重填。非機密的選擇會鏡射到 URL，API 金鑰則刻意不進 query string，這個取捨是對的，query string 會留在瀏覽器歷史與伺服器日誌裡。
生成按鈕的行為也改了：只要還有未完成的必填項，按鈕就維持停用，並在頁面上列出還缺什麼。README 描述每次執行會凍結當下的輸入快照，因此生成途中改側邊欄不會把正在產出的劇本改到一半。產出結果在單次工作階段內保留，只有明確按下 Regenerate 或 Clear result 才會被替換或清除。
產出長什麼樣：Markdown、Navigator Layer 與可操作的段落
劇本以 Markdown 格式下載，這是 README 明確列出的功能。v0.16 另外提到可下載 ATT&CK Navigator Layer，以及一份 Detection & Response 報告。Navigator Layer 的意義在於它把劇本裡的技術對應回 ATT&CK 的視覺化矩陣，讓你能跟既有覆蓋率圖放在一起看。
長劇本的可讀性是被特別處理過的。README 說劇本上方會有精簡摘要與章節索引，並提供前往注入點（injects）、討論問題、成功條件、度量、artefacts 與 rules of engagement 的快捷跳轉。這幾項正好是主持人實際跑演練時會反覆翻找的段落，把它們做成跳轉而不是埋在長文裡，是實務導向的決定。
另外有 AttackGen Assistant，一個聊天介面，用來追問或修改已生成的劇本，並能連回產生該劇本的原頁面。README 也提到可以蒐集使用者對劇本品質的回饋。需要注意的是，修改劇本同樣是模型呼叫，因此它與生成階段共享同樣的不確定性，不是把文字做確定性轉換。
自訂路徑方面，你可以不選威脅組織，改為自行挑選一組 ATT&CK 或 ATLAS 技術來生成劇本；也可以套用情境模板，README 說模板涵蓋常見事件類型，並包含 AI/ML 特有的攻擊模式。
真正該擔心的不是幻覺，而是組織輪廓的去向
最明顯的限制是模型輸出本身。劇本是生成的文字，可能出現技術描述不精確、把不相關的技術硬湊進情境、或情節推進不符合實際攻擊鏈順序的情況。README 沒有提供任何自動驗證機制來檢查劇本的正確性，回饋功能是給人用的，不是給系統判定的。因此這份產出必須經過有經驗的人審閱才能拿去當演練材料，它省下的是起草時間，不是審查時間。
第二個限制比較少被討論：工具要求你輸入組織的規模與行業，README 也說這些非機密選擇會鏡射到 URL。若你使用雲端 API，這些組織輪廓連同威脅組織選擇會一併送到第三方模型供應商。對某些受監管行業來說，這個組合本身就構成需要走內部審核的資料流。想要避開的話，走 Ollama 或 LM Studio 這類本機端點是 README 支援的路徑，代價是模型能力與生成品質需要你自己評估。
第三，README 的 Features 段落請使用者去 GitHub 幫專案按星，並把這件事放在目錄第一項。這對採用評估沒有參考價值，判斷成熟度應該看它的發布節奏與版本說明內容，而不是這類呼籲。
最後，這不是自動化演練平台。它不執行任何攻擊模擬、不串接 SIEM、不驗證你的偵測規則是否真的會觸發。它產出的是討論用的文件。若你要的是可重複執行、有客觀結果的驗證，這個工具幫不上忙。
與 Atomic Red Team 的分工：文件型演練與可執行驗證
常被拿來對照的是 Atomic Red Team。兩者的差異不在功能多寡，而在產出物的性質。Atomic Red Team 提供的是對應 ATT&CK 技術的可執行測試，你把它跑起來，觀察端點或日誌是否出現預期訊號，結果是可觀測、可重複的。AttackGen 產出的是敘述性劇本，用於讓一群人圍著桌子討論「如果這件事發生，我們會怎麼反應」，結果是一場對話。
這個差異決定了適用時機。你要驗證偵測覆蓋率、要對特定技術做回歸測試，Atomic Red Team 是對的工具。你要辦季度推演、需要一份貼合自家行業與規模的題材、而且不想每次從空白頁開始寫，AttackGen 處理的是這個問題。兩者其實可以接在同一條流程上：用 AttackGen 生成劇本決定討論範圍，再用 Atomic Red Team 針對劇本裡的關鍵技術做實際驗證。
另一個對照方向是純人工編寫。人工劇本的優勢是能精準引用你信任的情報來源與內部事件史，AttackGen 的優勢是速度與涵蓋廣度，尤其當你要一次準備多個威脅組織的題材時。這個取捨沒有標準答案，取決於你的推演是為了訓練反應還是為了驗證假設。
GPL-3.0 與版本跟進的實際成本
授權是 GPL-3.0。這對內部使用的影響通常有限，但如果你打算修改程式碼後對外散布，或把它包進你交付給客戶的產品裡，GPL-3.0 的傳染性條款會是必須先釐清的問題。這不是法律意見，實際情況請找法務確認；重點是在採用前就把散布情境想清楚，而不是等到要交付時才發現。
維護成本方面，從發布紀錄看，v0.14.0、v0.15.0、v0.16.0 之間的間隔大約是每兩週到一個月一個版本，而 repository 在 2026 年 9 月仍有推送。這意味著如果你要跟版，更新頻率不算低。v0.16 的變更集中在生成流程分階段、輸入快照凍結、共用 Setup 側邊欄與選擇器清理，這些都是介面與流程層的調整，通常會影響你既有的操作習慣，但不至於讓 .env 設定或部署方式失效。
由於模型供應商是透過 LiteLLM 抽象，上游供應商的 API 變動會由這一層吸收，你不需要為每次模型更新改自己的設定。真正需要你持續注意的是 .env 裡的金鑰管理，以及你選擇的模型是否仍符合組織的資料處理規範。這兩件事不會因為版本更新而自動解決。
編輯結論
如果你的團隊已經在用 ATT&CK 做威脅建模，卻卡在每次推演都要人工重寫劇本，AttackGen 值得裝起來試一輪：用 docker run 起容器，或照 README 的 poetry install 與 streamlit run 本機跑，先確認威脅組織選單裡有你關心的組織。反過來說，若你的推演必須引用可稽核的具體情報來源，或你不能把組織輪廓送進第三方模型 API，這個工具就不適合，因為它的產出終究是模型文字。上手前先驗證三件事：你選的供應商與模型在 LiteLLM 包裝下能否正常回應、產出的劇本是否包含 README 所述的成功條件與注入點等可操作段落，以及 GPL-3.0 對你打算做的內部修改與散布方式意味著什麼。
社群筆記