兩週內，三個國家的調查報告出現同一個名字。

10 月 7 日，CrowdStrike 公布韓國金融機構攻擊案的調查，攻擊者伺服器裡有 ARTEX 的設定檔。10 月 19 日，日本 GMO イエラエ 說約 20 家日本企業被同一組基礎設施鎖定，確認用的是 ARTEX。10 月 22 日，台灣的 91APP 公布 18 天調查報告，系統內發現 ARTEX 的痕跡。

ARTEX 到底是什麼？

上次寫韓國七家金融機構那篇，我留了一句：社群說它是「一個 agent 規劃、一個 agent 執行」，但我只看到 README 前半段，沒辦法確認，所以沒寫。這次把架構段讀完，可以確認了，而且比「一個規劃、一個執行」更完整。

先講清楚：這篇依 ARTEX 其中一個 fork 的 README、CrowdStrike 與雲安全聯盟（CSA）的報告、91APP 的官方說明、日本 GMO 的公開調查、韓國金融保安院（FSI）對媒體的說法，加上幾份獨立分析。我沒有把 ARTEX 架起來跑，也沒有任何一手鑑識資料。

影片解說

觀看本文的影片解說：91APP 遭駭背後：ARTEX 不是 AI 駭客，是飽和攻擊的開始

影片依據本文整理，涵蓋：三個事件的時間軸、ARTEX 的 agent harness 架構、91APP 被打穿的 Appsmith → GitLab → CI → 訂單資料庫那條鏈，以及用無護欄紅軍 AI 與 coding agent 做的防守流程。

30 秒定位

時間 調查 ARTEX 出現的方式
10/7 CrowdStrike，韓國金融機構 攻擊者伺服器的 ARTEX 設定檔、Claude Code session
10/19 日本 GMO イエラエ 約 20 家企業被同一組基礎設施鎖定；另有 6 台 AI 攻擊主機
10/22 台灣 91APP，18 天報告 系統內發現 ARTEX 痕跡；破口是未修補的 Appsmith

日本那份還有一個細節：另外 6 台 AI 攻擊主機幾乎只打日本，而且各自鎖定不同產業，有的打數位禮品與零售，有的打保險與金融，有的打電商、媒體與物流。已確認被鎖定的企業裡，有 8 家在 9 月到 10 月之間公告資料外洩。

這不是亂槍打鳥。這是依國家、依產業部署不同主機的分眾作業。

項目 內容
是什麼 開源的 LLM 多 agent 滲透測試系統。不是模型，是把模型接上工具、記憶、範圍與審批的 harness
作者 GitHub 帳號 Autumn-27，2026-07-26 上架，AGPL-3.0
現況 原 repo 已 404；作者在 10/8 下架並表示轉閉源；fork 與鏡像還在
技術棧 Go 後端內嵌 Next.js、PostgreSQL；agent 能力來自同作者的 norma SDK
模型 填 Anthropic 或 OpenAI 的 API key 就能跑，也可自訂 provider、model、base_url
預設值 連接埠 8787；每個任務預設 3 個 worker
授權 AGPL-3.0，但作者另外加了使用條款：禁止對任何線上系統測試，也禁止用於真實滲透測試

一句話：它是一套把「偵察、找漏洞、規劃路徑、執行、驗證、記錄」包成產品的開源系統，模型是它插上去的引擎。

最後那一行授權很重要，後面會回來講。

91APP 的 18 天：被打穿的不是 AI，是一條老鏈

91APP 是台灣的電商技術服務業者，客戶是品牌，品牌的客戶是消費者。這次受影響的是 Commerce Cloud 的其中一座訂單資料庫。91APP 說，遭存取的是訂單資訊，不含信用卡等支付資訊；Marketing Cloud、91APP Payments 與 iCHEF 未受影響。

官方時間軸是這樣：

日期 發生什麼
10/4 第一次接獲客戶通報，啟動資安盤查。當時用詐騙訊息比對，名字、地址、訂單內容都對不上，先朝客戶的 ERP 系統查
10/7 更多詐騙訊息，連非 91APP 客戶的品牌也收到，擴大盤查外部合作系統
10/8 成立緊急應變小組，決定委聘奧義智慧科技協助調查
10/9–10/11 連假期間擴大盤查全系統、分析 log
10/14 在一台內部持續整合（CI）主機發現 10/3 有一支未授權執行緒的執行紀錄；確認 Commerce Cloud 一座訂單資料庫遭非法存取，當日阻斷
10/15 依個資法通報數發部，開始向客戶說明
10/22 公布 18 天調查報告

根因寫得很清楚：內部使用的第三方工具 Appsmith 有漏洞，91APP 沒有及時套用修補，駭客從這裡進入內部網路，在 GitLab 上找到其中一座訂單資料庫的金鑰，然後存取訂單資料。報告沒有公布是哪一個 CVE，只說是未及時修補的漏洞。

把這條鏈畫出來：

1
2
3
4
5
6

未修補的 Appsmith
  → 進入內部網路
  → 在 GitLab 找到訂單資料庫金鑰
  → 10/3 CI 主機出現未授權執行緒
  → Commerce Cloud 訂單資料庫被非法存取
  → 10/14 阻斷

這張圖是我把報告的根因和時間軸接起來的示意，不是報告自己畫的鏈。

這條鏈裡，沒有一個環節需要 AI 自己想出新的攻擊。需要的是一個沒修的第三方工具、一份放在 repo 裡的金鑰、一條從 CI 主機通往資料庫的網路路徑。這三件事，都不需要 AI 才找得到；一次認真做的滲透測試，或一次紮實的資產盤點，就該抓到其中至少一項。

防堵措施也值得看：移除受入侵的 Appsmith、更換內部系統權杖與資料庫帳密、限制 CI 主機與資料庫網段之間的連線、停用遭冒用帳號、重建 GitLab 權限。這幾件事，剛好可以對照下面要談的防守重點。

但報告的「攻擊型態」寫的是 ARTEX AI Agent 自動化攻擊。一個是 AI 工具，一個是修補與秘密管理。報告沒有說 ARTEX 在這條鏈的哪一段做了什麼、用哪個模型、從哪個入口進來。這是閱讀時最需要自己補上的空白。不是批評，是提醒：不要把工具的名字當成完整的因果解釋。

還有一個數字。91APP 說，這件事中斷了連續 5,025 天沒有資安事件的紀錄。

從時間軸看，18 天不是調查太慢，是「先查明再通知」的選擇。董事長何英圻在公告裡承認，10/8 成立緊急應變小組時就該同步提醒品牌客戶，這是公司的疏失。結果是，10/4 到 10/22 之間，消費者先收到詐騙訊息，品牌才陸續知道。技術上這是鑑識，治理上這是通知時機的決策。對平台業者，這一段比 Appsmith 更難修，因為它牽涉的是「什麼時候要承認不確定」。

91APP 承諾吸收品牌通知會員的簡訊與 email 費用，並對因此受詐騙而財損的消費者提供補償。補償可以事後談，信任不行。截至 10/22，受影響的品牌、會員人數與資料範圍仍在確認。

對把會員資料交給平台的品牌，這件事也是一個提醒：合約裡的事件通知義務、資料最小化、聯合通知演練，跟平台有沒有裝 EDR 一樣重要。平台的一個資料庫，後面是一群品牌的會員信任。

ARTEX 內部：它不是模型，是一間把滲透測試做成產品線的戰情室

把 ARTEX 想成一台車。模型是引擎，ARTEX 是底盤、方向盤、儀表板、行車紀錄器。你可以換引擎，DeepSeek、GLM、Grok、Claude 都行，但沒有底盤，引擎不能上路。

我把 README 的架構段整理成這樣：

1
2
3
4
5
6
7
8
9
10

Goals      拆解目標、抽出 scope
Planner    產生下一個 intent
Worker ×N  執行工具（預設 3 個）
MainAgent  人在迴路

Asset Graph        有哪些門：domain / subdomain / ip / service / app / endpoint
Exploration Graph  試過什麼：goal / intent / fact / finding / hint
                   邊是 spawns / derived_from / yields / proves

支撐：MITM 流量代理、審批攔截、DNS/HTTP enrichment、MCP、Skills、Memory、Report

Agent 能力來自一個叫 norma 的 SDK，裡面有 agentcore、tool、permission、harness、memory、transcript。你看出來了嗎？這跟企業在做 agent 時的元件清單幾乎一樣。差別只在工具集：ARTEX 接的是 nmap、HTTP、Bash，企業接的是 ERP、CRM、資料庫。

元件 它在做什麼 企業 agent 的對應
Goals 拆目標、抽範圍 任務規劃
Planner 決定下一個 intent 決策層
Worker 執行工具 工具層
MainAgent 人在迴路 審批
Asset Graph 有哪些門 資產清單
Exploration Graph 試過什麼、證明什麼 狀態與來源推導鏈（provenance）
Traffic Proxy 錄下所有請求和回應 可觀測性
Guard 工具審批 權限

ARTEX 架構：控制平面、Agent 迴圈、審批與執行路徑

圖：ARTEX 架構。從控制平面到 Agent 迴圈、審批閘門、工具層、流量代理，最後打到目標資產；下方是 PostgreSQL 的雙圖與 ScopeSentry 同步。依 fork README 重繪。

我最在意的是那兩張圖。Asset Graph 回答「還有哪些門沒試」，Exploration Graph 回答「這條路試過沒、得到什麼、證明什麼」。有這兩張圖，一個操作者才能同時管很多條線，而不會迷路。這就是「變快」的來源，不是模型突然變聰明，是攻擊的專案管理被產品化了。

對攻擊者，這是生產力；被查扣的時候，這是證據。這跟我們在做 agent 可觀測性時講的是同一件事，只是立場相反。

還有一個細節：它的資產資料可以直接從 ScopeSentry 同步，那是同一個作者的另一個工具。整個生態是接起來的。

安裝呢？README 寫得很輕鬆。Docker、一鍵腳本、預設 8787。意思是任何人租一台便宜 VPS，就能有一台自己的 AI 紅隊控制台。這是能力的商品化，不是能力的突破。

一份 10 月初的曝露面研究掃到 359 個對外暴露的 ARTEX 相關 IP，其中 93% 開在預設的 8787。這是暴露的服務，不是 359 個攻擊者，但你可以看出這個工具被裝得多普遍。真正的問題不是「AI 會不會打」，是「現在有多少人有這台控制台」。

它內建的護欄，是給自己人的治理，不是給外人的邊界

ARTEX 有審批閘門（approval gate）、有範圍（scope）、有人在迴路。聽起來很安全。

但這三個東西的主詞都是操作者（operator）。範圍是操作者填的，核准鍵是操作者按的，模型是操作者選的。它可以接 OpenAI 或 Anthropic 的 key，也可以自訂 base_url 接中轉。所以這些設計保護的是「操作者不要誤打」，不是「別人不能拿它來打你」。

這是企業導入 agent 時最容易誤會的地方：審批閘門是治理功能，不是安全邊界。真正的邊界是權限、網路、身分與資料。

模型廠的護欄也不在路徑上。韓國案的主力模型是 DeepSeek v4.1-flash，透過中轉使用，輔助用 GLM-5.3 和 Grok 4.6。ARTEX 不綁模型，所以「模型會不會拒絕」不是防守方的控制點。控制點是「誰有權把這個工具指向你」。

作者下架時說，因為被濫用，所以轉閉源。這是負責任的動作，但它不是控制。AGPL-3.0 的授權不限制用途，作者另外加的使用條款是社會規範，不是技術限制。fork、鏡像、已經下載的 binary，不會因為原 repo 消失而消失。我 10/24 查的時候，一個英文鏡像還有近百個 fork。

你可以下架一個 repo，不能下架一個能力。

「ARTEX 痕跡」不等於「AI 自主攻擊」

這是我最想講清楚的一段。

層次 問題 目前公開證據
1. 工具在場 系統裡有沒有 ARTEX 的痕跡 91APP：有。韓國：有。日本：有
2. 工具做了哪一段 情蒐、掃描、驗證、橫向，還是全部 韓國 FSI 說，回溯新韓的 log 與攻擊 IP 看到使用痕跡；但沒有公布逐步對應
3. 工具自己決定目標與整條鏈 沒有人下指令？ 公開資料沒有證明。FSI 的說法是「不是 AI 自己決定要攻擊，是駭客用了 AI 工具」

91APP 的公開資訊只到第 1 層。報告說「ARTEX AI Agent 自動化攻擊」，但沒有說 ARTEX 執行了哪一段、用哪個模型、從哪裡進來。破口是 Appsmith，金鑰在 GitLab，這兩個比較像人的選擇，不像模型自己發明。這是我的推論，不是報告的結論。

兩邊的措辭不一樣，不是誰說謊，是證據層級不同。FSI 有 log 和 IP 回溯，所以敢講「人用了工具」；91APP 是在自己的系統裡看到痕跡，寫「ARTEX 攻擊」是他們調查後的判斷，但讀者很容易補成「AI 自己打進來」。

三個不能從報告推出來的結論：

  1. 不能說 91APP 與韓國、日本是同一組攻擊者。工具一樣不代表人一樣，fork 滿地都是。
  2. 不能說 AI 自主完成入侵。目前最強的官方說法，是攻擊者使用了 ARTEX。
  3. 不能說 AI 讓攻擊變強。目前公開資訊裡沒有 0-day；91APP 是未修補的已知漏洞，韓國是查詢端點與員工系統，都是老問題。

能推的只有一件事：試錯變便宜，所以以前「不值得打」的系統開始值得打。

韓國那邊還有一個很實用的觀察。FSI 說，攻擊者換 IP 之後，手法和鎖定的漏洞都一樣，而且拆開攻擊資料，會看到「從 ARTEX 發出的特定資料」在不同案件裡共同出現。所以他們看起來不是靠 IP 在抓，是靠行為特徵。這也直接回答了「封 IP 有沒有用」：應急可以，長期沒用。

防守方要補的五個洞

把 AI 兩個字拿掉，91APP 這條鏈是教科書等級的老問題。下面五件事，不用等到下一次 AI 攻擊就該做。

洞 這次發生什麼 本週可以做的事
對外暴露的內部工具 Appsmith 沒修補，成為入口 盤點 Appsmith、Grafana、Jenkins、GitLab、Metabase 這類「方便但不在核心資安流程」的工具；對外只留必要入口；修補 SLA 比照核心系統
Repo 裡的金鑰 GitLab 上找到資料庫金鑰 掃歷史 commit；金鑰短效化；資料庫帳號最小權限；排定輪替
CI 到 DB 的網路路徑 CI 主機出現未授權執行緒 預設拒絕；CI 只能到它需要的服務；資料庫只接受應用層網段
機器速度的偵測 這類工具會大量枚舉、快速變形 看行為：同一來源短時間大量 404/401、參數快速改變、預設 8787、頁面 title「ARTEX—自主渗透测试控制台」
通知與治理 18 天後才通知品牌 把「通知客戶」寫進應變手冊的時間軸；區分「已確認」與「已足夠通知」；平台與品牌做聯合通知演練

第四項要補一句：不要只封 IP。韓國 FSI 的說法是，IP 換了就繼續打，手法和漏洞不變。你要抓的是行為，不是地址。

還有一個更根本的：你的資產清單裡，有沒有那些「只有員工在用、只有合作夥伴在用」的系統？韓國這次打的全是這一類，91APP 的 Appsmith 也是這一類。它們通常不在客服、不在官網、不在金流，所以也不在演練劇本裡。

用 Agent 打自己：可以，但要有授權的樣子

這次事件最實用的結論，是防守方也該用同一類工具。但「用 AI 打自己」跟「拿一個 fork 亂掃」是兩件事。

我的做法會是這樣：

  • 書面授權與 scope：域名、IP、時間窗、禁止動作，先寫清楚
  • 隔離環境與專用帳號，不要從生產網段發起
  • 全程日誌與審批紀錄，事後可回溯
  • 模型與工具來源可審核，不要拿來源不明的 fork 進內網
  • findings 要對到 owner 與修補 SLA，不然只是產出一份漂亮的報告
  • 先從外部暴露面與 CI/CD 路徑開始，不要一開始就打核心

ARTEX 作者自己的條款禁止真實滲透測試，所以我不會建議你直接拿它上場。你要的是同一類能力，不是同一個 repo。商業工具、自建工具、有審核的版本都可以，重點是授權、範圍與紀錄。

我的判斷

第一，這個世界的 IT 架構，大部分都是草台班子，坑坑巴巴。太多子系統——91APP 的 Appsmith、韓國銀行的外包公司系統——根本沒有重兵防禦。這些子系統平常不在資安預算裡，也不在演練劇本裡。以前這個草台班子沒垮，是因為駭客精力有限，不可能每個都試。但 AI 加上這樣的 harness 來了，路邊一個小孩子都有機會當黑帽，還是能力 top 等級的黑帽。所有系統，不管是不是核心，都變成可以攻擊的。這種飽和攻擊，會逼防守方去治理「全部」有機會碰到內部系統的子系統。

第二，這不是「AI 駭客元年」，是「攻擊工作流產品化元年」。真正的新東西不是模型，是有人把偵察、規劃、執行、驗證、紀錄包成一個可以自架的系統。

第三，企業的預算不要全押在「用 AI 偵測 AI」。先修 2015 年就該修的東西。那些東西不會因為 AI 出現才變成問題，只會因為 AI 出現而變得更常被試。

第四，做 agent 的人要記得：你的審批閘門是給自己人用的。安全邊界在權限、網路與資料，不在 prompt。

91APP 說受影響的品牌與會員範圍還在確認；韓國與日本的調查也還在進行。如果後續報告補上 ARTEX 的實際行為，我會回來更新這篇。

坦白說

  • 我沒有把 ARTEX 架起來跑。架構描述依 fork 的 README，不是原始碼審計；原 repo 已經 404。
  • 91APP 沒有公布是哪一個 Appsmith CVE，也沒有公布 ARTEX 在這次事件中的具體行為、受影響品牌與人數。
  • 韓國與日本的數字來自公開報導與廠商報告，受害者數量版本不一；「同一攻擊者」還沒有經過執法確認。
  • 359 個對外暴露的 ARTEX 相關 IP、近百個 fork，都是我這段時間查到的快照，會變動；暴露的服務不等於攻擊者。
  • 我把「91APP 的破口比較像人的選擇」標成推論，不是報告結論。
  • 這篇沒有第一手鑑識資料，請不要當成判決。

常見問題 Q&A

Q: ARTEX 是病毒嗎？

不是。它是可以自架的滲透測試系統，本身不會自動找上你。要有操作者把它指向你的資產，才會有攻擊。

Q: 我的公司沒有用 ARTEX，需要擔心嗎？

要擔心的不是這個名字，是它代表的能力：有人可以用很低的成本，對你的外部服務持續試錯。先盤點暴露面與修補速度，比追名字有用。

Q: 開源 AI 工具是不是都該禁？

不。禁工具擋不住能力。要管的是誰能把工具指向你的資產，以及你的資產有多少沒鎖的門。

參考資料