Wiz 披露 ARTEX 智能体被 Storm-0940 用于攻击 IT 和软件厂商

2026年10月期间，我们发现一名攻击者使用与ARTEX（一个自主AI渗透测试代理）相关的工具，针对多家IT和软件供应商发起攻击。该活动聚焦于身份提供商（Okta、Entra、Cognito）以及对Microsoft 365集成的滥用。我们观察到其在多个环境中反复尝试发现身份验证绕过、枚举API并访问（目标供应商的）客户数据。

我们的观察与微软近期关于Storm-0940的报告存在重叠，该组织是一个与中国政府关联的攻击者，与近期涉及被盗供应商凭证及下游Microsoft 365租户的供应链攻击有关。\

然而，我们还额外观察到相同的基础设施、工具和攻击模式针对整个行业。通过对已识别的TTP和IOC进行关联分析，我们还发现同一攻击者正将其尝试的供应链入侵扩展到其他软件领域。

在本博客中，我们将描述使用ARTEX的攻击者在多个环境和云提供商中应用的可重复模式和方法，并附上来自真实攻击的示例。

什么是ARTEX？ 

ARTEX是一个开源的自主渗透测试框架。一名中国开发者于2026年7月在GitHub上发布了它，并于当年9月赢得了百度的“Agent+”红队挑战赛。在实际操作中，操作员提供目标和目的。随后规划代理选择下一步行动，工作代理运行nmap、curl和Impacket等工具，每个结果都会汇入一个共享的资产与发现图谱。

攻击者在数周内就采用了它。ARTEX的痕迹出现在9月下旬对韩国银行的攻击以及10月对日本企业的攻击中。微软和Zscaler此后将其与两个不同的攻击者关联起来。开发者于10月8日将该工具转为闭源。彼时，该代码已有超过12,000个分支。

一套可重复的剧本

在所调查的环境中，我们观察到一致的侦察和攻击尝试序列：

• 测绘应用：下载JavaScript包、暴露的source map、运行时配置以及Swagger/OpenAPI文档，以发现内部API路由和应用功能。

• 探测身份验证：反复发起登录流程，操纵OAuth回调和state参数，测试未签名的JWT，并探测SSO和Microsoft 365专用端点。

• 攻击身份提供商和登录流程：对企业Okta和Entra ID环境进行密码喷洒，并针对内部和专有应用的登录页面。

• 滥用账户恢复：反复调用密码重置、用户名找回、激活和重置令牌端点。

• 测试租户隔离：尽可能使用一次性电子邮件地址注册账户，然后操纵可预测的标识符，以探测访问控制缺陷和未经授权的跨租户数据访问。

• 适应防御机制：被封锁时轮换IP地址，并不断更换用户代理。

日志中的表现

我们使用通过Wiz无代理工作负载检测收集的HTTP访问日志，以及AWS Cognito事件、Entra登录活动和Okta身份验证日志等身份提供商日志，分析了这些攻击模式。

针对内部应用

在所有观察到的攻击实例中，该代理的第一步始终是读取应用本身。首次接触后几分钟内就出现了如下请求：

不久之后，它开始按名称调用内部 API 路由。这些路由名称唯一出现的地方，就是它刚刚下载的 source map。

账户恢复功能也遭遇了同样的对待。该代理先检查哪些用户名存在，然后对重置端点发起猛烈请求：

凡是能注册的地方，它都注册了，使用的是来自免费临时邮箱服务的一次性邮箱。随后，它立即尝试查看他人的数据：

在每次模糊测试运行之前，它都会先确认基线“未找到”响应是什么样子：

针对 OAuth 身份提供商 

在探测 Microsoft OAuth 流程时，该代理通过注入伪造的授权码和格式错误的 state 参数，直接操纵回调端点，同时还尝试使用未签名的 JWT 绕过身份验证：

第二个令牌解码后不过是 {"alg":"none"} 和 {"email":"test@test.com"}。该代理在两分钟内用这个载荷对 60 多种 SSO 路由变体发起了密集请求。

在 AWS Cognito 上，我们观察到了与专有应用中账户恢复滥用相呼应的模式。这一活动体现在 InitiateAuth、ForgotPassword 和 ResendConfirmationCode 等事件中。这些请求来自与早前攻击中观察到的相同的用户代理组合，包括 boto 和 python-urllib 这类看似无害的编程客户端。

该代理还尝试直接创建新身份，调用 AWS Cognito SignUp API，同时轮换其用户代理池。

密码喷洒

我们还追踪到一场针对众多已观察目标的大规模密码喷洒活动。该活动不区分 IDP，同时攻击 Entra 和 Okta，并表现出若干独特的 AI 驱动特征。

这些攻击针对数百名用户，并以高度协调的突发方式执行。每次突发都具有以下特征：

• 专用用户代理：每次突发都分配了唯一的用户代理字符串，与之前各波次使用的不同。

• 精确计时：认证尝试之间的中位间隔严格为 1 秒。

• 持续执行：单次突发持续 20 到 60 分钟不等。

• 基于角色的定向：该代理主要针对软件工程师所属的账户。

• 重复尝试：部分单个用户遭受了十多次登录尝试。

设计上的不懈

该活动具有持久性和高度自动化。部分会话持续 24–30 小时，当 IP 被封锁时，新地址会在几分钟内出现。

在一次会话中，该代理轮换了同一 SSO 端点的十几种变体 （/sso、/sso/、/sso/login、/sso/jwt、/jwt/sso…），每种变体都分别携带和不携带同一伪造令牌，速率约为每秒一个请求。当某个登录页面开始对该活动进行速率限制时，该代理干脆切换到同一主机上的另一个端点继续操作。

我们在受害者中观察到了 15 种以上不同的用户代理字符串：

• 基于 Python 的客户端和 curl；

• 被截断的 Chrome 字符串，以及版本号看似随机的无头浏览器。

• 更具辨识度的自描述标识符，例如 ReconProbe/1.0。

这种多样性，结合一致的攻击模式和与 ARTEX 相关的指标，帮助我们将跨多个组织的活动关联起来。

尽管这些尝试大多失败了，但真正的威胁在于其方法论。人类攻击者受限于时间和疲劳，而自主智能体不会放弃。它只会不断迭代，直到找到一个薄弱点。

一次明显的智能体攻击

观察到的单项技术均无新颖之处。然而，将这些技术结合起来，便能看清此次攻击背后的智能体。有几个明确的信号：

1. 步骤被自动串联：当注册开放时，它使用一次性邮箱注册、确认账户，并立即请求另一家公司的数据。

2. 每个自动化步骤都使用上一步的输出：在拉取源映射几分钟后，便按名称调用内部 API 路由

3. 自适应是自动的：当登录页面开始限流时，智能体转向同一主机上的其他端点。当一个 IP 被封禁时，几分钟内就会出现一个新 IP。

4. 并非所有攻击都是合乎逻辑的：具备此技能水平的人类攻击者不太可能花时间在备受审视的 Microsoft OAuth 流程上测试通用载荷。 

领先于 AI 驱动的攻击

随着 AI 使侦察和利用尝试变得更快、更易于扩展，防御者需要缩短暴露与修复之间的差距。进一步了解如何借助 Wiz 的 AI 威胁就绪框架 做好准备。 

此外，Wiz 的 AI 红队智能体 持续自主开展攻击性测试，帮助以 AI 的速度减少暴露面——从而平衡双方力量。

Wiz 客户可参阅我们的威胁情报中心警报：ARTEX：智能体 AI 活动导致云与供应链沦陷

现有检测规则也能有效识别此活动，例如：

• 针对多个用户的大量失败登录尝试，随后成功登录管理员用户

• 来自单一 IP 的潜在密码喷洒攻击

• Okta 用户密码喷洒

这种持续不断的行为还会产生可预测的模式，同样可通过“异常大规模访问被拒活动”等规则检测到。

入侵指标

注意：所提供的许多用户代理并非该攻击者独有，若单独进行狩猎，预计会产生大量噪声。