ARTEX 死了，圈子却开始群魔乱舞：从换皮倒卖到公网裸奔的 OPSEC
上游停止维护之后，Fork、商业版和公网暴露的控制台，把整个圈子的工程认知照得一清二楚。
最近 ARTEX 这件事，我觉得已经变成挺有意思的行业观察样本。
一个开源 AI 渗透测试项目，因为被用于真实攻击而停止公开维护。按正常的开源生命周期，故事到这儿就该结束了。
但实际情况正好相反。
原始仓库没了，社区里反而冒出一大堆二次开发、二次分发、重新打包的版本，有的还做成了商业产品。与此同时，这些工具开始出现在真实攻击里，受害者从金融机构一直到政府相关组织。
更魔幻的是，很多使用者似乎没意识到，自己手上运行的是一套拥有目标资产、测试凭据、会话记录、执行历史和网络出口的高价值控制系统。
于是就有了这些场面：
有人用 AI 自动化攻击别人，却把自己的攻击控制台直接挂在公网。
有人想让 AI 提高攻击效率，却把 Prompt、会话历史和运行配置留在了公开目录里。
还有人部署了来路不明的二开版本，把后门请进了自己的攻击基础设施。
说到底，这是一部分所谓自动化渗透从业者对工程、供应链和 OPSEC 的认知缺口，被一个开源项目集中照了出来。
01. 上游死了，Fork 开始群魔乱舞
先说 ARTEX 本身。
2026 年 7 月 26 日，ARTEX 以开源项目发布，Go 实现，前端 Next.js，围绕多个 LLM Agent 组织侦察、漏洞测试、任务规划和结果管理。定位是帮安全团队自动化执行授权范围内的安全评估。
两个多月后，它出现在了真实攻击里。2026 年 10 月初，韩国多家金融机构遭到攻击，CrowdStrike 在 10 月 7 日确认攻击者使用了 ARTEX 和多个 LLM 工具。受影响的系统包括银行面向经纪人的贷款进度查询服务，以及另一家银行的员工移动办公系统，最终造成数据外泄。CrowdStrike 没有把攻击者归因到具体组织，只判断可能是具有经济动机的中文使用者，置信度中等。
10 月 8 日，原作者 Autumn-27 宣布停止公开更新，转闭源，不再发布公开版本，也不再提供原来的维护支持。直接原因就是这起针对金融机构的攻击。
这个决定不难理解。
但代码生态不会跟着作者一起消失。
随后出现了大量独立分支、镜像、翻译版本和重新包装的产品。AhnLab 观察到一串改名版本：ScopeWeaver、Tangora PTaaS、Horda、Meze、AegisLoop、Bob Research Labs / REAPER。
其中一些改了产品名，也改了 UI、文件结构、Agent 配置和语言，但架构痕迹还是原来那套。
我倒不是反对 Fork。ARTEX 最后公开的版本是 AGPL-3.0，二次开发和商业化本身都不是问题。
我好奇的是另一件事：
一个项目刚刚证明了自己的工程能力，转眼就冒出一堆换了名字、换了配色、重新打包的“新产品”。
这些项目到底新增了多少工程能力？
重新设计了任务状态机吗？重新解决了 Sandbox 隔离吗？重新设计了证据体系吗？
还是只是换了套配色，翻译了一下 Prompt，把上游代码重新打包了一遍？
如果连上游的架构边界都没搞清楚，就急着包装成自己的 AI Pentest 平台，我确实不太明白这有什么可吹的。
你可以卖服务，卖维护，卖企业部署方案。但至少得知道自己卖的是什么。
02. 它已经不只是一个安全研究工具
韩国金融机构只是最先曝光的一起。之后 ARTEX 出现在更多真实攻击里，而且是多家机构在事件响应中独立发现的。
政府和其他重要行业也一样。Microsoft 在 10 月 21 日披露，Storm-0940 用 ARTEX 自动化攻击了数百家不同领域的组织，涉及政府、航空航天、金融、能源、制造、半导体。活动内容包括自动化侦察、密码喷洒、OAuth 应用滥用，以及云环境里的后续操作。部分受害环境在不到三小时内就出现了云基础设施的高权限访问。
Google GTIG / Mandiant 在 10 月 31 日的研究里，也把 ARTEX 相关活动与政府、技术、化工、制造业的组织受影响情况联系起来。
这几起活动彼此独立，不是同一个已确认的组织。但它们指向同一件事：
这类工具已经从安全人员的实验室，进入了真实威胁行为者的工具链。
ARTEX 有几个 Agent，其实没那么重要。
真正变的是另一件事：当一个普通操作者只需要给出一个目标和一段自然语言指令，就能让一组 Agent 持续执行侦察、漏洞发现和后续操作时，攻击活动的组织成本确实变了。
原本只有具备一定专业经验的人才能完成的工作，正在被打包成更容易部署和使用的软件。
03. 最精彩的部分：连自己的控制台都保护不好
如果前面还只是工具滥用，接下来的 OPSEC 问题就有点离谱了。
Censys 在 11 月 5 日发布了研究。截至 11 月 4 日，他们发现 1,465 台主机暴露了 ARTEX 控制台，其中约 650 台集中在两个配置高度相似的托管网段。排除掉这些模板化部署后，大概还有 815 个不同的实例。
这些只是暴露在公网的部署，不等于都在被用于攻击。但暴露本身就已经很说明问题了：
ARTEX 控制台没有任何必须暴露在公网的理由。
它是一个管理面，管着任务、目标资产、测试凭据、执行历史和结果数据。你把它放在公网，是准备让谁访问？
更离谱的是，Censys 还在 32 台主机上发现了公开目录。里面有后渗透工具、Stager、Implant、Exploit 二进制、Shell 脚本、内部扫描器、其他 C2 工具，甚至有完整的操作员 Home Directory。
其中一台暴露了 .ssh、.bash_history 和 ARTEX 安装目录。另一个目录里能看到 Windows 横向移动工具、Pass-the-Hash 脚本和相关 DLL。还有主机直接暴露 Beacon 和反向 Shell 脚本。
这已经超出了“忘记关闭目录索引”的范畴。这是把自己的整个工作环境摆到了互联网上。
Check Point Research 也发现了类似情况：2,557 个系统部署过 ARTEX，其中 1,608 个当时仍能从公网访问；在 10 个配置错误的实例上，他们拿到了完整数据库权限，可以直接看到操作者用的模型、给 Agent 的指令，以及 Agent 自主执行的过程。
我觉得这就够说明问题了。
有些人非常认真地研究怎么让 Agent 自动找漏洞，却好像从来没想过自己的控制面本身就是个高价值目标。
你给 Agent 配了客户资产、测试凭据、模型 API Key、执行记录和各种工具，然后把管理后台开放给公网。
这不是自动化渗透，这是自动化给别人送攻击面。
04. 韩国银行那位哥们，是 OPSEC 的反面教材
如果说前面那些公开控制台还只是配置失误，那么韩国金融机构这起事件里的操作者，把这件事做到了另一个层次。
CrowdStrike 能还原部分执行过程，原因朴素得有点可笑：攻击者自己把工作目录暴露了。
服务器上有 .claude 目录、CLAUDE.md、Claude Code 会话历史、ARTEX 配置、Claude Memory，以及其他运行期文件。其中还有指导 LLM 怎么执行测试的中文 Prompt。
Censys 后来发现，这个公开目录在 CrowdStrike 报告发布之前已经暴露了很久，扫描历史能追溯到 2026 年 8 月，一直摆到报告发布。
更有意思的是，研究人员从会话记录里看到，操作者一边用 Agent 执行攻击，一边让 Claude 帮忙查韩国数据交易市场和 Telegram 数据销售群组，还让模型帮忙起草安全研究员简历，把相关活动写成自己的研究经历。
我看到这里确实不知道该说什么。
你一边让 AI 帮你做自动化攻击，一边把攻击 Prompt、Memory 和 Session History 放在公网，连自己工作的目录都没保护好。
你给目标部署了自动化渗透 Agent，却忘了自己也是一个需要被渗透的目标。
这位哥们的技术能力可能不差，甚至可能确实能完成复杂的漏洞利用。但在 OPSEC 这件事上，他和前面那些把控制台直接开放到公网的人，认知水平是一致的。
CrowdStrike 没有公开确认这位操作者的身份。我说的是同类问题，两件事本身没有关联。
05. Fork 本身也可能成为供应链风险
原始仓库停止维护之后，很多人开始找其他镜像和 Docker Image。
这本身没问题，但你至少得知道自己部署的是什么。
2026 年 11 月 6 日，Cloud Security Alliance AI Safety Initiative 披露了一起值得警惕的事件：一个被植入后门的 ARTEX Docker Image 被上传到了 Docker Hub。
研究者披露的数据是：这个镜像有约 9,000 次拉取，11 月 2 日到 4 日之间，有 62 个互联网暴露的 ARTEX 控制台跑的是这个恶意版本。它提供了未经认证的容器内 Root Shell，在某些部署方式下风险还会扩展到宿主机。
还有个细节：恶意镜像不是靠改大量源码实现的。研究指出，某个 Fork 只需要改 docker-compose.yml 里的一行镜像引用，就能让用户拉取恶意镜像。
你以为自己下的是社区维护的 ARTEX Fork，实际部署的可能是别人替换过的镜像。
而这类工具恰好存着最敏感的东西：LLM API Key、客户目标清单、未修复漏洞、测试凭据、会话状态、网络访问能力。
这样的控制系统被植入后门，影响范围远远超过一个普通 Web 应用被入侵。
上游维护者退出，社区继续大量分发未经验证的二次版本，供应链风险就是这么扩大的。
06. 真正该吐槽的，是这个圈子的工程认知
把这些问题放在一起看，会觉得它们是同一件事的不同切面。
有人拿到一个开源项目，换个名字、换套 UI，就开始宣传自己的自主渗透平台。
有人把几个 Agent、几个扫描器和一个 Web Dashboard 组合起来，就认为做完了企业级安全产品。
有人连目标的测试范围都没做好工程约束，就把控制台开放到公网。
还有人能用 AI 找到真实漏洞，却没有能力保护自己的执行环境和运行数据。
我一直觉得，安全工具开发不是把技术组件拼起来就结束了，自动化渗透系统尤其不是。
一个真正能执行安全评估的系统，起码要认真对待这些东西：
- 控制面和执行面的隔离
- 任务权限与目标范围
- 凭据和模型密钥管理
- Sandbox 生命周期
- 网络出口与流量审计
- 任务状态与证据归属
- 故障恢复
- 软件供应链
- 日志和敏感数据保护
这些都没有漂亮的 Demo 页面，也不容易在竞赛里展示。
但它们决定了这个系统是一个能交付的工程产品，还是一个随时会把自己和客户一起送进去的实验项目。
我不反对二次开发，也不反对商业化。
我反感的是另一种情况：
没真正理解上游的架构，没解决它的工程问题，连基本的安全部署都没做好，就急着把它包装成自己的产品。
ARTEX 只是把这些问题集中摆到了台面上。
07. 从 Script Kiddie 到 Agent Kiddie
ARTEX 这件事，给自动化渗透行业上了两课。
第一课，Agentic Pentesting 确实改变了攻击活动的组织方式。原本需要专业人员逐步完成的侦察、测试和后续分析，现在可以交给模型持续执行。
第二课，攻击能力的增长不会自动带来工程能力和安全意识。
这一课其实早就开始上了，只是换了批学生。
以前我们嘲笑 Script Kiddie。
他们下载别人写好的 Exploit，运行别人开发的扫描器，复制论坛里的 Payload，然后把偶然成功的结果当成自己的技术能力。
现在这批人换了装备。
他们开始自己部署一整套 Agent Framework：Planner、Recon Agent、Exploit Agent、Memory、Skills，还有一个相当漂亮的 Web Dashboard。
模型替他们分析目标、生成 Payload、调用 EXP、串起攻击链。
于是有了一个新的群体。
我更愿意叫他们 Agent Kiddies。
传统脚本小子至少还得理解几个命令行参数，知道 Exploit 怎么跑起来。Agent 小子连这一步都省了，交给模型就行。
但模型跑出来的能力，并不属于操作者。
能启动一个会代码审计的 Agent，不代表你懂代码审计。能让 Agent 拼出一条复杂的 RCE，不代表你懂利用工程。能部署一套多 Agent 攻击平台，不代表你懂任务调度、网络隔离、状态管理和证据归属。
更有意思的是，有些人连自己这套平台都没保护好。
控制台直接暴露公网，工作目录公开，Prompt、Session、Memory 和凭据被研究人员完整拿走。
这很像传统 Script Kiddie 的老毛病：能用别人写好的工具，但不知道自己正在做什么。
区别只是工具升级了。
以前是复制一段 Exploit，现在是复制整个 Agent。
以前是不会写攻击脚本，现在是不会理解 Agent 的执行过程。
工具的复杂度上去了，操作者的工程素养没跟上。
用开源框架、Fork 别人的项目、借鉴别人的 Harness，这些都没问题。
但要能回答几个问题：你部署的这个系统，权限边界在哪，网络行为是什么，数据存在哪些地方，出了结果谁来负责。
这些问题答不上来，那么终端里跑着十几个 Agent，也只是拿着更贵玩具的 Script Kiddie。
只不过这一代人有了新名字：Agent Kiddie。
一个成熟的安全工程师，首先应该理解自己正在使用和建设的系统：架构长什么样，风险在哪里，控制面在哪儿，秘密存在哪儿。否则你做的就不是自动化渗透平台。
如果连自己的 ARTEX 控制台都保护不好，我建议先别急着给别人做安全评估。
韩国金融机构那位哥们已经演示过一遍了：目标系统还没怎么着，他自己的 OPSEC 先塌了。