這一篇的寫作範圍： 只講工具的定位、工具自己的弱點，以及新聞證據怎麼讀。不寫可以照著做的攻擊步驟，不點名任何被指為攻擊者的個人或帳號，也不討論哪家機構被入侵的細節。
上一篇測的是 AI 系統，AI 是被測物。這一篇倒過來：AI 是攻擊者，被測物是一般的網站、API 或網路服務。
| 測 AI 系統（第 6 篇） | 用 AI 測別人（這一篇） | |
|---|---|---|
| AI 的角色 | 被測物 | 攻擊者 |
| 被測物 | LLM 應用 | 一般軟體：網站、API、網路服務 |
| 出錯的代價 | 一個不準的數字 | 打到不該打的目標 |
在系列地圖上，這是第七類。適合想知道這類工具能做什麼、為什麼它自己也有風險的人。內容依據各專案的文件與廠商報告；本文沒有安裝這些工具，也沒有對任何目標掃描；HexStrike 只讀了原始碼，沒有執行。
四個代表
| 工具 | 一句話定位 | 要注意的限制 |
|---|---|---|
| Strix | 多個 AI agent 在 Docker 容器裡對網站、API、原始碼做滲透測試，要拿出實際的證明才算發現 | 範圍限制要靠自然語言寫進指令，文件裡沒看到程式強制的目標清單 |
| Shannon | 對 web 應用與 API 的自主滲透測試，開源版必須有原始碼 | 授權是 AGPL-3.0；黑箱模式要買商業版；官方寫明不可對正式環境執行 |
| AI-Infra-Guard（騰訊朱雀實驗室） | 掃描 AI 基礎設施、MCP server 與 skill、部署中的 agent，並測越獄 | 開源版沒有登入機制，官方說不該部署在公開網路 |
| HexStrike-AI | 一個 MCP 伺服器，讓 LLM 驅動 150 多個資安工具 | 幾乎沒有目標範圍檢查（見下節） |
Strix 與 Shannon 都靠「要有實際證明才算發現」來控制誤報，但兩者的準確度都沒有可信的獨立數字。Strix 自己在資安競賽題型（CTF）基準上報告 v0.4.0 解出 104 題中的 100 題（96%）。競品 Escape 則在含 20 個漏洞的靶機上實測，Strix 找到 1 個、Shannon 找到 6 個，Escape 自家產品找到 15 個。三個開源工具用同一個模型（DeepSeek v3.2），Escape 用自家的多模型，Shannon 另外拿到了原始碼，每個工具只跑一次。這是競爭對手做的單次實驗，只能說題型與設定不同會讓結果差很多。
第一個問題：工具自己是攻擊面
AI 滲透工具會讀不受信任的內容：被測網站的頁面、被測程式的原始碼。這些內容如果夾帶指令，LLM 可能照做。
- Strix。 一位獨立研究者在 2025 年底針對舊版發表了報告（另有技術部落格的相同主題文章）：被測網頁內的惡意內容被讀進去後，LLM 可能產生真的工具呼叫，在 Strix 的容器裡執行指令，也可能被誘導去打第三方目標。報告裡維護者的回覆只說會再檢視，沒有承諾修補；這是研究者單方面的轉述，Strix 方的回覆在公開資料中看不到。這裡的 RCE（遠端程式碼執行，也就是讓外人在你的機器上跑他指定的程式）發生在容器裡，容器內能執行指令不等於逃出容器；但工具被誘導去打第三方，容器擋不了。沙箱見第 2 篇，RCE 的完整說明見站內這篇。這類攻擊的原理是 prompt injection，見站內這篇。
- Shannon。 README 直接告誡：不要把它指向不受信任或對抗性的程式碼庫，因為會讀原始碼的 AI 工具可能被惡意內容影響。它曾因為內建固定的 API key 被通報（GitHub 安全公告 GHSA-qrvr-jqxg-65rv，CVE-2026-29023），修補狀態請看公告頁。
- AI-Infra-Guard。 團隊在 Help Net Security 的訪談裡承認，兩個掃描元件會讀取敵對內容；他們稱 4.1.9 起把讀入的內容與指令分隔以降低間接 prompt injection，但那是降低風險的措施，不是形式上的保證。README 的更新紀錄另有一項：動態掃描模式用工具白名單防止 RCE（4.5.2）。它同時保存被評測模型的 API key，開源版沒有登入機制，所以被連到就等於交出金鑰。
- HexStrike。 一份 GitHub issue 指出伺服器沒有驗證、綁在所有網卡上，可以注入 shell 指令；依當時的原始碼，指令端點直接執行輸入，未見驗證檢查。README 本身也寫了要自行考慮加上驗證。這是只讀原始碼的觀察，沒有執行。
共通點：這類工具為了「能攻擊」而被賦予很大的權限，卻去讀攻擊者控制的內容。第 2 篇的沙箱與第 3 篇的護欄，對這類工具比對一般 agent 更重要。
第二個問題：開源之後，用途管得住嗎
雙用途（dual-use）指同一個工具，既能用在授權的測試，也能被拿去攻擊，工具本身分不出使用者的意圖。開源之後，連設計者也無法限制誰拿去用。
防濫用設計通常做在操作者可以改的地方。ARTEX 的控制台有攔截並審批工具呼叫的機制，規則存在資料庫裡、使用者可以編輯，部分規則預設還是關閉的（見一篇讀碼文章）；韓國資安公司 Genians 在 10 月 12 日的報告裡有類似判斷：這些攔截規則與審批功能由操作者自行設定，被濫用時難期待實效。Zscaler 看到的實際部署裡，操作者把工具換成自己的版本，並在指令裡預先聲明目標都已獲授權，等於在模型層就把防濫用設定繞開。
HexStrike 的 README 自己承認，模型的安全設定會讓某些請求被拒，並在文件裡提供了應對寫法。這是作者自述，不是在說工具實際怎麼被使用。
例子：ARTEX 事件，哪些證據有多強
ARTEX 是 2026 年中出現的開源 AI 自主滲透測試系統。10 月多家廠商報告有人在韓國金融機構相關的入侵與全球的 AI 輔助攻擊中使用它，作者在 10 月 8 日宣布不再更新並轉為閉源（聲明見 The Hacker News，日期見路透社報導）。
事件的證據可以這樣分級：
| 主張 | 證據 | 強度 |
|---|---|---|
| 某攻擊活動的操作者用過 ARTEX | CrowdStrike 取得攻擊者控制的開放目錄（對話紀錄、設定檔）與一台 ARTEX 實例；Recorded Future 自述分析了同一組攻擊者基礎設施內的開放目錄；Zscaler 第二篇（10/21）明說引用 Recorded Future 的分析，第一篇（10/14）沒交代證據來源；Genians 依該公司公開報告，是在疑似被用於攻擊的伺服器上擷取到 ARTEX 登入頁與網頁標題字串 | 高，但這幾家不是各自獨立的證據：CrowdStrike 與 Recorded Future 的基礎設施重疊（指向同一台伺服器），Zscaler 第二篇引用 Recorded Future。Zscaler 第一篇有沒有自己的資料看不出來；Genians 的擷取是另一條線索，但只證明伺服器上出現過這個字串 |
| ARTEX 是入侵某幾家特定機構的工具 | 廠商只說目標與新聞報導重疊 | 中，情況證據 |
| 微軟報告的活動用了 ARTEX | 微軟自己的偵測資料（產品回報的遙測）顯示速度與規模；但報告沒說明它如何判定是 ARTEX，公布的指標是 IP 與通用的連線特徵 | 對行為是高，對「是 ARTEX」未知 |
| 官方公布的受害數字 | 監管機關與警方，經媒體轉述，數字隨時間變動 | 中，要標日期 |
把活動連到特定個人或組織的說法，本文不採用也不複述；廠商報告裡這部分的證據通常最弱。
兩個要分清楚的地方：
- 韓國的案子與微軟報告的案子是兩條不同的線。 微軟只把韓國案當作公開報導的例子引用，沒有把它歸給自己追蹤的 Storm-0940；Storm-0940 是微軟另行歸因的團體。不要把兩件事寫成同一條線。
- 多家廠商說同一件事，不等於多個獨立證據。 要看它們是否共用同一批資料，或是直接引用彼此。這跟第 8 篇會談的「查來源」是同一個習慣。
對比 HexStrike：它的「被攻擊者濫用」只有 Check Point 一篇，來源是地下論壇貼文的截圖，用詞是「聲稱」和「討論」；其他報導都轉述同一篇，未見偵測資料或事件調查。所以兩件事可以並排，但證據等級不同：ARTEX 有多家廠商的分析（部分彼此重疊或引用），HexStrike 是單一來源的聲稱。
閉源有沒有用
作者 10 月 8 日轉閉源。之後的情形：
- 原始儲存庫下架後，仍有許多 fork 與備份複本在流通，也出現韓文在地化版本（見 Genians 的報告，截至 10 月 11 日）。具體數量沒有可核對的來源，本文不引用。
- 好幾個 fork 另有改名版、翻譯版出現。AhnLab 的第二篇分析在一個改造版的基礎設施上看到攻擊準備環境的痕跡；AhnLab 也強調，不能把暴露在外的 ARTEX 位址全當成攻擊基礎設施，或連到特定行動。
- 微軟描述的活動最早從 2026 年 9 月開始，其中 10 月中旬的密碼噴灑與 ConnectWise 下游登入發生在閉源之後；報告沒有說明所用版本。
公開資料中看不到閉源後濫用下降的量化數字。ThreatBook 說開源版原是個人專案，並推出需要授權目標白名單的商業版 ARTEX Pro；這個說法來自利害關係方，效果沒有獨立驗證。
怎麼用
- 看到「某工具被用來攻擊」的新聞，問三題： 誰說的（偵測資料、事件調查，還是論壇截圖）、是不是獨立的（多家報告是否共用同一批資料）、有沒有量化（多少次、多少受害者、何時）。
- 要用這類工具測自己的東西，先隔離。 只指向你自己控制的測試環境（例如 staging），不要指向第三方或有人刻意擺陷阱的程式碼庫。工具放在第 2 篇講的沙箱裡跑，沙箱內只放這次測試用的臨時憑證，測完整組刪掉。
- 只對自己擁有或書面授權的目標。 這些工具的範圍設定多是給 LLM 的指令，不是網路層的強制；Shannon 的文件把範圍規則寫得最結構化，但沒有說明有出站過濾（限制工具能連到哪些外部位址）。
- 別把星數當成熟度。 選型前，先查有沒有近 6 個月的 release、有沒有人處理 security advisory，再看星數。Strix 與 Shannon 星數都高，但自報成績與競品的單次實驗差距極大。
- 如果你把自己的工具開源，把範圍檢查寫進程式（目標白名單、出站過濾），不要只寫在給模型的指令裡；指令只能擋模型犯錯，擋不了持有者蓄意。
自我檢查
問題：五家廠商都說攻擊者用了同一個工具，這是五個獨立證據嗎？
答案：不是。要先看它們是否共用同一批資料來源，或是直接引用彼此。ARTEX 的例子裡，CrowdStrike 與 Recorded Future 的基礎設施重疊，Zscaler 第二篇引用 Recorded Future，這幾條算同一條證據線；自己另外取得資料的才算另一條。
整體來說
AI 滲透工具的價值是把重複的偵察與驗證自動化；它的風險有兩層，一層是它自己會被反控，一層是開源後用途無法限制。新聞怎麼讀比工具怎麼選更值得先學：先看證據是誰的、獨不獨立、有沒有數字。下一篇是這個系列的最後一篇，把前七篇用過的判斷方法整理成一份檢查表，用來拆解任何一則工具宣稱。
參考資料
- usestrix/strix
- KeygraphHQ/shannon；GitHub 安全公告 GHSA-qrvr-jqxg-65rv
- Tencent/AI-Infra-Guard；Help Net Security 報導
- 0x4m4/hexstrike-ai；Check Point：HexStrike AI
- Escape：Benchmarking agentic AI pentesting tools
- ARTEX 事件：CrowdStrike、Recorded Future、Zscaler ThreatLabz（10/14）、Zscaler ThreatLabz（10/21）、AhnLab ASEC（第一篇、第二篇）、Genians 報告（10/12）、Straits Times／路透社（閉源日期）、Microsoft Security Blog（2026-10-21）、The Hacker News
- 上一篇：測試你的 LLM 應用
- 站內：RCE 是什麼