超800个Artex实例暴露公网：AI渗透测试工具反成风险入口

先说一件必须先说的事：“800 个”这个数字，是把 1,465 减掉 650 之后的结果。

Censys 首席安全研究员 Silas Cutler 在 11 月 5 日的报告里写得清楚：截至 11 月 3 日，他们通过指纹匹配到 1,465 台在公网上跑着 ARTEX 控制台的主机。其中约 650 台集中在两个完全同构的网段里——同一套端口布局、同一套模板——把这部分剔掉，”看起来彼此不同”的部署大约剩 815 个。

标题里的 800 就是这个 815。它是去重后的下限，不是总数。

而这个差额本身就是新闻的一部分：有一家服务商在批量出这种机器。

一、1,465 是怎么变成 815 的

Censys 的指纹不复杂：页面标题以 ARTEX 开头（后接空格、冒号或破折号），加上 Next.js 的 _next/static 静态资源。两个条件一起命中，基本不会误判。

(web.endpoints.http.html_title=~"^ARTEX[ :—]" and web.endpoints.http.body: "_next/static")
or (host.services.endpoints.http.html_title =~ "^ARTEX[ :—]" and host.services.endpoints.http.body: "_next/static")

按这个查，1,465 台。分布很集中：

• 端口：8787 是 ARTEX 默认端口，命中 1,931 个端点（比主机数还多，因为一台机器可以挂多个）；其次是 8790、443、80
• 国家：美国 726、香港 387、中国 177、日本 51、新加坡 38、韩国 21
• 语言：中文默认界面占绝对多数，英、韩、日、俄、葡的本地化版本也有

然后是两个异常集中的网段，合起来占了 44%：

• PEG Tech（AS54600）：493 台，分布在 13 个 /24 里，只有两种端口布局，其中 38.11.221.0/24 和 38.11.173.0/24 各 125 台
• Yancy Limited（AS138415）：157 台，同一套 CyberPanel + 邮件服务器的模板，基本都在 156.234.0.0/16

Censys 给这个现象的判断很直接：这种整齐程度不是几百个独立运营者，是一套开通模板。

而且 Yancy 不是第一次出现。2025 年 12 月，Censys 就在这家看到过一波 Cobalt Strike 监听器激增，单日峰值 407 台新主机，两周内归零。当时的结论是”几个真实实例铺在几百个 IP 别名上”。这次的 ARTEX 主机形态一样。

所以 815 也只是上限。真实的独立运营者数量，可能比这个数字低得多。

这不是给谁洗地——恰恰相反。它说明两件事同时成立：一，暴露面比看起来更集中；二，这种批量开通本身就在制造风险，因为买家拿到手的是一台默认配置、默认端口、默认无鉴权的攻击平台。

二、ARTEX 是什么，为什么会被人拿来当武器

2026 年 7 月 26 日，GitHub 用户 Autumn-27 以 AGPL-3.0 协议发布了 ARTEX。作者另一个项目 ScopeSentry 是国内用得比较广的资产发现与漏洞扫描平台，2000 多 star。

ARTEX 的定位可以说是在 ScopeSentry 之上加了一层 AI agent：ScopeSentry 扫出来的域名、子域、IP、端口、端点，直接同步进 ARTEX 自己的资产图。

技术栈是 Go 写后端、Next.js 做控制台、PostgreSQL 存数据，Docker 镜像里自带 nmap。这套组合意味着部署门槛极低——一条 docker run，默认就监听 8787。

跑起来之后的流程是这样：

• Planner agent 把用户定义的目标拆成一条条攻击”意图”（intent）
• Worker agent 领取意图、调用工具（nmap、以及镜像里带的其他东西）、把结果写回
• 一个事件驱动的引擎反复跑”探索—决策—执行”这个循环，直到目标达成
• 全程维护两张图：资产图（目标长什么样）和探索图（测到哪儿了）
• 内置 mitmproxy 做流量录制
• 模型后端可以接 Anthropic、OpenAI，或者任何 OpenAI 兼容端点

任务描述框里默认给的示例是这么一句：*”What to achieve, e.g., gain admin panel access or server privileges”*——想达成什么，比如拿到后台管理权限或服务器权限。

微软的描述更干脆：这套 agent 系统能”从侦察一路做到数据外泄，几乎不需要人工介入”。

发布十周内，star 数到 1,500–2,000。10 月 8 日，也就是 CrowdStrike 报告发布的第二天，作者在 GitHub 主页发了声明，说自己与攻击无关、ARTEX 只用于授权范围内的资产测试，然后宣布闭源、不再发布新版本。原仓库已下架。

但下架没用。Censys 数了一下现在还在流通的分支：jiwoochris/artex-global 2,885 star、BaaRai/ARTEX 1,696、Hinln/ARTEX 1,408（带原始提交历史的源码备份）、RuoJi6/ARTEX 1,405、cskwork/scopeweaver 927（英韩本地化）。还有一堆二开版：加了代码审计的、加了内网横向的、加了 IoT 协议适配的。

AGPL 一旦发出去，就收不回来了。

三、它已经被用过两次，账单在别人手里

这部分是整件事的分量所在——不是”可能被滥用”，是已经有两次归因明确的战役。

第一次：韩国金融，CrowdStrike，10 月 7 日。

2026 年 9 月底到 10 月初，一个未被命名的攻击者用 ARTEX 打了韩国的金融机构。CrowdStrike 评估为”中等置信度的、财务动机的中文使用者”。

手法是：一家银行被打穿了给券商用的贷款进度查询服务，另一家被打穿了员工的移动办公支持系统，数据被外带。

关键基础设施是 38.244.50[.]120，ARTEX 主模型跑的是 DeepSeek v4.1-flash（大概是通过 API 中转商 xcai[.]pro 买的），另外还用 GLM-5.3（智谱）和 Grok 4.6 跑 Claude Code 会话。

CrowdStrike 是怎么发现这一切的？因为攻击者忘了关目录。

38.244.50[.]120:18899 是一个开放目录，里面躺着 .claude/CLAUDE.md——一份中文的渗透测试提示词，规定了 LLM 该怎么干活；还有 Claude Code 的会话历史、ARTEX 的配置文件、Claude 的记忆文件。

Censys 翻了扫描历史，发现这个目录从 8 月 18 日就开着，比 CrowdStrike 的报告早了七周。而目录里的文件名显示，这名攻击者盯的目标远不止韩国银行——支付公司、游戏公司都在里面，和 CrowdStrike 观察到的”同一画像的更广活动”对得上。

第二次：ConnectWise 供应链，微软，10 月 21 日。

微软把 ConnectWise Cloud Backup 的供应链入侵归因给 Storm-0940，一个 2021 年就活跃的、中国国家背景的行为体，长期靠密码喷洒和打互联网暴露应用吃饭。

这一次 ARTEX 被用来做三件事：扫描侦察、密码喷洒、OAuth 应用滥用。规模是这样的：

• 尝试登录 2,250+ 个租户
• 峰值 每分钟 2,900 次尝试
• 10 月 10–14 日那波，15.1 万+ 次失败登录，其中 10 月 11 日一天集中了 11.1 万次
• 8 个组织里的 327 个账号被针对，48 个账号收到超过 1,000 次失败
• 4 个应用凭据，4 分钟内完成 200+ 次登录

微软的原话值得抄：多次入侵里，“从初始定位到拿到特权访问，用时不到 3 小时”。而且这些自动化活动会产生大量流量和日志、会触发告警——但速度让防守方几乎没有时间协调响应。

有一个细节必须说清楚，否则容易误读：那一波跨租户密码喷洒（327 账号、8 组织、15.1 万失败）最终没有一次成功认证，98% 的响应是锁定。真正得手的是另一条路——他们先拿到了 ConnectWise 云应用的身份，然后用这些已被租户信任的应用凭据，从同一批 IP 去认证下游客户环境。

这就是供应链攻击的本质：你信的不是那个 IP，是那个应用。

四、暴露的不只是控制台，是整套军火

回到 Censys 报告里我认为最该被传播的部分：32 个开放目录。

不是 32 个”配置不当的控制台”，是 32 个直接列出了攻击装备的目录。举几个原文里的例子：

• 110.42.215[.]163:18080 —— GodPotato、Invoke-TheHash / SMBExec / WMIExec、pass-the-hash 脚本、MSSQL UDF DLL。一整套 Windows 横向移动工具箱
• 111.68.4[.]13:18080 —— 公开的 CVE-2021-3156（sudo “Baron Samedit”）利用、堆转储、爆破脚本
• 108.165.147[.]226:8299 —— 三个 beacon_linux_amd64 植入体构建，加反弹 shell 脚本；这台机器同时还跑着 FRP 和 CyberStrikeAI
• 206.187.215[.]173:8081 —— c2.py、stager.c，加一个编译好的 Windows stager
• 181.41.194[.]136:8081 —— 约 18 个 HTA 投递器、批处理加载器、一个 wpad.dat，以及一张 MITM 根证书私钥
• 203.195.243[.]103:80 —— fscan 内网扫描器、payload 可执行文件，旁边是 Vshell 监听
• 154.12.86[.]207:18080 —— 一名操作员的整个 home 目录，包括 .ssh、.bash_history，和 ARTEX 安装目录

最后那条我得单独说一句。.bash_history 加 .ssh 加工具目录，等于把”这个人平时怎么干活”整包送出去。对手不用打你，读你的历史记录就够了。

这些目录大多只存活几小时到几天。11 月 3 日到 5 日两天里，10 个关了，15 个新的开出来。Censys 因为有扫描历史，关掉之后文件列表还留着——所以这些曝光是可追溯的、可复盘的。

顺带一个数字对比，能说明这种失误有多普遍：Censys 在写这篇报告的过程中就撞见 32 个。这不是孤例，是这一类操作者的通病。

五、10.6% 的机器上，还跑着别的东西

1,465 台里，155 台（10.6%）至少还命中了一个别的威胁检测。

三种模式：

① AI 攻击框架叠着用。 最常见的搭配是另一个 AI 渗透工具——CyberStrikeAI 和 ARTEX 同宿 70 台，还有 PentAGI、HexStrike AI、RedAmon。这些人不是选一个用，是并排跑好几个。

② AI 工具旁边就是传统 C2。 这组数量不大但性质明确：

• 1.14.104[.]208 —— ARTEX + PentAGI，旁边 50050 端口跑着 Cobalt Strike teamserver，4321 端口跑着 Adaptix C2 监听
• 1.14.193[.]53 —— 两个 ARTEX 控制台、Vshell、NPS、Gophish、一个邮件服务器管理面板，还有一页叫”SuperAgent 主监督”
• 45.87.53[.]3/4/6/10/14 —— 五台同构主机，每台都是 ARTEX + CyberStrikeAI + ARL（灯塔）+ Vshell

③ LLM 访问本身成了技术栈的一部分。 43 台还跑着自建的 LLM 网关或中转软件，主要是 CLIProxyAPI（19 台）和 New API（18 台）。

这条对防守方最有价值。CrowdStrike 那个案例里，攻击者的 DeepSeek 就是从中转商买的。如果你在出口日志里看到不认识的 LLM 代理或中转域名，那是个信号，不是噪音。

六、为什么会这样：默认配置，加一个错误的直觉

Censys 那句话说得克制但到位：ARTEX 控制台根本不需要对公网开放。

它的使用场景是自己定义任务、自己跑、自己看结果。整个过程没有任何一环需要”别人能从互联网访问到我”。

那为什么有 1,465 台开着？我的判断是三个原因叠加：

第一，默认值就是公网。 8787 端口、0.0.0.0 监听、无鉴权。Docker 一把梭的人不会去改。

第二，把攻击工具当成普通 Web 服务部署。 装 Grafana、装 WordPress 的肌肉记忆是”绑到公网，方便访问”。但这是一台装着 nmap、mitmproxy、植入体、和你的模型密钥的机器。它更像一台跳板，不像一个网站。

第三，买模板的人不知道里面是什么。 那 650 台同构主机就是证据。一套模板批量开通，买家拿到的是”一个能跑 AI 渗透的平台”，未必意识到这台机器上有什么、以及它对公网意味着什么。

结果就是双向暴露：攻击者的目标被暴露，攻击者自己也被暴露。 这是 Censys 报告标题里”asbestos”（石棉）的双关——石棉既伤人，也伤装它的人。

七、给防守方：这份数据可以直接用

Censys 把狩猎方法全公开了，照抄即可：

查控制台

(web.endpoints.http.html_title=~"^ARTEX[ :—]" and web.endpoints.http.body: "_next/static")
or (host.services.endpoints.http.html_title =~ "^ARTEX[ :—]" and host.services.endpoints.http.body: "_next/static")

按默认端口扫 8787/tcp，其次 8790、443、80。

做三组 pivot：

• 同一主机上有没有开放目录（尤其 8081、8299、18080 这类高位端口）
• 有没有 Vshell、FRP 监听
• 有没有 CLIProxyAPI 或 New API 这类 LLM 网关

查历史：扫描记录里找 mitmproxy 的 banner、以及高位端口上短命的 Python SimpleHTTP 服务。Censys 说这两样经常出现在控制台之前——也就是说，你能在攻击者正式开张前就看到苗头。

另外三条给企业内的：

• 这类暴露通常在云上，先查你自己的云账号有没有人私自起了”安全测试平台”。影子 IT 里最危险的一类就是带攻击能力的影子 IT。
• 出口流量里出现陌生 LLM 中转域名，按可疑处理。
• 微软那份报告里的教训更重要：多租户应用的权限要按最小化给，并且应用 ID 而不是显示名去盘。 被信任的应用凭据，比被偷的密码更难防，因为它不需要交互式登录。

最后

这件事有个很对称的地方值得记下来。

ARTEX 之所以危险，是因为它把”渗透测试”这件事的门槛降到了 docker run 加一个模型 API key。但它降的是攻击能力的门槛，没降运维的门槛。

于是我们看到：一批人拿到了能自动打穿系统的工具，同时把自己的 .ssh 目录、C2 配置、MITM 根证书私钥挂在公网上。

Censys 那句话我认同：简单的漏洞——包括配置错误——同时暴露了攻击者和他们的目标。

对防守方来说，这是个难得的位置：你不需要比对手更强，你只需要比对手更细心。那 155 台同宿 C2 的机器，那 32 个开放目录，那 43 台跑着 LLM 中转的机器——都是对手自己交出来的情报。

对正在用这类工具做授权测试的人，只有一句：改默认端口，加鉴权，别把控制台绑到 0.0.0.0。 你手里这台机器上的东西，比你测的目标更值钱。