800个ARTEX实例裸奔公网

11月6日，安全研究人员披露，超过800个ARTEX AI渗透测试工具的独立部署实例直接暴露在公网，访问者甚至不需要密码登录，就可能查看任务、资产、攻击工具和运行数据。一个原本用于授权渗透测试的多Agent系统，被不少运营者部署成了任何人都能打开的“自动攻击控制台”。(techcrunch.com)

这不是又一次普通的后台面板泄露，而是Agent安全运维最典型、也最危险的一次反面案例：企业和研究人员开始让AI自主扫描资产、调用工具、保存凭据和验证漏洞，却仍在用部署个人博客或测试面板的方式管理它。

超过800个控制台无需密码

ARTEX 是一个由大语言模型驱动的自主渗透测试框架。 用户设置目标、测试范围和任务后，Planner Agent负责拆解计划，Worker Agent调用Nmap等安全工具执行扫描与验证，并把资产、漏洞、流量和任务结果写回数据库。

这种架构与传统漏洞扫描器的最大区别，是ARTEX不会只按照固定规则跑完一张检查表。它会根据上一轮结果决定下一步动作：发现新子域名后继续枚举服务，拿到应用指纹后切换检测策略，验证漏洞后再更新资产关系图。

Censys在11月4日观测到1465台运行ARTEX控制台的公网主机，其中约650台集中在两个高度相似的托管网段，配置和端口布局几乎一致。排除这批可能由模板批量生成或通过多个IP映射的节点后，仍剩下约815个看起来相对独立的部署。

TechCrunch在11月6日援引这项调查称，超过800个独立ARTEX部署无需密码即可访问。ARTEX本身并不要求控制台对公网开放，因此这些实例暴露在互联网，并不是产品运行的必要条件，而是部署者主动绑定公网地址、错误配置反向代理或完全没有设置访问控制的结果。(techcrunch.com)

不同安全机构给出的数量并不完全一致，但趋势高度一致：ARTEX的公网暴露规模正在快速增长。

| 调查来源 | 统计时间 | 发现规模 | 统计口径 | | --- | --- | ---: | --- | | AhnLab ASEC | 10月初 | 600个IP | 托管ARTEX实例的公网IP | | AhnLab ASEC | 10月14日 | 超过900个IP | 可从互联网访问的相关系统 | | Censys | 11月4日 | 1465台主机 | 识别到ARTEX控制台特征的主机 | | Censys | 11月4日 | 约815个 | 排除约650个高度重复托管节点后的独立部署估算 | | Check Point Research | 11月5日 | 2557个历史系统、1608个在线实例 | 曾经或正在托管ARTEX面板的系统 | | Check Point Research | 11月5日 | 10个数据库暴露实例 | 可直接查看完整ARTEX数据库的错误配置系统 |

这些数字不能直接等同于攻击者数量。一个运营者可以控制多个IP，一个IP也可能只是安全研究人员、企业红队或临时测试环境；但即使按照最保守的815个独立部署估算，暴露规模也已经足够形成一套可被批量搜索和接管的攻击资源池。(asec.ahnlab.com)

暴露的不是面板，而是一整套攻击上下文

Agent运行上下文是AI系统在执行任务时积累的目标、工具、凭据、会话和中间结果。 对渗透测试Agent来说，这些数据往往比最终生成的漏洞报告更敏感。

传统扫描器后台暴露，攻击者通常能看到IP、端口和漏洞列表；ARTEX控制台暴露，外部人员可能看到的是一条仍在运行的任务链，包括测试目标、Agent提示词、历史对话、捕获的HTTP流量、漏洞验证结果和自定义工具。

Censys还发现32个ARTEX主机同时开启了可公开浏览的文件目录，里面出现了横向移动工具、植入程序、反向连接脚本、堆转储文件和私钥等敏感内容。部分目录只存在数小时，但互联网测绘平台已经留下扫描记录。

Check Point Research发现的情况更严重：至少10个错误配置实例直接暴露了完整ARTEX数据库。研究人员因此能够看到运营者如何给Agent下达目标、配置了哪些模型，以及Agent执行了哪些步骤。(censys.com)

ARTEX还支持记录代理流量，并将经过身份验证的浏览会话转化为Agent可检索的证据。公开维护的ARTEX分支显示，其浏览器扩展可以采集已登录页面的请求与响应，再写入流量存储系统；这意味着一旦控制台、数据库或运行目录暴露，风险可能从“泄露扫描结果”升级为“泄露有效会话和认证上下文”。(github.com)

| 系统类型 | 自动化程度 | 通常保存的数据 | 公网暴露后的主要风险 | | --- | --- | --- | --- | | 传统漏洞扫描器 | 固定规则、批量扫描 | IP、端口、漏洞结果 | 资产与漏洞清单泄露 | | AI渗透测试Agent | 自主规划、调用工具、循环验证 | 提示词、任务历史、流量、凭据、证据 | 攻击链与认证上下文泄露 | | 暴露的AI渗透测试Agent | 外部人员可能直接访问运行环境 | 完整数据库、工具、模型配置、目标资产 | 被接管后继续攻击原目标或反向攻击部署者 |

因此，把ARTEX控制台理解成一个“带AI的扫描器后台”，会严重低估问题。它更接近一间没有锁门的红队作战室：墙上挂着目标地图，桌上放着门禁卡，终端里还有正在执行任务的自动化操作员。

ARTEX已经出现在真实攻击中

Agent化攻击是指AI系统在较少人工干预下，自主完成侦察、策略选择、工具调用和结果验证的攻击流程。 它不会凭空创造漏洞，但能显著压缩攻击者在不同目标之间切换和重复操作的时间。

今年9月底至10月初，ARTEX被发现出现在针对韩国金融机构的攻击活动中。相关调查认为，操作者使用DeepSeek系列模型驱动ARTEX，并结合其他模型和编码工具，对多个目标执行自动化侦察和漏洞利用。

微软在10月披露的另一场攻击规模更大。微软将相关活动归因于Storm-0940，并称该组织使用ARTEX加速扫描、密码喷洒和OAuth应用滥用，尝试登录超过2250个Microsoft 365租户。

微软记录到的部分攻击峰值达到每分钟2900次失败登录，10月10日至14日期间累计出现超过15.1万次失败事件。部分受影响环境从初始攻击到获得云基础设施特权访问，用时不到3小时。(microsoft.com)

这组数字说明，Agent带来的主要变化不是攻击技术突然变得不可理解，而是相同攻击路径被并行复制到更多目标上。弱密码、缺少多因素认证、权限过大的OAuth应用和暴露的管理端口都不是新问题，但Agent可以全天运行，并同时尝试多条路径，让防守方原本按小时计算的响应窗口缩短到分钟级。

更荒诞的是，攻击工具自己也被植入后门

软件供应链投毒是攻击者通过篡改依赖、镜像或构建产物，将恶意逻辑传递给下游使用者的攻击方式。 ARTEX停止公开更新后，大量复制仓库、重新打包版本和第三方容器镜像迅速出现，使供应链风险进一步放大。

安全研究人员近期发现，一个非官方ARTEX容器镜像在登录处理流程中加入了隐藏逻辑。攻击者只需向验证码字段提交特定标记，就能在认证检查之前以root权限执行系统命令。

截至11月2日至4日，至少62个公网ARTEX控制台被发现运行这一后门版本，其中26个位于美国、17个位于香港、7个位于中国。相关容器镜像的下载次数达到约9000次，但下载量并不等于实际安装量或受感染主机数。(thehackernews.com)

这件事形成了一个近乎讽刺的闭环：有人部署AI渗透测试工具寻找别人的漏洞，却从来没有审计自己拉取的镜像；工具以root权限运行，控制台又直接暴露公网，最终部署者自己成为最容易被入侵的目标。

问题不在“AI太强”，而在权限给得太随便

Agent安全运维是围绕AI Agent的身份、权限、工具、数据、运行环境和操作审计建立的持续治理体系。 它不能只检查模型是否会输出危险内容，还要管理Agent实际能做什么。

目前很多团队把Agent安全等同于提示词过滤或模型内容审核，但ARTEX事件说明，真正决定风险上限的是系统权限。如果Agent可以访问生产网络、读取有效凭据、调用Shell、修改云端身份并持续运行，那么它就应该被当作特权自动化账户，而不是普通Web应用。

ARTEX的公开部署暴露了Agent项目最常见的四个运维误区：

1. 把管理面板直接绑定到公网。 远程使用需求本可以通过VPN、零信任访问网关或SSH隧道解决，没有理由让控制台面向整个互联网。
2. 把登录密码当作唯一防线。 高权限Agent至少需要多因素认证、访问白名单、短时会话和异常登录检测。
3. 让Agent继承过大的凭据权限。 模型只需要读取扫描结果时，不应该同时获得云管理员、数据库写入或代码仓库发布权限。
4. 默认信任第三方镜像和复制仓库。 项目停止维护后，来源不明的镜像恰恰是风险最高的安装方式。

企业现在应该检查什么

Agent资产盘点是识别组织内部所有AI Agent、模型连接、工具权限和运行位置的基础工作。 没有资产清单，安全团队甚至不知道哪些服务器正在运行自动化Agent。

部署过ARTEX或类似工具的团队，应立即进行以下检查：

• 确认控制台、数据库、代理端口和调试服务是否暴露公网，默认端口8787也应纳入扫描范围。
• 将管理界面限制在内网、VPN或零信任访问网关后，并强制启用多因素认证。
• 检查容器镜像来源、摘要值和构建记录，避免继续运行来源不明的预构建镜像。
• 轮换Agent接触过的模型凭据、云端凭据、浏览器会话、数据库密码和测试账号。
• 将Planner、Worker、工具执行器和数据库拆分权限，禁止所有组件共享root账户或同一组长期凭据。
• 为扫描、漏洞验证、代码执行、权限修改和数据导出设置不同等级的人工审批。
• 保留完整工具调用日志、网络流量日志和身份审计记录，并建立一键暂停任务和撤销凭据的“紧急停止”机制。
• 对Agent的出站网络访问设置目的地址限制，避免Agent在任务之外任意连接外部主机。

防守方还需要调整监控思路，因为Agent攻击产生的日志特征与人工操作不同。短时间内跨大量租户登录、非工作时间持续扫描、同一服务身份高频调用目录接口，以及应用凭据突然新增高权限角色，都应该触发更高优先级告警。

Agent的安全边界必须从产品设计开始

ARTEX事件最值得行业警惕的地方，是Agent能力增长速度已经超过安全运维体系的升级速度。开发者正在快速增加记忆、工具调用、浏览器控制和多Agent协作，却经常把身份认证、权限隔离、升级签名和审计能力放到后续版本。

闭源也无法解决已经扩散的版本问题。ARTEX开发者在10月8日宣布停止继续公开发布，但原始代码的备份、翻译版本和改名分支仍在流通；对于已经进入公共代码生态的工具，删除上游仓库只能阻止未来更新，无法收回现有副本。(techcrunch.com)

Agent安全接下来需要形成一套类似云安全责任模型的规则：模型厂商负责基础能力和滥用控制，Agent框架负责权限设计和危险动作审批，部署者负责网络隔离、身份认证、日志与供应链验证，最终使用者则必须对测试范围和授权负责。

这次事件给出的结论并不复杂：越能自主行动的Agent，越不能被当作普通软件部署。一个能自己找路、自己调工具、自己保存凭据的系统，一旦管理界面没有锁、运行镜像被投毒或权限没有边界，它首先自动化的可能不是安全工作，而是安全事故。

参考来源

• BaaRai/ARTEX：ARTEX公开维护分支，可用于了解多Agent架构、流量记录、资产同步与默认部署方式。
• Autumn-27/ScopeSentry：与ARTEX资产发现流程相关的攻击面管理项目。
• vxcontrol/pentagi：另一套自主渗透测试Agent框架，可用于对比同类产品的架构与能力边界。
• oritera/Cairn：通用AI状态空间搜索引擎，已用于自主渗透测试场景。